ISU Game Developers Club
General Information
Mailing Lists

Open Privateer


Project Page
Lab Sessions
CVS Access
Subversion Access



The primary goal of this engine is to put together a 3D game engine that we can finally reuse as a separate, stable library in order to allow us to rapidly develop new games. There are however some other key requirements necessary of this new engine.

Keep in mind that most of these requirements are very broad. For an actual game, these will have to be cut down. If we want to be realistic, there's no way we could implement all of this, and not all games need all of this functionality. -- ChadAustin

I should have mentioned somewhere that I tried to lay down the groundwork for an ideal game engine in my mind. As such, a lot of the advanced features in this doc are still wishful thinking but there to provide guidance for future development. This engine would oniy ever support 3D games. In my opinion, work on an engine of this scope would have to be done in stages, with the parts that we need for the games we are working on nom going into the first release. -- BenScott


The "engine" developed for MidWorld allowed us to tackle many of the problems that inherent in the making of a 3D game engine. However, due to time constraints, the core of MidWorld was not allowed to grow into a reusable library. Many pieces of it are indeed extremely reusable as can be seen in the way parts have been successfully integrated with other projects. Additionally, the MidWorld engine is extremely stable making it a prime candidate to use as the launching point of a new engine.

The engine detailed below is extremely ambitious, but all of it would be necessary of a professional-grade engine of today. With a well thought out design and schedule, we can make it happen!


Hey, before we can build anything we need to know what we want to build. Right?

To even be considered useful, the engine is going to have to exhibit a few key properties.

  • Speed
  • Flexibility
  • Portability
  • Ease of use


We need the engine to be highly optimized so that we can be used in real-time applications. We need to make sure that when performance problems crop up they are not in the core engine code.


We want to be able to use this engine for the games we develop over the next few years. As such it needs to be flexible enough to support a variety of game styles.


From a game perspective, portability brings us the ability to move from PC to console with minimal effort. From a VR point of view, we all want to play our games in the cave.

At a minimum, we should aim to support the following platforms:

  • Win32
  • Linux
  • IRIX

It would be nice if we could also support:

  • PlayStation2?
  • XBox
  • GameCube?

Ease of use

The engine needs to be a easy to use. In order to make this happen it should be written as a black box with an interface in some suitable scripting language. This way, the code that needo to be fast can be implemented in a language like C++ and the game logic (which does not necessarily need to be fast) can be implemented in a simpler language like Python.

Along with this requirement comes the problem of memory ownership. In order to be easy to use, the engine needs to manage the memory it allocates. Since client usage of data shared across the API boundary is inherently unknown, some sort of smart pointer or garbage collection scheme will need to be used. In addition to making the API more clear, this should also make the the engine more stable.

What should go into the engine

When one tries to come up with the functions necessitated by a game engine, the result is a huge list of crap. It should be useful to discuss the functional requirements by grouping them into subsystems.


Without sound, a game is just not fun to play. The sound subsystem includes music and sound effects. to be really great, the sound subsystem needs to support the ability to cue changes in the music in response to changes in the "mood" of the game. If the player is walking alone in the forest and stumbles across a goblin, the music should smoothly transition from serene "forest" music to exciting "battle" music.

  • Play a sound
  • Piay a 3D localized sound
  • Play music
  • Loop music (loop points)
  • Mood music cues

Entity management

Every object in the game is considered an entity. Most entities have all the properties of a rigid body in addition to the game specific data that goes along with them. This subsystem should make sure the entities are updated appropriately.

  • Manage entities

Physics and collisions

This is the subsystem in which we try to make the entities in the game interact with the world in a realistic fashion. Basically we do not want users thinking that the game does not feel right. The contents of this subsystem essentially take care of most of the "update" loop of the core engine.

  • Handle physics calculations
  • Do collision detection
  • Provide hooks for customized collision responses

System abstraction

Here the goal is to hide the implementation details of the underlying system architecture. This basically includes windowing, timers, threading, and I/O.

  • Open a window
  • Change window/screen resolution
  • System time access
  • Thread management


Without input, a game is just a movie ...

  • Allow usage of digital inputs
  • Allow usage of analog inputs
  • Allow usage of positional inputs
  • Provide input management (bindings)

Resource management

The engine should be able to provide tools for loading and caching the many types of resource data that a game needs. This includes images, audio, models, maps, etc. All the loaders should be stream-based for the case where you want to stream resources over the network. (but this detail depends on what you want to stream... would you really want to stream textures into a model in the same way web browsers do it? music is the only thing I can think of where streaming makes a lot of sense.)

Hmm ... I guess even in the networked case, you would still probably save the resource to disk to cache it client-side before attempting to use it in-game. On the other hand, if we move to supporting access of resources in archives, then having done the implementation as a stream would be very useful. -- BenScott

  • Load 2D images
  • Load 3D models
  • Load maps/scenes
  • Load UI layouts
  • Load terrain definitions
  • Load movies (AVI, etc)
  • Cache game resources
  • Facade to all loaders


The engine needs to be able to render the game world in 3D as this is the most visible aspect of the engine. The renderer also needs to be extremely fast!

  • Display a 3D model
  • LOD support and management
  • Animate a 3D model
  • Dynamic lighting
  • Provide a terrain engine

State Management

A game is generally broken up into several states. You have the intro, menu, game, etc. We had a good state manager in MidWorld that would work well here.

  • Create states
  • Add states to the engine
  • Trasition between states


All applications need to be able to use a good UI to interact with the user. This applies to games as well. However, we cannot just use the underlying system widgets since this engine needs to be portable. Thus the engine needs to provide a good set of wigets implemented in OpenGL?.

  • Display a user interface

Area of interest

Worlds that this engine needs to support may be extremely large in size; they may not even fit entirely in memory. Updating every entity every frame may not be feasible. Thus the engine needs to provide tools for managing the area of interest. This part of the engine is responsible for making sure the data needed is in memory when it is needed and serializing that which is no longer of interest.

  • Provide tools for area of interest (AOI) management

Artificial intelligence

A game is not fun if the computer player is not a challenge. The engine should provide a framework for adding intelligent agents to the game that can control the computer entities. Since most of the work in the AI has to happen at the game level, the engine can only provide tools that developers can use to build up their own AI routines.

  • Provide an AI toolkit


The API to the engine needs to be in a souitably high-level language that is easy to use. This portion of the game does not necessarily need to be blindingly fast and will most definitely benefit from the clarity of a scripting language. This will also allow for rapid debugging of both the engine and the games that use it.

  • Provide an API in a scripting language

Core tools

This is basically just a collection of useful tools that all subsysytems and the user will need.

  • Provide math functions
  • A flexible plugin system for handling extensions to the engine
  • Load in DLLs at runtime


A treatise of the design of the implementation of such a system will be covered in another topic.

See SirenEngineDesign

Libraries we can use

Obviously we do not want to reinvent the wheel (just most of it), so here are some libraries that can help us achieve our goal.

Library URL
AI Loom
Boost Smart Pointer Library

-- BenScott - 27 Dec 2002