Navigation
|
Small Steps
Beware The Title Screen Monster! At the very start of your project you could take a wrong turn and head off down the route of spending an inordinate amount of time developing the front end of the game, i.e. the title screen, options screen, etc. Title screens are magnets for wasting time. You can spend forever tinkering with graphics to create a great splash screen and before you know it weeks have passed. Ive known developers who have a nice collection of title screens but then they lose interest or run out of time before they get anything substantial behind it. However, if you are developing the title as part of a team, then this is a convenient place to split development tasks. Simple Movement First of all we need to get the very basics of the game engine working. Aim for something like a simple square moving around the screen via keyboard control. At this stage it would be all too easy to add a frame rate counter and start getting concerned that you are not getting x hundred frames per second. As long as the on screen movement responds to your control, you do not need to worry about performance at this stage of development. From here you can begin to build things up. First try adding walls to block the sprites path or for the sprite to bounce off. Next try adding gravity and other simple rules of physics. This is the stage were thoughts such as, I wonder what it would be like if I added another wall here, or another seven layouts as different levels? may creep into your mind. Level Editors Level design may well lead you off track for a while or bring you face to face with one of the big time-eating monsters The Level Editor! The Level Editor is a cunning creature; it takes you in with its user-friendliness and its alluring promise of Im nice and easy for you to write. However, once it is working, it turns around and bites you, as you end up spending all your time adding lots of tweaks and nice extra little features. Sure, those who end up using the editor and helping design your levels will thank you for those nice features, but how happy are they going to be when they discover that the 120 levels they have created are pointless because there is never going to be a finished game to play them in? The way around this is to hardcode your first level until you get everything working. At least with a hardcoded level you know where the problems are if it doesnt work, instead of the added possibility of the problem being in data loading routines and other such things. Of course, allowing someone else to write the level editor is an option. However, unless you have written a very detailed specification and are 100% sure you will not be changing anything, then it is far too early at this stage to be doing this. As you build your game engine it will evolve and at the early stages a simple change of ideas may change the whole fabric of the levels and their data. Remember to keep using simple graphics or graphics from a previous game. At this stage of building your proof of concept engine, you dont need to worry about what it looks like. Worrying about your graphics this early can lead you wandering around in circles forever. Add some alien sprites to the game engine. Dont worry about their interaction with the player for now. Remember to keep taking things in small stages that let you see you are making progress. Add the ability to allow the player to fire some kind of simple bullet. Firepower is another area where you could easily wander off the path. The joy of seeing the first weapon working will no doubt get your mind racing about what other fancy weapons you could add. You could easily find yourself spending days adding more and more weapons firing bullets at different rates, in different directions and colours all over the place. Resist the temptation, because you can always go back and expand things later on when a solid game engine is working, or when you are waiting for feedback from any beta testers you may have been lucky enough to find. Of course if you are working as a team then why not split the tasks here and let someone else work away on the additional weapons. Add interactions between the aliens and the weapons and you should have a fun engine, which may steal some more of your time as you move around shooting everything that moves. Add in scoring and lives or energy for the player and you have a simple, but playable, game. Now is the time to think of adding some graphics. Since the game actually works, it is very easy to see what the graphics look like in action. If you have someone doing the graphics for you, they can see straight away how their work looks and then they get that instant rewarding feeling too. Title and Other Screens At this stage you are at a crossroads. Do you go on expanding your engine and increasing the game play, or do you now turn your attention to the title screen? At this stage, I personally would move on to the title screen. By now your game has an ending when the player is killed, so it also requires a start. Just go for something simple for now. Also now would be a good time to add a simple options screen. Up until now the game controls would be programmed for your tastes, but adding the ability for the player to configure the controls as they desire will give your beta testers an easier time. A Little Sapling By now you should a have a simple, but complete little game. From here you can go on expanding the individual areas already created and adding new features. However, remember to try and keep your game fully playable from now on. Always having the game playable means it is easier to let people try it out and give you feedback. Try not to overreach and add some exciting feature that causes everything else to break. Dont be tempted to add something else before finishing the current feature you are developing. I hope this article has provided some useful advice and an insight in how you can grow a game whilst avoiding the pitfalls that await the novice, and not so novice, game developer. About the Author Andrew Sage has been dabbling with games writing over the last 20 years on various platforms ranging from the Sinclair ZX Spectrum, Commodore Amiga, Windows, Palm and since February 2002, Mac OS X. During this time he has managed to complete a large percentage of projects started and even made a small amount of money selling some of his creations. Currently he is working on, amongst other things, a book entitled Cocoa Puzzle Games: Learning Cocoa the Fun Way and actively seeking a publisher. Article Copyright (c) 2004 Andrew Sage |