The technical aspects of making a computer game. General guidelines, lessons learned, best practices, call it what you will.I assume you already know what kind of game you want to make. This means having either an idea of an interesting “twist” to an existing genre (“Hey, let’s make Tetris with different shapes of bricks!!!”, “Hey, let’s make HL2 with a Star Trek theme!!!” etc.) or a new type of game (“Hey, let’s make... a completely new type of game!!!”).
- Make a prototype. The most important thing is how quickly you can put it together and see if your idea works. It may look and sound like crap and crash all the time – that doesn’t matter. It’s for you and maybe a couple of your friends so don’t waste any time making it look good. If your idea doesn’t work, you can delete it and try again. A week or two is enough to make a game prototype.
You can take an existing game and implement your special “twists” there – many games support “modding” and there are also many games released with full source code. - Write a design document. There is a nice guide on writing a design document on Gamasutra: www.gamasutra.com/features… Keep the design document updated.
Pick the right technology... but don’t spend too much time on it. There is no silver bullet and you should spend the majority of time developing the game, not evaluating all game engines in the world.
It should allow you to do the things that set your game apart. If you want to make a physics-based game, you’d better be sure that the physics package you pick is top notch and won’t let you down three months into development.
Many people still use C++ for making games. I prefer Java but to avoid making myself look too biased... let’s just say it is good to look around before going with C++. At least have a look at Python, Java and the game-oriented Blitz family of products/languages.- Use source control. Here’s a nice article describing what it is: en.wikipedia.org/wiki/Revi… - basically a big infinite UNDO for all your files. Subversion is what I prefer but it doesn’t really matter what system you use as long as you do use one. Once you get used to it it gives you great confidence to experiment with your code on a daily basis, which often results in great new things.
- Automated builds. You should be able to go from a changed source file to a new install package in a single click. Use plain batch files, Ant, scons, Final Builder, whatever suits you. The build system should compile and link your source code, process the game data and make an installer using NSIS or similar, for all your target platforms, custom builds (ie. for portals) and language versions. Avoid using any important tools that cannot be used from the command line because they cannot be included in the automated build process.
- Portable data formats. Don’t invent new data formats. Stick to plain text files or XML. Make sure you can programmatically read and write all data in your game. This will allow you to modify the data structures because the existing data can be easily converted into the new format. You can also access the data from the editing tools...
- Editing tools. Create editing tools for the in-game data – maps, levels, characters, items, dialogs, puzzles, everything. External editors are fine, and you can use tools that are better suited for the job (such as different languages, better GUI toolkits or export plugins for various existing authoring tools) but on-the-fly editing directly in the game is also great. Your choice.
Create and maintain good workflows. This relates to the previous point - don’t rely on editing anything by hand and make the “turnaround time” as short as possible. How do you get the graphics from Photoshop into the game? Is it quick enough? Do you have a special level for stress-testing new code, such as enemy AI or physics? How do you add new sounds? Can you quickly start the game at level 15 to test just that one?
