Goals and aims - GavWood/DOGE-Game-Engine GitHub Wiki

Aim

The game engine was created to support game design in new contexts. Foremost, it was designed as a tool for fast game development with an emphasis on lightweight and no-fuss.

DOGE has so far been used for:

  • academic research
  • learning and experimenting with code
  • creating designs quickly in game jams
  • commercial games

Goals and some of the "best practices" employed

Thin Client

The game engine encompasses the idea of a thin client. In the context of this game engine, this means it has bare functionality out-of-the-box that can fullfil basic needs for a games designer without too much baggage. This includes the ability to:

  1. Create the window or instance of the program
  2. Respond to different input devices e.g. keyboard, multi-touch, mouse and joystick
  3. Render textures and materials
  4. Render sprites
  5. Render models (skinning, lit and animated)
  6. Render fonts
  7. Play sound
  8. Render ad-hoc vertex
  9. Ability to program shaders

Cross-platform

The game engine is cross-platform, which means the game designer does not need to overly concern themselves with writing platform specific code. Native libraries are used in the engine e.g. augmented reality and vibrating notifications etc.

Minimal build times

To speed up development it has been desirable to have fast build times. Currently a clean build of the entire game framework and the basic 3D scene unit test can be built in around 14s on a mid-2014 Mac Book Pro running Windows 10.

Minimal reliance on STL

Underlying game framework structures nearly entirely avoid STL. This reduces compile times, makes debugging easier, and importantly removes dynamic memory. STL can pre-allocate memory e.g. by using "reserve". However, this is not always used by programmers. Instead, the bespoke underlying structures e.g. BtQueue ensures that the amount of memory used at runtime stays constant. Note, there's no problem with apps using STL in the game logic implementation.

Reliance on third-party libraries

The use of third party software is necessary and convenient. However, smaller libraries with permissive licenses have been chosen in preference to others.

Loading times

It is disappointing to wait for games to load and it is mostly avoidable. Keeping the code small will reduce loading times a little, but the biggest saving is organising assets efficiently and storing these in a compressed file. These archives can be loaded in a single read into memory.

Good organisation will ensure that the "mark up" stage is mimimal. Once loaded, all the assets need to be "marked up". This involves setting pointers to resource data, so the OpenGL and OpenAL libraries can be given that data.

Most of the games created with this game framework load in seconds or sub-second times.

Playing is making

Game engines should be created so that "playing" is part of making. We can foster this by ensuring:

  • Minimal build times
  • Fast loading times
  • Support for ad-hoc vertex rendering e.g. if you wanted to play with particle systems
  • Support for open source model format that can be used in free modelling programs e.g. Collada. May expand to 3ds.
  • Good debug primitives which enable scenes to be easily debugging
  • Good asset management means that the programmer does not have to worry about loading assets
  • Simple font rendering for debugging