Anyone who has ever written any code will know that sometimes, you just want to rewrite what you’ve already done. Maybe it’s because there are bugs. Or maybe it’s because you’ve learnt a new way of doing things. I’ve recently come to the realisation that in games, there is another: code that just should be thrown away. Allow me to explain…
In traditional software development, at least in my experience, I’ve always been fairly certain of what I was going to develop and how I would do it. There may be the occasional design meeting where you need to think about how something will work, but usually, that’s all details of the user interface.
In games, by contrast, it’s very hard to know if a game will be fun without first playing it. But in order to play it, you need to make it. This is a bit of a circular problem, as you don’t want to spend months or even years making a game if you don’t even know if it’s actually fun or not. At the end of the day, we all want the games we make to be fun.
So, with games in particular, I find quite a fair amount of effort is put on prototyping. Prototyping generally involves making part of a game, usually a specific mechanic or two, to test out whether or not an idea works (and is fun). Prototypes can be as basic as a few cubes moving around, or as complex as a full level from a game. The later would take a large amount of code, depending on the number of systems you have that interact.
On our current project, I’ve had to do some similar things. Whilst not strictly prototyping, as it actually making the foundations of a game, I’ve still found myself writing code, only to then delete it all. But just because I’ve deleted code that will not make it into the final game, does not mean it was a waste of time.
That experience of writing something helped me to figure out what worked and what didn’t. As a programmer, I always like to lie to myself and say that my code is perfect and never has bugs. But in reality, I know this not to be true (any programmer who actually says this is lying… if they’re not, please tell me who this genius is). Sometimes I’ve spent hours and hours writing code, dry-running it in my head thinking “this will definitely work” and “I can’t possibly go wrong here”.
But games are very complex systems. Sure these days there are loads of engines and stuff that do so much hard work for you, but they only do so much. Gameplay mechanics still need to be developed. And unless you are just learning and copying an existing project, it is likely you need to come up with your own logic specific to your game.
With games, I’ve often found that something that makes sense when you think of it in your head doesn’t always make sense when it translates into an actual game. This is why prototyping is so important. The other need for “throw-away code” is when you are focused on testing part of your game, but it would usually require a bunch of other systems you are not ready to develop. These are often shortcuts to certain point within a game, or a way to give the player weapon x or upgrade y.
Have you ever noticed in some PC games there is a “console” where you can type things and things happened? That is a game dev creating a shortcut so he can automatically test out some awesome new thing he made without having to play through the entire game. SO that is not example of code you throw away (since it’s still in the game), but I’ve found myself doing that. Maybe I want to just be able to make an enemy appear so I see how the player attacks. I don’t want to have to go and find one, or wait for the AI to find me, I want it to just appear. So maybe I’ll create one when I press a specific key.
I could go on and on about this kind of subject in more technical detail, but I’ve rambled enough. The point I’ve long-windedly tried to make is this: in games, you sometimes need to write code that you will never actually use in your end game, because it is important to make sure your game is fun!
Thanks for reading. Stay tuned for more random musings and observations…