Tower Defence! and Design

Okay, I am going to attempt to make a start at this blog by talking about a project I am working on at the moment. Points go to those who guessed from the title that it is indeed a tower defence game.

One of the problems I encountered when starting the project was the sheer number of things you need to create a game, not just a cool tech demo, but a real game. I am going to assume that if you found your way here there is a good chance you have played a tower defence game, it might not seem like much, but when you start adding up all the features you realise there are enemies, towers, map, user interface, artificial intelligence, state management, input, sound, graphics (and networking in my case ) 'Audible Gulp'.

Now each of these in isolation is fine, but the trick with the game is there are relationships between these objects, and certain objects have to interact and update other objects accordingly, and in order for this to happen you need lovely code to properly initialize, update and finally clean up all of these things. The trouble is how you go about doing this.

Enter Software Engineeing! If you talk to anyone who has written a large piece of software they will tell you design is king. It is much better to spend longer on the design, and get it right, than start implementation, and have your shoddy plans fall apart. The only problem is, designing something, when you don't really know exactly what you want, or know the best way it should work, or how it should fit together, without a great deal of experience, is extremely difficult. What exactly do you do then...... Enter Tom!

Now I am in a small conundrum where I know design is important, and I do have a (flimsy) design, but there is also a desperate need (especially given the impetuousness of youth) to see results, and that can happen quickly if you throw design to the wind, and break open your tool bag of tricks to get stuff up on screen. This is intensely satisfying, but often you'll find that your hacking has created a hole (sometimes a black hole) that is now inescable and you find nothing else will work with your new change. The design falls apart and you are left with super glue and nails where girders and beams once stood.

This is the problem with writing code, when you are dealing with something that is intangible, you need a grasp of the structure and design of the software, not just small parts in isolation of one another. But to create that amazing design, you need to know what designs work, and when to use them, and to know this you probably have to fall, at least a few times.

I apologise for my mad ramble, but I find it is a difficult subject to talk about. I do think that it is a trap all too many programmers fall into, but it is one laid so expertly one can hardly blame them. In working on this project I hope to strike some kind of balance, I'll let you know how it pans out!