A video game is not that different from any other software development; it perhaps depends more on hardware, but even so it is very similar. When you describe a program you need the client’s opinion and plenty of information to determine how the issue was being taken prior to the new development. In the end it is obvious that albeit there won´t be much relation between the analysis and the final development, that relation will still be more or less recognizeable.
But, what about video games? To start with, the figure of the client blurs between the person who has the bucks (producer), the game’s ideologist (designer) and, finally, the end client (player?). Naturally, these three characters have different, opposing goals. There is the Art-Product duality and, of course, all the problems which stem from technical show vs. deadlines. Anyway, no matter the conflict, in the end the game is compiled code and that is what we programmers have to think and do.
One of my usual work methods is data-driven design, as exhaustively explained in the first Game gems book. It looks like a good idea and will generally work well. However, what is not as explicit is that you need artists to have quality data, or else you will suffer from the famous green-ninja syndrome[1].
It is usually reasonable to design data-driven software (unless the team is minimal or the game is very, very small), since it makes it easier to implement some useful features, such as allowing the users to design their own levels. In this way the programming tasks can be detached from level designing and maybe, with some luck, a modding community could emerge.
Talking of design, an interesting topic arises: what to do when a game’s design is not only data-driven but also procedural? In this way it happens that not only can different textures, models, sounds, animations, backgrounds, names, etc. be defined, but that you have no a priori idea of how a finished level will look like because everything can be modified.
Besides from stocking up with vast quantities of coffee and cookies, I advise you to factorize (less technically, put aside -ed.) all the code related to manual object creation. That´s the perfect candidate for a generic tool like, for instance, the audio manager. If besides factorizing you store references to parametrically created models and you use a “flush” method or any cheap trick alike to make the manager erase all things created, tada!!: Memory management+order+coherence+easyness to update, all with the same shot.
From now on, apart from the audio, inputs, outputs, etc. managers, I will add a fantastic “Creator of Parametric Unification”, or CPU, to my code. ed. note: the pun sounded far better in the original spanish article.
–
[1] That’s what happens when you use all the data included in the SDK, like the green ninja/green robot in Ogre3D. In small development teams, everyone ends up doing everything, which means that sooner or later you´ll have to make programmer art.
-This article has been translated from the original in spanish, which you can find here.