Game Engine Programming I


One of the best and most challenging classes I’ve ever taken during my pursuit of my master’s degree at DePaul University was Game Engine Programming I. I just finished it successfully and I’m about to start its sequel class. The goal was to build a basic game engine in C++, which will then be developed much further in the sequel class and any independent studies the student would like to do. Each student was required to work individually on his own to finish and submit his final project. It was a lot of work and I definitely learned a lot from it. Each student was required to submit his working source code along with a recorded video of him demoing his game engine. The following is the video that I submitted:

Building my game engine, I accomplished the following:

  • Building all the data structures that the engine uses:
    • Parent-Child-Sibling (PCS) Tree: for maintaining the engine’s scene graph.
      • Passed 73 out of 73 unit tests provided by the professor.
    • Sequential and Hashed Symbol Tables.
    • Iterable singly and doubly linked lists.
  • Building a memory system that  manages dynamic memory allocations and encapsulates and abstracts Win32 memory management functions. The memory system can handle multiple heaps and each heap can either be of fixed-sized blocks or variable-sized blocks. It can also handle any alignment requirement of blocks.
    • Passed 40 out 40 unit tests provided by the professor.
  • Building a file system on top of Win32 functions to handle the needed file IO operations of the engine.
    • passed 20 out of 20 unit tests provided by the professor.
  • Building a math system for the engine that does all the matrix and vector operations associated with the game and graphics engines.
    • passed 102 out of 102 unit tests provided by the professor.
  • Building an efficient graphics engine using OpenGL. The graphics engine was the biggest part of the project and it included many areas:
    • Cameras and Camera Management:
      • Building a camera  object that can move, rotate, and zoom in/out.
      • The camera draws its frustum as a visual clue.
      • The camera calculates its view and projection matrices, and can determine whether an object should be drawn or not (object culling against the camera frustum).
      • Building a camera manager that manages multiple cameras, and can perform operations on the active one.
    • Textures and texture management:
      • Building a texture manager that loads and unloads textures in a flyweight manner. The same texture never gets loaded twice.
      • Hashing of textures is done by MD5 hashing of the texture image data rather than its file name.
      • Textures use reference counting, they’re only unloaded if they’re not referenced by any graphics object.
      • Texture manager tracks the number of textures loaded into GPU and their total byte size.
      • Each texture object has its own min and mag filters, and wrapping modes.
    • Graphics objects and graphics objects manager:
      • Each graphics object is loaded from a single file that includes all its data:
        • Vertex data (positions, normals, and UVs).
        • Texture data (the texture images themselves, their min and man filters and wrapping modes). An object can have multiple textures.
        • Information about its culling sphere.
      • Objects are stored on the GPU memory using Vertex Array Objects (VAOs) and Vertext Buffer Objects (VBOs).
      • Objects can have different locations and lights.
      • Can be unloaded, which will unload its vertex data stored in its VAO, and unloads its textures (if they’re not referenced by another object).
      • Each object has its own transformation. It can deal with transformation hierarchies when placed as a child of another object.
      • Each object using a bounding sphere to be used in the culling against the active camera frustum. The culling sphere can be drawn in debug mode for testing.
      • Graphics object manager:
        • Tracks the number of objects on the scene graph.
        • Performs the culling against frustum upon drawing using the active camera.
        • Has factory methods to create objects.
        • Tracks the number of objects drawn.
        • Can delete an object along with its children if any.
        • Can unload all the objects.
    • Ability to have different shading modes:
      • Lighting the objects without textures.
      • Lighting the objects with textures.
      • Flat shading the objects with a constant color.
      • Draw objects in wire-frame mode.
  • General Project Achievements:
    • Fully object oriented and data driven.
    • Uses many design patterns.
      • Singleton: for all the management systems like the camera manager, the texture manager … etc.
      • Strategy: for swapping the active shader.
      • Flyweight: Texture manager loading of textures.
      • Factory Methods: in the graphics object manager.
      • Iterator: for the iterable data structures.

I’m looking forward to Game Engine Programming II so that I can continue and improve this game engine.

Note: The models that I didn’t create belongs to:

- Pear
 http://www.blendswap.com/blends/view/66573
 - Lizard
 http://www.blendswap.com/blends/view/66922
 - Fence
 http://www.blendswap.com/blends/view/66818
 - Spaceship
 http://www.blendswap.com/blends/view/49662
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s