Lone developer

From GDWiki

To comply with our quality standards, this article may need to be rewritten.
Please help improve this article. The discussion page may contain suggestions.

Main Page >> Game Ideas | Lone Developer

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.

[edit] Preparation

[edit] 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 in case you have to let some go as the deadlines draw near.

[edit] 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.

Alternate Opinion:

There is also a school of thought that a Design Document is not necessary. In a team, the design document is used to communicate specifications and "carry the vision" of the project. When there is only one person this is not necessary. The game itself becomes the Design Document.

As your game progresses it's important that each area of design is evaluated and if necessary changed. Maintaining a detailed design documented may become unnecessary busy work.

There are many AAA titles that simply don't maintain a Design Document.

jay at jaykyburz.com

I'll support that. I'm a freelance IT consultant doing all sorts of programs (games included) and work better without one. Just adding my opinion out of my own experience. alex (no spam) at variasys.com

Another opinion: a design document helps fixing and remembering things, allowing the author to read his old reflections and move forward instead of reconsidering old problems and settled issues. A "vision" can be complex, and a game design is full of important and nontrivial details.

Considering the last opinion: While I am a lone developer, I have found that a design document allows me to think things through, and plan, better than just trying to remember what I've thought of doing. It doesn't have to be a formal design document, though. It could just be a notebook of ideas and solutions that you have come up with. mmanners <at> snu <dot> edu

Yet Another opinion: a design document allows you to record the rationale for why a particular design choice was made so that if you come back to revisit things at a later date, you won't have to rehash the same thought process / series of arguments / etc. The formal approach would be to create a requirements specification and have that drive the design document, but very few people can differentiate between requirements and design (i.e., most don't). Regardless of the tool or template used, it's important that you don't waste time by going back over ground that had already been covered at an earlier point.

A post mortem opinion: in study projects with teams of two or three would-be developers we rarely wrote a GDD, and yet achieved the goal stated at the beginning, nevertheless, I often found myself and my team wondering "why did we decided this?", "How was that system going to be implemented?", "Haven't we decided on this? - no, we decided on that" and the like... I agree that a GDD is not mandatory, but if you have the time, just do it, you'll be better off even if you don't realize it

And although these documents can't guard against poor designs, there are now programs available to assist designers with creating and using these documents during the development process, like The Corpament's Video Game Design Pro 2006.

[edit] Design Wiki

Instead of a design document, a more modern and useful approach is to create a wiki for yourself and your testers to use. Plan your designs, do your documentation, bug reports and put all your suggestions in a simple package. If your testers are worthy, they'll quickly point out serious problems in your design.

It will also give you a chance to modify things over time as you end up thinking of better and better ways to do things.

Most web servers allow you to restrict this to certain IP addresses, for example, you and your testers.

Trac is worth a look, since it is a wiki that also has built in bug-tracking, revision control, and svn browser.

Assembla is another free choice for svn repository and group management, documentation and coordination.

TiddlyWiki is also worth a look. This free wiki is contained in a single html file that can sit on your harddrive or USB stick. No need for a server or host, all you need is a browser.

[edit] 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.

[edit] Programming

[edit] 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.

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.

Alternate Opinion: Many people would argue the exact opposite of this. Your engine should do exactly what it needs to do and nothing else. Time is your number one enemy when developing a game by yourself.

Why take the time to implement a scripting language when you are the only person scripting the levels. The only reason to implement a scripting language is if you want non-programming developers creating game logic without having to compile. I say hard code it all.

jay at jaykyburz.com

Counterpoint:

However, hard-coding can become time-consuming in itself. For example, imagine having to recompile your entire game just because 'Light B' blinks twice per second instead of once. Implementing a scripting system will eventually allow the 'One Man Army' more agility when it comes to exploring new ideas.

swordfish at protonovus

Free Labor and Enhanced Criticism:

Hard coding may seem to allow faster development for the one man army. Consider how difficult it is to find reliable developers to work on your project. However, it can be significantly simpler to recruit your gaming buddies (or others) into non paid employees for your project. Rather than hard coding, you could create tools that'd allow people to modify maps, change settings, etc. Your buddies could make and tweak content while providing free testing for your game. You can find bugs faster, brew up excitement, and benefit from the added criticism. The entertainment value of this kind of activity is high, and you can probably get them to do it for free.

More eyes on your project means more suggestions and criticisms that may help your game achieve its full potential.

Or better yet, find an open source game engine that is already working. Tweak the code to your likings and make the engine do what you need. This will make a lot easier than making your own from scratch.

Another opinion:

Write only as much as you need to. Don't write code you're not going to use. Don't generalize when you're only using something once. But keep in mind which code might need to be generalized in future, and have it ready to be turned into general code when the need arises. If it doesn't arise (say, you get a real job, or you scrap the game and start on a different project), then you've saved yourself a lot of time. So for your AI engine, hard code it, but don't mix the AI code (or class) with the "non-player character" model/class. This will allow you to "drop in" a scripting engine more easily later -- the scripting engine will use the same interface as your AI code already does -- and you haven't spent too much time implementing a general purpose scripting language for v1.0.

If you don't even want to go as far as to get that layer of abstraction right, (because good programmers are lazy, right?) at least place obvious comments/hints throughout your code saying how you'll clean it up when you get around to it, so you know you're on the right track when (if) you eventually need to.

--Pengo.

Stick to what you know:

For the one man army or the few good men working independently it is very likely that engine design and programming would result tedious and if it takes too long might result in forfeit even. Unless somebody in the team actually LIKES engine development, try to avoid it; if you know any free engine that fits your needs use it; avoid taking an open source engine and trying to figure out how it works just to tweak a few things. If none of the team members knows or is interested in engine development, stick to the gameplay. There are tons of free engines for many different purposes and with lots of documentation an online support communities.

[edit] Coding Hints

If you love your code, rewrite it. If you do it properly, it will clean up things a lot and clear your mind (and code) of cobwebs, though it does push timescales and release dates back if you aren't careful. Be sure to document everything you do! Use the Wiki mentioned earlier if you aren't much for comments in the code.

Simplify everything. Your designs, code, game interfaces - EVERYTHING. We can all write complex code, and design things that need huge amounts of studying to understand, and who really cares if nobody else can understand it but the lone developer, right ? Wrong. Extended periods of coding, complex designs are all very well till you need to make a change, and all of a sudden you have to go through 15 pages of complex code till your brain starts to hurt. Break everything down into simple managable chunks. If your function/procedure/method/property/etc is more than a page of screen size, think about refactoring to make it simpler.

Pretend you have an idiot boss who needs to read your source code. If you have access to tools that display your code graphically, use them to add even more comments. If you are thinking "Comments are a time waste I could be spending coding", then use the time you are sitting in your chair, staring at the screen wondering which part of the program to work on next. Or the time when there isn't enough time to do the really cool bit of programming before the next episode of Star Trek/Stargate/Doctor Who/Whatever. Forcing yourself to do the stuff that sucks, will end up making you a better programmer in the long run.

Better yet, if you really hate commenting your code like I do, then use your design document. I just copy all of the UML from the design doc and code around it, leaving the UML intact. Works great. Of course, this is dependent on a design document. --kidmosey 22:41, 18 February 2007 (EST)

You may also use some of auto-commenting programs, leaving some tags for him. Like [Doxygen] -- C.a.l.

Some advices by Linus Torvalds. [1] or [2] -- C.a.l.

[edit] Tools

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. Besides, if next year you want to add a few more levels and release an expansion or new version, the tools will help you get back into the right frame of mind for the project quickly instead of pouring through the code wondering why you didn't comment everything as well as you could have done.

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.

Alternate Opinion:

Another approach is the config file style. As long as you use some persistant data file format (like the standard xml), and some well known easy-to-use scripting language (like Lua, Python or Perl) the game tools can be made by a third party.

Usually tools are left until last in the project, and come as an after thought due to the nature of projects they handle - you only need tools and the like when you start handling larger datasets.

genjix at gmail.com

Alternate Alternate Opinion:

Wherever possible use existing third-party tools like freeware/shareware 3D editors, texture editors, animation tools, etc. There is a lot of good free and cheap software available. It is usually better for the lone developer to adapt something using custom-written file format translators and data merge utilities than it is to spend a lot of time writing complex tools. And always look into programming libraries - there is an amazing amount of quality code to be had for just adding a blurb to your credits.

theAntiELVIS

Extending Alternate Opinion and Alternate Alternate Opinion:

For creating your first levels, it's actually good to write a quick and dirty text-file converter. That way, you can create your levels using ASCII characters and a simple 'properties' list where you can specify which ASCII character stands for which level object. That's not as comfortable as a graphical level editor, but it's better than using the hex editor ;) Another approach is to write a bitmap converter. You're then able to use MS Paint to design your (tilebased) levels: Just choose 8x zoom mode, and create your level by plotting pixels with different colors. Then also make a 'properties' file where you state which RGB-code resembles which tile in your game. It's also quick and dirty, but with both ways you're able to create your first few levels in a somehow comfortable way ;)

ZeHa

Using 3rd party tools/libraries also means if you manage to recruit other people to your project there is a chance they are familiar with these third-party free/shareware/open source tools/libraries and will not have to learn your editors/libraries.

foobat

[edit] 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 Windows 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 cues 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.

[edit] Multiplayer

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) game 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. (However, if you are not expecting excessive traffic, you could get a good hosting option for as little as 100 USD a month.) 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) architecture is worth investigating, as it may (or may not) suit your needs. 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. Firewall and Network Address Translation become more of an issue, too. 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.

[edit] Testing

[edit] Burnout

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.

Some developers usually release their beta sources to the general public for testing. The idea being, that with a large number of users any bugs get found quickly. There is also the problem of incentive on the users behalf to report bugs. For instance, if joe user found a bug that made him invincible, why should he report it? If he doesn't he may well be able to be invincible when the game is released. So how about, banning/disciplining the users who don't report? Well, there are problems here, in that if you're too strict very soon your gameplayers will start labelling you nazis and stop playing your game. An alternative method is to offer a reward for reporting bugs, such as free 'game' money, or a free copy of the game. But if the rewards don't outweigh the bug, then you still have a problem. The trick is to lie somewhere inbetween, harshly disciplining those who cheat, and rewarding those who help out (rare items, game money, etc). Take note however that if your game is a community open-source game, you don't have to deal with these problems as much, as gamers will happily report bugs to improve the game (and the large user base will take care of testing).

[edit] 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.

[edit] 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.

The Gauss Bell: when not obligated by clients, publishers, deadlines and the like, the excitement and dedication towards a particular project tends to follow this pattern, starting from nothing when you first get the idea light on, the excitement seems to grow exponentially non stop, but eventually it will have a rather symmetric falldown. Don't let projects be longer than they have to be, if you don't have a compromise it is likely you will eventually lose interest. Maybe you got a different idea, maybe you had a personal family problem, or maybe you just got stuck for the hundredth time on a bug you don't know how to fix and got bored. Make sure the project lasts a time that you can face and get to the end, make sure you don't spend too much time alone in one same stage of the development, variety is key to keep interest. Otherwise you might hear the bell toll and its good bye and good riddance to your project