Contents

Introduction: 3D Engines Setting Goals for the Engine Feature List Structures and Subsystems Conclusion

Setting Goals for the Engine

There are a number of reasons why you should clearly define your goals before you begin.

The specs of the engine should be fitted to the team making it, and to the game for which it is being made. Programmers often aim too high, and start building features that are not completely necessary. Or they may not have the time, the manpower, or the skills to finish off a highly polished game.

Setting the goals help you clarify your focus, and give you a direction to go. With a clear purpose, you will likely keep on the right track through the end of the project. One small completed project, even with only a few levels, is better than ten great projects abandoned when they are 90% finished.

The third reason for establishing clear goals is that you will remember that developing the engine is not an end in itself; it is just a tool to make the game. Gameplay often takes a back seat in game development, both in marketing and among developers, but remember that a neat engine never made a good game. Gamers have known this for years, and we developers should keep this in mind.

Note that the goals are quite broad, and should help everyone to get a quick overview of the project. More specific details are considered later on in the process.

The Team

The goals should be suitable and feasible. Therefore they should be based on the team, the deadlines, and the project. A number of useful questions to ask yourself are:

Who is going to work on the project?
How many people are available?
When will they be available?

If you work alone it is easier to keep an overview, but if there are more people, it makes it easier to keep up the spirit. Knowing that more people will join as the project goes along can also help to push you over the worst hurdles.

Is it a full-time or spare time project?
How much time will each member be willing to spend?

If you are a single programmer, and have a full-time job apart from programming, writing the next Unreal entirely from scratch does not sound that feasible.

If you are a single programmer, writing the next Unreal entirely from scratch may not be entirely feasible.

What are the skills and the experiences of the team members?

If you have few artists and many programmers, writing a game with procedural graphics would make more sense than trying to make a new Final Fantasy. And if none of the team members have ever written any large programs, it might be better to aim for a small project.

The key thing is that you have to be realistic or, even better, pessimistic about your team's skills and available time. It is definitely better to make a simple game quickly than trying to do an epic tale with too few or too inexperienced people. Even highly professional development houses have sometimes managed to screw up here, causing years of delays and ending up releasing boring, uninteresting games.

Deadlines

The deadlines include the final version and the feature-complete alpha as well as demos or possible milestone requirements. Even if you don't work for a company, you should still set deadlines. With no clear deadlines it is easy to keep working on nitty-gritty details that have only a marginal impact on the project, but if you know when to be finished with each part, you can always come back to do fine polishing later.

Oh, by the way - learn to keep the deadlines! That would make a lot of people happy - including yourself.

The Project

What is the real goal of the project?
Is it just for fun, or do you want to sell it commercially?
Do you do it just to learn or to get a job in the business? Or do you just have an idea to try out?

If you do a project just to learn, there is no point in making 100 levels, when it is just the same tasks you will do over and over. And if you have an innovative gameplay idea that you want to try out, you should not have to worry about writing menu systems or cinematic routines.

Is the target format PC, Mac or a console? Is it cross-platform?

A simple way to avoid problems when working across multiple platforms is to design for the smallest target and simply scale up and add more detail on the more powerful machines. However, different machines have different weaknesses, and it is important to know these (some machines, for example, excel at polygon-pushing power, others have more memory, etc.).

What style of game will the engine be used for? How complex is the game? Is it very innovative, or a clone of an existing game?

If you're working on a very innovative game, it is very important to be able to get it to a playable state, but using simple boxes might work fine as graphics. A first-person shooter, on the other hand, follows a standard recipe, and in the beginning it is more important to see the level design in-engine than to tweak character control and gameplay. Similarly, for a complex RPG, there should be much more focus on setting up systems for the level designers to enter texts, weapon stats, enemy properties and so on than in a puzzle game.

Do you want to allow the mod community to add new stuff to it? In that case, you are limited from using any commercial package like 3D Studio Max, and you better have easy-to-use, bug-tested editors to go with the game. It is important to remember that the mod community consists of gameplayers, not professional game designers (yet.) Also try to make sure that the file formats are simple and documented, in case people want to write their own tools. And if you have a script system that the mod community has access to, make sure that it is very stable and works properly, even if it gets weird user input.

How many levels should be in the game?

The more levels, and the more complex they are, the more important it is to have a good set of tools to use. A 30-level Quake game will require more advanced tools than an outdoor game with three levels based on procedural geometry.

Still, do not underestimate the amount of time that is wasted due to inadequate tools. In my first game, Banshee (a 1942 clone), we used a terrible in-house level-editor on the Commodore Amiga for the enemies. However, since it was not possible to set any properties, the levels had to be converted to source code, copied to the PC, add data by hand within the source code, and then compile and test it. We estimated that we would probably have saved a month or two (out of 11 months in total) if I had written my own level editor.

Should the engine be used for only one game, multiple games in the same genre, or completely different types of games?

If you want to target your engine for use in multiple games, there should be as little gameplay-specific code in the engine as possible. If it will be used for just a single game, it might be possible to do some hardwired functions. As an example, in Banshee the player-characters used hard-coded functions, while my script language controlled the enemies. Still, I cannot recommend this practice, as it gets too messy.

An Example

What I've explained thus far should help you determine where your project is going. The next phase is to share this vision with all of the people in the project.

As an example, let's imagine a team consisting of four people: an artist/3D modeler, a level designer, an engine programmer, and a gameplay/editor programmer. They have limited experience, and they are all working in their spare time. Their goal is to make a simple game that can give them a job at a game company, and to release the game as freeware. Therefore there are no requirements for demo versions or milestones (except internally). The target machine is a 450 MHz PC with a TNT2 graphics card.

One realistic goal for our little team would be to create a simple single-player Terminal Velocity-style shoot-'em-up, with about 3-5 levels. The engine should not be developed with reuse in mind, and the levels should not be editable by players.

________________________________________________________

Feature List