Warning...longish post ahead!!!

In what must be something of a first, I managed to get a blame 3 times in row! It started with memory leaks, followed by a heap corruption, followed by another memory leak just for good measure. All of these I readily uploaded to our repository in good faith whilst proclaiming loudly each time that "...this time it's working, really!...". Thanks to some great debugging team work from Andrew and Josh, the twisty logic that I was working on succumbed to their combined mental might, and the code was uploaded cleanly much to our relief.

Which leads me to conclude that the more well planned a design is, the easier the implementation will be. Now for me, I had previously thought the creation of a game was an almost organic process, with the element of what we call "fun" something that emerges out of playing and tweaking and developing during the writing of the software. However, with a more detailed plan of the logic and complex interactions that I was attempting to code, I might not have spent so long debugging the errors.

What I'm thinking of is, if you take any game, say Monopoly for example, it has a set of clearly defined rules and interactions that dictate exactly what may happen at each step of the game, and clearly specified results. If an interaction occurs in some point of the game that is not specified by the rules, it is then over to the players to work out amongst themselves what outcomes should apply. Generally this is not a desirable thing to occur for a board game, and should be minimised with clearly thought out and detailed rules, but does not necessarily prevent the game from continuing provided the players agree on a compromise and then proceed with the players next turn.

However, what happens with a computer game when something occurs that is outside of the logic that has been written for the game?...Well, one of two things...either the event cannot occur, which is a powerful feature of computer games, automatic enforcement of a gameworld for a player to express themselves in...or, in a more dramatic scenario, the software will simply crash or hang, leaving the game player stuck with no other option but to restart the game, or give up entirely as the prospect of having it crash again may be too discouraging.

So then, to my long beleagured point, it's clear that the details really are the most important thing to pay attention to when designing a game. It may occur to some (such as myself) as killing the creative process by requiring a fixed design from the start. This is not really the case, as there is always scope to make changes if necessary.

The real benefit comes from being able to quickly create the software of a good design, as the logic has already been thought out in advance and the actual implementation becomes trivial. As the development time to get something up and running is now shorter, this allows for more playtesting of the actual game to take place, which in turn allows more time for tweaking and adjusting to balance all the elements into something known as "fun"!

ergo, do not skimp on planning and design!
Paul

p.s. Milestone submission was a day of intense focus and rapid last minute debugging. With plenty of time to spare (30 seconds to be precise) the submission was electronically sent at 4:59pm today and we all left to get some much needed sleep!