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.
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
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
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 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
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.
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
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.
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
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
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.