Opinion: Data Validation - Catching Errors Before They Cause Problems

[In this reprinted #altdevblogaday-opinion piece, Nameless founder and programmer Tiffany Smith discusses data validation, examining what kind of things developers should be validating, and how to get people to fix their warnings.] We all do some form of data validation. Something as simple as making sure that the png we're importing as a texture is actually a png, or import detection of the classic "million poly rock". But what I'm talking about here is a specific pass on otherwise valid data that has snuck in. For example, you might import a texture, and the data is correct, but the texture is a temporary texture. This is something that could easily be missed and found later when it's too late to do anything about it. Here at Nameless, we perform this check by hooking it up in the editor on level load and level test; we also have an offline process that allows us to run it on all of our levels from the command line. After saying that, obviously something that runs on level load needs to be fast, so I'm not talking about a process that takes minutes, but seconds. For our current game, our levels are small, so there isn't much data to validate. But since we allow the user to use the editor while the validation is running, we should be able to scale up without much hassle. If speed really becomes a problem, you could have the validation constantly running, and once the initial validation is done, only run the validation on data that has changed. What Kind Of Things Are We Talking About Validating? Assuming you're making a platformer, you may want to make sure there is a valid path to collision geometry. I'm not talking about pathfinding the whole level but more like something as simple as validating that all collision surfaces are within jump height of another collision surface. This would detect the error if someone laid out a collision surface a bit too far, or perhaps accidentally nudged it in the editor when they were doing something else. This and many other little bugs are easy to detect, so why shouldn't we? Depending on the editor, it may also be able to accidentally duplicate geometry. In that case, then you could look for overlapping objects of the same type. But really it's about using common sense and flagging issues as you find them to prevent having to debug them in the future. So, How Do We Get People To Actually Fix Their Warnings? I think the sanest way is to just enforce no warnings. Much like enforcing no warnings in code, it gets easier as people get used to the process. If people aren't staying on-top of their warnings, you could also turn them into errors and refuse to allow them to test the game via the editor until they are fixed. I wouldn't recommend disabling save, though, because if the error is incorrect or they have completed five hours' worth of work and missed something but their machine crashed before they could fix it, then they would be in a world full of hurt. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]