Creating and Managing a Computer Game Project

I am a great supporter of Indie game development, and love to see what small games people make in their free time.
After creating a small game many people try to make a larger one, and then feel that they need a small team to help them along. This Ible covers trips and tricks that I've picked up from my own computer game, DEEP Space, that I've been working on for more than a year.
This does not only apply to computer games, but also to other web-based team projects.

Making a game is a big task, that takes a lot more time that you think. A professional, paid company takes over a year to produce a good game, so don't expect you to produce an amazing title in a month.

Also, people often drop out of un-paid projects, so be prepared to do everything yourself.

Before you start to think about getting other people involved there are several key choices to make:

1. What game engine are you going to use, or will you code one from scratch?
2. What will attract people to your game?
3. Who is your target audience?

I try to keep things open source, so as a game engine I chose to use Blender's internal game engine. Other free options are Unity, Spring and many others. Have a look at the wikipedia page for game engines.
You choice of engine may be influenced by things like:

• Programming languages you know
• Licencing of published games
• Game-play type. (ie Spring is for RTS only)

When you create a game you have to think about who will play it and how they will find out about it. As I found out, making a game is 10% developing and 90% promoting.

• Most game projects have a website, for consumers and developers.
• Publish WIP versions of your game on the web.
• Make posters and distribute them on the web.

You also have to think about who will play it. What makes it stand out from other computer games? There are millions of FPS's and RTS's, yours must be slightly different to make an impact. But it can't be so radical so as to turn people away.
Make sure you have an audience.

Nothing beats pen and paper for this stage.
A name is an important thing to chose. I chose badly, picking "Defender" as my initial name. 4 months later someone told me that "googling defender.exe produces a virus." I then spent the next couple months deciding wether to change the name. It was a big task, as you have to re-brand everything, from script headers to posters to forum thread titles to website domain names. So pick a name that tells people about the game, isn't ambiguous, then, Google it to see if it has been taken by another company, or represents something you don't wish it to.

You must also come up with a story time.
Make sure you make the story-line believable and detailed. It will be the base for everything later in the game. Once you have set a story, don't change it either, unless there is a serious objection for it. It's not quite as bad to change as the name, but it is still an effort.

Creating a consistent style is rather important. No-one would dream of mixing 16x16 pixel textures with very good 3D models, simply because the effect would be so weird. The same applies for smaller things. Pick an overall style and communicate this to any concept artists. Styles can be things like:

• Dark industrial
• Post-apocalyptic
• Fairly tale
• Cartoon
• retro-futuristic
• dated

When you are developing make sure the menu's, models and textures reflect this, otherwise the resulting game won't fit together nicely.

There are a few sneaky surprises that caught up on me part-way through developing.
One of these was the filing system.

When you buy a game you don't see hundreds of images, textures and sounds in the same folder as the executable. Rather they are sorted neatly into folders with sensible names like "Textures" or "Sounds" Planning this is key to good developing. As is planning how you get models from data files into the game files.
Be specific and make a document that communicates this clearly to team members. Have a look at my sheet to see what detail I went into. Things like:

• Folder names
• File-types
• Contents of data files

You can also plan a time-line, but I would advise waiting until you are well into the project. There is nothing worse than having to rush to meet a dead-line, and having to go back later and fix up a programming botch-job. Pretty much everything takes longer than you think. I had planned for my game to be finished in about a year, now, coming up on it's second anniversary, there's still quite a bit to be done (but the end is in sight).

Also plan out communication with your team members. IRC is a good system, as is file-syncing with a system like dropbox. Setting up a website is a good idea about now.


The next three steps should be done at roughly the same time. With you doing the third, as bits of the other two are done by others.

Now you have enough information to get a concept artist onto your team. 
There is a lot for your concept artists to do. These include:

• Menu's (including high-scores, in-game menu's)
• Player character(s)
• Enemies/challenges
• Levels (I feel I need more than one word for this, it is a large challenge)
• Game-play features (HUD's, props)

You don't have to wait for them to finish before you can move on to the next step.
Anything from pencil sketches to publisher vector graphics, to 2D painting works. Text documents along with the concepts help explain.
Concepts should be approved to fit with the style before they are able to be included in the project.

Time to get modelling. Get those concepts into 3D models, or sprites depending on what sort of game you are making.
You can have specific people doing modelling and texturing. People have different areas of skill, so let people do what they are good at.
Myself I can model and code well, but had to give the texturing up to some-one else.

There are a lot of models, so it pays to get started on this early. Don't worry about levels at this stage. Menu's too, can be ignored unless they require complex modelling.

Time to code and put everything together.
It's best that one person does this, probably you, as the person running it. This helps prevent confusion.
You take all the models, put them all together in a logical file-structure. Separate out textures.

Start coding. Get user/game interactions right, start working on the menu's (they are more coding than modelling you see, that's why they fall under this category)
Use a blank level for testing, or add obstacles for testing AI, collisions and such, but don't fuss with proper levels yet.

This is one of the hardest parts of the game, as it takes lots of motivation from you.

Here's where your prior planning really comes in useful.
If you coded and planned well, adding levels should be a breeze.

For my game, the level-select menu auto-detects new levels in a level folder, and since the levels know all about themselves (logic and all) it's just a case of putting the levels in the right folder and hitting play.

I'm not here yet, so from here on it is just what I hear and think. If you know better than me, let me know.

Hopefully you have got a website set up, as well as spread those posters around. Now it's time to go back to all those sites, and post a download link (or if you are selling it (pah), a buying link). If there are forums of people who play your style game, then post links there. Put a link in your signature. Do your best to let people know about it.

Sites like sourceforge offer free hosting for projects like this. Chose a place that doesn't require signup to download, and uses as few-er clicks as possibly to actually download it.

Make the executable file available in as many formats as is possible. Some game engines (like XNA) only allow windows, and this restricts your audience. Try to keep everything as cross-platform as possible.


Some more detail on creating computer games can be found here