Game Design

Ryan Clark
Copyright Jan 19, 2000


Page 1

Game Design - Tips for the one-man army.

I have read thousands of pages of information regarding game design, but only rarely have I seen discussion directed at the lone developer, the "One-Man Army." I know that there are many of you out there, like me, alone or with small supporting groups, hoping to compile your myriad keystrokes into a playable work of art. Doubtless there have been times when you've wondered whether it actually would be easier to get an infinite number of monkeys and an infinite number of compilers to see if one will code the next Quake killer. Well I say to you, lift your mind out of that blissful monkey-gutter and take heed. Small developers need to work smarter, not harder, and here are some ways to do it.


The Concept

Make sure that your game idea is something that sets your imagination ablaze. You are going to be working on this project for a long time hence, and if it doesn't positively tickle your fancy right now, you can be sure that any tickling will end after the honeymoon. Talk to your 'game playing' friends and see what they think. If you can't get them excited about it after five minutes then your idea probably isn't that good. The initial thrill of the concept is what gets people to buy games, and if you can't thrill your partisan friends, how can you expect the gaming community to be thrilled by the description on your box or web-site?

Coming up with a great idea is one thing, but you also have to be realistic with your vision. You know what you are capable of achieving, don't fool yourself into thinking you're better than you are. Design with your limitations in mind and you'll have a much easier time when you finally start to code. Never let your imagination run completely off the leash and then try to stretch your technology to fit it, you will end up with the computer game equivalent of a fat man in spandex.

Have a brainstorming session with anyone that you feel has good insight into games. Come up with as many 'cool' additions to your concept as you can and be sure to write everything down. After the session, take your notes and carefully craft a feature list from the ideas that please you most, only you truly know which are going to be feasible. Split your list into three sections: Required, expected, and hoped-for. All of the ideas that you believe are needed to make your game complete should be flagged as 'required'. Any ideas you know would add greatly to your game but are not essential should be 'expected'. And finally, those far-out and possibly difficult to implement features that you've conceived should be labeled 'hoped-for'. Later, when identifying your milestones and deadlines, take these three categories into account. You must ensure sufficient development time to include all of your 'required' features and as many 'expected' ones as possible. If you have time left over afterward, try your hand at some of the 'hoped-for' ideas, but don't get too attached to them incase you have to let some go as the deadlines draw near.

The Design Document

There are divergent theories regarding the purpose and creation of the design document. As I see it, for the small developer it does not matter so much how you make your design document so long as you make it concise and complete. Ensure that your design doc describes everything in your game, from top to bottom. If you're going to have to program it, record it, or draw it, it should be in this document. Describe the functional specifications first, and only when this is finalized should you create the technical component. Describe every algorithm you intend to employ and every solution you intend to implement. If you can't think of a solution for it now, don't include it in your game. Never assume that you'll "figure it out when you get to it."

Keep your design doc as modular as possible so that it can be easily added to or subtracted from. If you need to make changes to it down the road you should be able to do so without disrupting any unrelated items. Having said that, I must now emphasize the importance of sticking to your document once it's complete. Of course it is wise to allow for the possibility of change, but as much as possible you should keep your design static. It is very difficult to hit a moving target, and we all know that hell hath no fury like a programmer scorned.

Once your design doc is complete, coding should be a breeze. You'll already have all of your solutions identified and you'll have a complete list of items that need to be implemented. Just go through the list (in order, have discipline!) and barring any major design changes, your game development shall press forward like little girls at a Backstreet Boys concert.

Deadlines and Milestones

Even the one-man army must make milestones and deadlines for himself. Whether you have a publisher or not, it is a beneficial practice. When you pass a milestone it's kind of like getting a pat on the back, you know you've done well and it makes you feel good to know that things are progressing. Additionally, the presence of deadlines and schedules will entice you to do what needs to be done and to do it on time. Without these constructs the development path becomes blurred and you will find yourself straying to work on items further down the path simply because that's where the 'fun bits' are. Development is undoubtedly most efficient when undertaken logically and sequentially, so make your design such that this process will be as painless as possible.

Peruse your technical and functional documents and extract what seem to be the most important milestones. Apply to these milestones reasonably generous deadlines wherever possible. There is nothing worse than the feeling you get as you see your deadlines flying past and you realize that you are slipping, so keep this in mind.

If your project has no set ship date, allow as much time for testing and QA as you can. It is impossible to predict what problems may arise during these times, so it is best not to try to compress the schedule. You will know when you are satisfied with the quality of the product, so ship when you're good and ready - one of the advantages of being an independent one-man army.


The Engine

I hate to state the obvious, but it's what I'm good at: Make your engine solid. Do not skimp on the development time you spend here, you will pay for it later if you do. Would you rather buy a car with a German motor, or something made in Cuba? Spend time on your engine until it is complete, never assume that you can patch it up and hold it together as you go. Duct tape can only do so much, even Cuban duct tape.

Make the engine as general as possible. If you hard code anything naughty into it you deserve to be thrown in the Sarlacc pit. Allow for as many details as possible to be file driven. Every world, level, or character should be loaded from a file created by your in-house tools. Try not to describe AI in code either, create a scripting language and allow everything to be interpreted at runtime.

I am a proponent of object-oriented design. Any performance decrease you may encounter will likely be negligible since the one-man army is rarely trying to create cutting edge polygon pounding products like the big-boys. Lone developer games need to impress gamers with their style, originality, and gameplay, not speed and flashy effects. You will therefore likely have enough leeway to incorporate an object-oriented design. This will allow you to integrate new unexpected items (and they will arise, no matter how hard you try to stick to your design doc) more easily and it increases the overall robustness and reusability of your code. Reusability is of prime importance to small developers; anything that can cut down production time for the next game is like money in the bank.


Gentlemen, start your engines! This is where all the hard work you put into your game engine will start to pay off. In the real world of game development, the programmers are rarely the ones designing the levels or setting up the world. They need to create user-friendly tools to allow game and level designers to interface with their beautiful engine. Things such as level builders, character animators, AI script writers, etc, will all facilitate and expedite the jobs of the designers.

I can hear the one-man army saying "I don't need tools, I do it all myself," but I don't believe this to be true. Your game will end up looking more polished and refined in the end if you have easy to use tools at your disposal with which you can tweak your levels and get the most out of your engine. It is very hard to tell what will be fun before you actually try it, so allowing easy modifications through the use of tools will give you the power to tweak up the level of fun with minimal effort.

Make your tools as reusable and general as possible while still maintaining their utility. Think ahead to your next game (or games) and try to ensure that the tools as a whole, or at least some of the code, will still be useful. Lone developers are usually not as affected by hardware advances as are big developers, so tool reuse is quite plausible and beneficial.

The Interface

The interface should be as unobtrusive as possible. When the player doesn't need it, it should ideally not even be there. Make actions available to the user only when they can be performed, give the user information only when it is needed or requested. By accomplishing these goals you can ensure that the player never loses his sense of immersion in the game world. The longer you can hold him in there, the better. People play games as an escape or release, they do not want to have to deal with uninteresting or extraneous information like they do in real life.

In order to keep the player immersed, seek to avoid any harsh 'reality checks' such as loading screens or menus that don't seem to flow with the game. It's similar to what happens when a 'blue screen of death' pops up while you're madly coding. You are awoken from your WinDoze and you realize that the world is not a happy place full of icons, menus, and 'for loops'. Don't do this sort of thing to your players; you know how much you hate it when it happens to you.

Intuition is the language of the soul, and the game player. Seek to exploit any previous knowledge or habits that your target audience will have. If you're making an RTS, for example, ensure that you include items now standard to the genre such as click-and-drag selecting and shift-click to add to group. Try to use obvious, unambiguous, and habitual metaphors for your buttons and mouse cursors. When a player can't walk in a certain direction, change the cursor to the big red 'no' symbol, or give audible feedback; ensure that you give him ample queues to that effect.

By far, the greatest thing about interface design is that it is just as easy for a lone developer to create an outstanding interface as it is for a large developer. It costs little to implement these sorts of ideas since all it takes is ingenuity and a little savoir-faire. Set your phasers on stun and try to wow your audience and out-do the big-boys. This is one of the few areas where you may succeed.


Is multiplayer required for your game? Most people nowadays are quick to say yes to this question without properly thinking it through. In truth, not all games really suit multiplayer action. I know I wouldn't want to play a turn-based strategy (TBS) against seven people over the internet; it's bad enough waiting for the computer to take its turn in a single player TBS game, let alone a human. If nobody is going to play it, should you bother to include the option? If you feel your game will sell more units if it has the word "multiplayer" on the box, then go ahead, but if you think that decreasing development time is more important, then I'd advise you to drop it.

Now, truly there are many games that do suit multiplayer and would fail without it as an option, the RTS and FPS genres to name a few. Deciding on the solution you'll use for programming the multiplayer feature is a critical one for the lone developer. You likely have limited resources and paying to maintain a dedicated server is probably not at the top of your 'things to spend my money on' list. You need to put a lot of thought into whether you're going to go with a peer-peer or client-server system.

Peer to peer (P2P) is definitely the way to go - if you can make it work. Sending packets directly between the systems involved is certainly faster than bouncing them off of a server, but it can start to become costly as the number of players involved begins to rise. A two player game is ideally suited to P2P architecture, but as more players are added each system has to send (and receive) increasing numbers of packets in order to inform every other system of its game state. Packet loss or lag can cause fragmentation, and your code would need to be quite robust to hold high numbers of lagging systems together in a P2P state.

With a server, however, the burden on the individual systems is lightened. A client's sole duty is to keep the server up to date, and it is the server's responsibility to inform the appropriate clients of these updates. The indirect nature of information transfer in a client-server mode can increase lag, however. Data flows from client to server to client rather than from peer to peer. The intermediate server step can add to delay and have adverse effects. Ever play that old game 'telephone'? Similar misunderstandings can occur as a result of lost or late packets from the server. Fragmentation is not an issue, however, the server can hold the world together effectively, only losing individuals if their lag becomes too great.

Setting up a dedicated server of your own can be costly and is obviously a deterrent for use of the client-server method, but allowing one of the players to act as a server can solve the problem. If the player with the fastest computer and best connection starts the game (acts as the server) then this method can be employed effectively. It is a tempting alternative indeed for the lone developer, and one that I would recommend investigating.



There's nothing worse than the smell of burnt toast - when it's coming from one of your tester's craniums. Testing is obviously vital to your game's success as the public and media will tear you to pieces if your game is found to be buggy. It is important, therefore, to keep your testing schedule light and varied in order to prevent the burnout of your testers. When they look at the same levels over and over for days on end they're bound to become lax and miss a bug or two.

Switch it up. If you have any other games in development give your testers a variety of tasks. You must destroy the assembly-line feel of testing since it numbs the mind - the very thing you need at peak performance for effectiveness. If your game has a multiplayer option, use it as a reward for your testers, let them test the multiplayer after a hard day in the trenches. Keep the balance between multiplayer and single player testing appropriate, however. If your game is mainly a single player offering with multiplayer as a bonus, ensure that the single player aspects are sufficiently emphasized.

Fun Factor

Bring in testers from outside your development group to test the playability and fun factor of your game. Let the tester play the game uninterrupted and unaided to see where he has the easiest time, where he gets killed too quickly, and where he gets stuck. If you have allowed enough variability in your engine and your tools, you should be able to tweak and tweak and tweak until you make the levels fun. If your engine was too rigid to begin with you may find that your game isn't fun no matter what you do, so beware.

During your observations you may notice that a puzzle or course of action that seems completely obvious to you will be anything but obvious to an outside entity. Ever try opening one of those childproof bottles, and fail? That is what your testers may feel like, so be sure to nip it in the bud before it's passed on to the consumer. Nobody likes to feel like an idiot.

Be conscious during your design to provide 'fun' at a steady pace. It should never be a breeze, nor should it be impossibly hard. You should, additionally, allow the player to go at his own pace. As seen in FPS games, you go into a room, kill some monsters (fun) and when you're ready for more 'fun' you venture forth once again. Don't fluster the player with a deluge of monsters and action at all times, give them a chance to dictate the flow of the game. Testing is imperative in getting this right, it simply isn't something that you can predict with any accuracy during the design phase.

When people run out of 'fun' they stop caring about the game world and start trying weird things. They shoot at their wingmen and try throwing fireballs at villagers. You don't want this sort of thing to happen, so take the feedback from your testers seriously. When you are told repeatedly that something isn't fun or that something else is, you should listen. You are likely too involved in the game to see the truth of the matter.

Some Closing Tips

Read everything that you can get your hands on regarding game design. Regardless of the fact that most of it is written by the big players in the business, the fact of the matter is that the community is mostly made up of small developers like yourself. The data is still relevant and can be bent to suit your needs. I find postmortems are especially informative as they allow you to see where the big developers went wrong, and how your game can avoid a similar fate.

Continue to play games, lots of them, and of every kind. But not only should you play them, you should study them. You must first know your enemy and his tactics before you can ever hope to defeat him. Find out how Quake has trained you to drool at the mere mention of the word "frag." Why does Pokemon melt the brains of small children? What is it that makes the Warcraft series an enduring classic? In other words, ask yourself what game developers are doing to stay on the top of the heap, and soon you'll be up there shoving 'em off.