Delivering your first game on time

I am at the tail-end of a hectic 3 week racing game, and have come to realise that this is the sort of game that a beginning programmer may want to get into. It is not revolutionary, innovative or even particularly noteworthy, but it was developed on time with a small budget and with little prior knowledge of Torque itself.

To aid the novice developer, I have collected a series of important points that I feel contributed to the success of the project. For most of the points, I have pulled real-life examples from this project to compare against. Do note that this tutorial is targeted specifically at small, short-timeframe projects. Hopefully this will help answer the "What do I do next?" question developers keep asking themselves. Larger projects will require a more structured approach, but some points here may still apply.

Analyse your scope

You have a game idea. Be realistic. You aren't going to write Doom 3 (or Doom 1 for that matter) in 2 days. There are certain things that are beyond the abilities of your engine, or are simply too expensive to implement (like holograms... yes, it was proposed). Run your idea by a few experienced people and determine how feasible your project really is.

My client required this project out within 3 weeks. When we received his request, we recommended excluding networking and AI cars, and replacing the urban city race route with a racetrack. This drastically cut down the scope of the project to something more manageable for that timeframe

Plan before you code

Know what your game is going to be like, and how long it is going to take. If you cannot describe it easily, you need to rethink it before attempting to put down any code. This usually entails writing a design document. The design document is the bible that every team member will refer to when they make decisions that affect what the game is going to look like. How detailed does the design document have to be? That depends...

- Shorter projects timewise require less details.
- The more people you have working on the project, the more details you should include.
- The more familiar you are with the capabilities of the engine and tools you are using, the more details you can and should include.
- If your team is inexperienced, include more details.

In other words, if your project is your dog, the design document is your leash. If you give more slack, the dog will be happier, but is also more likely to run wild. If you keep it on a short leash, everything is more controlled but the dog might get annoyed enough to bite your foot off.

How do you write a detailed design document? A good place to start would be Chris Taylor's design document template. It will help you cover the essentials, but certain things may be missing or redundant for certain games. Customise this to your game and make it your own.

For Car Rally, I had 3 weeks to produce the game (including testing), with only myself as programmer, a 3D artist and a 2D artist. All were quite veteran in our own fields. We had very little prior knowledge of the Torque Engine. Our design specification was a feature list about 2 paragraphs long!

Jump right into it, don't learn what you don't need

There is no better way to learn than to do. You can buy books in the shop, read all the articles in the world, but only a small portion will be applicable to your particular game. Rather than spending all that time, figure out what you want to do, learn how to do it, then do it!

I started out reading the overview from the official documentation to get my grounding. Following that, I learnt how to use the mission editor and gui editor as I went along, and gradually researched the scripting and eventually made some changes to the engine code. I still have absolutely no idea on subjects like importing characters and animations, multiplayer networking and AI control. Those simply did not apply to this game.

Start with the simple stuff

Why? Because when you are unfamiliar with the engine, you should start out with things you can relatively painlessly redo as you will make mistakes. Also, dabbling in the easier bits will give you more experience and knowledge to take on the more difficult feats. When you encounter something that you have no idea how to go about doing, it is a good idea to put it off and come back to it later.

Doing this will also keep your morale up as you can see the changes happening at a decent pace. In the meantime, your subconcious mind will have a chance to take a crack at the big problem while you occupy yourself with other things. (Why use only 10% of your brain?!)

I started out with the Mission Editor and GUI editor, terraforming, and changing the interface. Not only was it relatively easy, it was fun!!! From there, I learnt about the various properties of each type of object, and later on could relate as I came accross them in the scripts.

Always have a working build

In other words, build up the skeleton of your project first, and as fast as possible. It may consist of a series of blank screens that later get fleshed out as the project progresses. If anything breaks the build, you know that you have a problem.

If you have multiple developers, some sort of code control might be useful. There are a variety of freeware and not-so-freeware available in the market, including CVS, Visual Sourcesafe, Perforce, Alienbrain, etc. This not only helps to maintain each working build, but also helps coordinate code changes.

For Car Rally, since there was only me and the duration was so short, no code control software was used. I did however, keep a daily backup of the code so I can regress or compare new code with the old one. I used the starter.racing demo as my first working build, and modified the components bit by bit.

Focus your energies on things in the critical path. Other things can come later.

What is a critical path? It is a collection of components that are crucial to your game. Everything else in the game depends on these. For example, a splash screen is not all that important. The ability to put a 3D object into the game, on the other hand, is crucial as you won't have much of a game with no objects available.

I spent one whole day (that's huge in a 3 week project) sitting down with my 3D artist, figuring out with him how the dts exporter works, and how to import vehicles. I could have spent the day creating more menus and doing up the high score table, but there wouldn't be many highscores if there was nothing to drive!

Track your progress

This will help you determine what stage of development you are at. A good way to do this is milestones. Predetermine what each milestone is and when it should be accomplished. This focuses the team on what it should accomplish next. If you accomplish milestones ahead of time, push the project schedule up, creating some buffer time for emergencies. If you fall behind, do not push the schedule down unless you have buffer time. Instead, try to catch up with the schedule.

You may take it for granted that problems will crop up that will cause delays. The only way to ensure that you deliver the project on time is by staying ahead of the schedule, and accumulating enough buffer time to handle delays. Some project managers plan in buffer time specifically for these problems.

Be firm on the absolute delivery date. Once you start pushing this date back, you risk falling into an infinite loop of the worst kind.

For my small project, I had a feature list. To each feature, I assigned a status. red - not implemented, amber - needs refinement, green - ready to ship. My assumption, since my timeframe was short, was that I was always behind schedule. It is now 2 days before the end of the 3rd week and I am ready to dance!

Don't be a perfectionist

Save time and effort by not doing everything to perfection, especially at the beginning of the project. Leave refinements to the end. The reason for this is techincal or design issues will tend to require changes to what you have done. Every minute not spent on the feature prior to this change is a minute saved.

When I first created the race route, I pushed mountains aside, and drew a rough track which had a lot of jagged edges. It looked quite sad, but that was it. Later on, when my artist modelled the track curves, we figured it would be easier for him to make them in 90 degree curve and straight pieces. I fit this onto the general shape of the track as best as I could, then wiped out the old track and filled in the space between the kerbs with the road texture. If I had spent time early on making the perfect shaped track, that effort would have been wasted, or my artist would have had to work a lot harder.

Test while you code

You do this because if you continually test, you will know the exact cause of any bugs that crop up. The less certain you are of what you are doing, the more often you should test. (The first time I modified the engine code, I was testing after every other line added!) Apart from bug avoidance, this also reassures you that your code is actually doing something! This will save you from many headaches, sifting through pages of code hunting down the elusive bug.

When I added sound to the game, I found that whenever I switched to 4WD mode, the game would hang after a while. Without consistent testing, I would not know what was wrong.. the game just hangs. Later, I traced this down to a subtle bug in Torque's use of OpenAL. (or a subtle bug in OpenAL depending on if you are pro-Torque or pro-Creative)

Don't reinvent the wheel

If you have something complex you need to implement, it has probably already been done by somebody. There are several places you can look. One is the resources section of the GG website. Another is through the forum archives. Also, you might find the feature in one of the demo apps which means readymade and tested code.

In my car selection screen, I wanted to display the cars rotating in my GUI without first connecting to the server module. I simply copied and adapted the showtool code. Later I found out about the Objectview resource which would probably have done the same trick.

KISS

Keep it simple, stupid! When given two options, one being simpler, and one being complex, pick the simpler option. Many programmers get sucked in by the allure of OOP, making things extensible, pluginable, multiusifiable, etc. Simple code is more readable. Simple code usually runs faster. Simple code is easier to maintain. Simple code for a better tommorow!

In the face of adversity... you are not alone

The GG community is well and kicking, and is there to help you when you have problems. There are several avenues available. My usual preference of SOS in order of merit is:

1. look in official documentation
2. search tutorials and resources
3. search forum archives
4. Google
5. read the engine source code
6. ask in irc
7. post in forums

1 is faster than 2 is faster than 3..... If you are new to programming, you might want to switch 5 and 6. Answering peoples questions when you can also helps to reinforce your grasp of the engine.

The 15 minute rule

If a new feature is requested, and it cannot be done in 15 minutes, add it to the nice-to-have list that will be implemented after all the original features are done. Scope creep is the death of many projects. Big companies have change control commitees to manage this. Indie developers just say 'no'.

Note that the 15 minutes varies depending on the length of the project. 2 month projects can have 1 hour rules, 2 year projects can have 1 day rules.... for my 3 week project, 15 minutes was just about right.

When I first put in the speedometer using the default speedometer control, the first reaction all of us had was that the needle was ugly, being just drawn lines. My artist wanted that replaced with a bitmap, but this got pushed to the end of the project after more important things were coded. It got done in the end, but if it had not, we could still have delivered with the ugly needle.

Do not change your codebase midway

Changing the codebase, tools or other variables halfway through the project is a risk. It should be avoided unless there are features in there that you absolutely must have. If bugs crop up because of this codebase, they would be difficult for you to track down.

Torque 3.0 came out as I was midway through the project. I downloaded it and put it to one side for the next project and as a reference. The particle editor looked nifty but I didn't absolutely need it and had no desire to risk any delays to the project.

Allocate time for testing

This should be part of the production schedule. There are 2 phases to this. An internal testing to iron out all major design and technical bugs, and an external testing to allow players to evaluate and feedback on the gameplay. Time should be allocated after each of these phases to implement changes and resolve issues.

Maintain an issues list. An issues list is a list of problems that need to be resolved. Prioritise these issues in terms of urgency and importance, and knock them off one by one in that order.

My game was tested by my clients near in the middle of the 3rd week. Based on their feedback, I have modified the game in small ways such as smoothing out patches of terrain and including more barriers to prevent people from straying off-course.



Well that's it! Hopefully this will help any budding new developers get more organised. I am sure that the more experienced folks here will have words of wisdom to add.