Programming

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.

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.

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.

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