The engine was programmed in C++ and used a variety of middleware that is listed below.

​

  In this project I developed a Game Engine and a simple game to be run by said engine. The game involved to local players trying to knock each others cars (represented by blocks) off of the platforms. The last one left on the platforms was the winner.   

​

  The vast majority of the development time I spent on this project was spent on developing the engine to be general purpose as opposed to focusing on building one very specific kind of game and developing that game into a more complete experience.

  My game engine made use of several different pieces of middleware:

• Bullet Physics was used to govern the movement and physical collision responses of the physical objects in the game.

• NCLGL is Newcastle universities graphics framework using OpenGL. The university provided tutorials for completing the framework however I had to integrate it with my game engine by making a renderer class suited to rendering the "Level" and "GameObject" classes that formed the structure of the game engine. The framework was also used for registering keyboard inputs.

• SFML was used for its audio functionality. It allowed me to play, pause and stop sounds and music from object controllers that had access to my audio interface .

• Memory Management was primarily handled by a memory allocator found here. However I also implemented an interface to use it and programmed my Levels and GameObjects to deallocate their memory from the memory allocator in a cascading fashion when they were no longer in use.

​

  The majority of the code I created for the project was in the Structure, Control and DataIO subsystems:

• The Structure subsystem contained the basic classes "Level" and "GameObject" that all of the other subsystems used as the representations of the game world. The Renderer renders all the GameObjects in a Level,  Physics system simulated all the objects in a given Level, etc.

• The Control subsystem is where the game logic is contained as subclasses of the "SingleObjectControl" classes. that has a reference to a single object that it is supposed to control. However it also has access to references to:

  • The current level in order to request references to other objects by name or a flag they have associated with them.​

  • The render interface to change the camera location.

  • The physics interface in order to get evaluate and influence the physical simulation of objects in the level, e.g. the PlayerCarController checking if its car is colliding with the other car in the level to play a sound or applying an acceleration to its physical body because of a command.

  • The resource manager in order to allocate more space for new objects or deallocate space.

  • The audio interface to play sounds or music.

  • Finally it had access to a method for requesting the engine load a new level from the DataIO subsystem.

• The DataIO subsystem read in level files and created the objects specified within. The fact that I built my engine to not be specific to one type of game meant the DataIO had to be very general. It read in individual assets like meshes, sounds, physical bodies and even controllers the engines user had written in the control subsystem. It then applied these assets to GameObjects that requested them later on in the file. This meant every GameObject in a level that used one particular mesh used the same mesh at the same memory location. This saved significant space in memory.

​

Overall this project was difficult but interesting and with the exception of my dissertation project it was one of the largest single pieces of coding work I did during my undergraduate.

​