Contents

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

Feature List

Now the goal is defined, and the features required by the engine can be determined. Again, it is very important to keep the skills of the team and the time constraints of the project in mind.

Some things to consider for your feature list are:

• The types of output. For example: 3D objects, indoor- or outdoor-drawing, skeleton animation/animation drawing.
  
• The eye candy - shadows, particle systems, texture blending, nifty effects.
  
• Physics and collision methods.
  
• Network play and/or single player.
  
• Input methods.
  
• Debug and testing functions.
  
• Sound and music capabilities.
  
• Whether to use a script language for the game code.
  
• Whether to do your own editor or professional tools.
  

The Wish List

It is important to distinguish between what you need and what you would like. So I suggest making two lists: a feature list and a wish list. Even though it is often more fun to work on items in the wish list -- usually the eye candy -- wish list items should wait until the required features are implemented, or when you're waiting for other people to finish their parts.

Things that fundamentally change how the game is made, such as implementing skeletal animation or developing a scene editor, should not be on the wish list. These things change how the animators create game content, and their previous work will be wasted. However, a lot of the eye and ear candy, such as lens flares, 3D sound, rigid-body dynamics, and advanced particle systems can go into the wish list, as the game can still work fine without these items.

Eye candy, like the lens flare in this shot, goes into the wish list. The game would work fine without it.

Network play is often put on the wish list. However, implementation of network playing will influence a large amount of the code, and greatly change the direction of the game. This might introduce a ton of new bugs and might require reworking the levels. In my opinion it's a bad idea to leave this question open for later discussion. Either networking is built-in from the start and all structures and routines are prepared for its implementation, or it is not there at all.

Content Path

It is a good exercise to consider how the game content is created and gets into the game. Preferably the artists, modelers, level designers, and gameplay programmers should have as much freedom to create the game with as little work for you as possible.

A typical dilemma is whether it is worth it to make a level editor, or if a tool such as 3D Studio Max should be used. It is much faster to write an exporter or a converter than to write a full editor, but in the editor it can be possible to see the level as it will end up in the game, and it will be easier to edit object properties, apply scripts and create new tests. Whether to build or buy again depends on the project, the team and the deadline at hand.

It's common for developers to have to wait for compilation, conversion or rendering tasks, and frequently developers have to perform tedious tasks which can introduce errors if not performed correctly. If possible, try to eliminate these tasks, or at least optimize them. For example, if your engine requires BSP-tree compilation, it should have an option to run an un-compiled version as well.

Another problem I have encountered is when artists depend on programmers to test their content in the game. This is annoying for the both artists and programmers, so try to design a system so that artists can test content in the game themselves as soon as possible. During the development of my first 3D game, Amok, the productivity increased by a factor of 3 to 4 when we got an extra development kit for testing the graphics and the levels.

The Example Returns

Let's return to our imaginary development team. Our little team has decided what the engine should do, and it has kept things simple to keep the deadline short and the goal easily reachable.

Their engine will require a landscape with subdivision. The landscape is based on a height image from a paint package, and the engine will select the textures procedurally. It will also contain 3D object drawings, with the objects modeled in Milkshape. All objects and textures are loaded into memory at the beginning, and no texture swapping will be needed.

The elements should be able to move and rotate in full 3D (six degrees of freedom). Collision will be sphere-sphere for checks against other elements, and sphere-polygon for checks against the landscape.

The game elements will be placed on the map in a simple top-down 2D editor. In this editor it will also be possible to set properties on each type of element, such as hit-points, sound effect and particle effects. The engine will be able to be started from the editor, to speed up testing of gameplay.

All gamecode will be written in C++, and the code for each element will be derived from a virtual class that is used to get information from the editor. The main debug functions will be a log-file and an overlaying text window for run-time information such as framerates and status flags.

The game will contain a particle system for explosions and other effects, and it will use MP3 for music and .WAV files played in simple stereo for sound effects. It will use a joystick for input. On the wish list are lens coronas, multiple sky layers, shadows on the landscape from the elements and a moving sun.

________________________________________________________

Structures and Subsystems