SPOILERS ALERT! If you’ve not played Breakdown yet go do so before reading these posts as they contain, amongst other things, a full walkthrough!
Everybody likes different bits of game making. Personally I love coding – coming up with a cool idea, putting in a rough implementation of it, thinking my way around all the possible problems, tweaking the code until it works just right and finally sitting back and seeing it working perfectly in game. This is the reason there is, for example, a fully working sliding door in the engine room corridor.
Unfortunately there’s another side to games called artwork. Pixeling a character can be fun, and I enjoy doing some animation (though not walkcycles, everybody hates doing walkcycles), but you can’t build a game without backgrounds and characters.
When it comes to putting the game together in AGS I focus on the areas I like doing (programming and writing) and do as much of those as I can until I have to draw the next bit of art. This way you can motivate yourself by thinking about all the great things you’ll be able to do once it’s finished.
With big things like backgrounds I also go through lots of versions. When I first start to put in walkable areas, walk-behinds and major hotspots I’ll have an accurate line drawing of a room. By the time I start to put in objects or do animation I’ll have at least coloured it in. Finally I’ll get fed up of looking at it in it’s half-finished state and put shading and texture in.
The same goes for the main character. When I’m just setting up rooms in AGS I only really need one standing graphic for the main character. When I’m testing walkable areas and putting in FaceLocation functions I’ll need all four directions. Finally I’ll get fed up of looking at them sliding around the floor and put in the walk animation… at least for one direction to start with.
Sometimes I do things that I don’t need yet, to avoid doing something more productive. For example the main character has a full set of speech animations. Later I decided to have them never speak, so none of them are ever seen in-game.
From this point it’s just a case of going through the cycle of Implement – Test – Improve until each piece of the game is at an acceptable level of quality.
I also try to work on sections of the game according to importance by dividing them into a set of categories:
Must be in the game
These are things that are vital, so the requirements of the competition must be met, major game breaking bugs must be fixed, the game has to be completable.
Really ought to be in the game
Almost vital things. All other game-breaking bugs need to be fixed, there should be a story or something to tell the player what they’re supposed to be doing. Walkcycles.
Nice to have in the game
These are the areas that start lifting your game out of the average. Nearly all bugs need to be fixed, everything that’s vital to completing the game should be put in and fully interactable and you should start adding in extra items/interactions that aren’t necessary but add to the atmosphere or humour of the game.
Would make the game really good
This is where I would start putting in sound effects, music, extra animation, title screens, cutscenes etc. Basically the icing on the cake. Masses of testing leading to 100% of bugs eliminated.
Would be awesome
Unfortunately this is where my plan to have loads of death sequences fell, so it never made it. Basically this category is where you put your ideas that realistically are never going to make it into the game (under the current time limit) but, if you were to discover you had an extra couple of days, you could put in.
In reality I don’t religiously stick to these boundaries because 1) I wouldn’t want to release something that wasn’t at least in the ‘Nice to have…’ category and 2) I have a habit of avoiding boring (and vital) parts of the game while I make something fancy and fun.
To be continued…