What was the goal?

At the beginning of class our end goal was simple, build as much of a game engine possible. We all knew that this would certainly be no easy or quick task. We started by laying the ground work by integrating and using Ogre 3D as our renderer. We would build off from there adding one feature at a time seeing how far each of us would make it. The process was difficult to say the least but I believe the end result is nothing too shabby. We wanted to show off some more technical c++ skills and practices by remaking space invaders as best as possible in our own engine I ended up accomplishing just that.

My approach

My approach to each individual feature usually varied for each one since the implimentation was all so different. The features that are implimented in my game engine are: Singletons, OOP, Custom Python Scripting, Custom Entity Objects, Entity Manager, Custom Physics Integration, Collision Integration, Scene Parsing, Custom Components, Component Manager Logging, Input Bindings.

Whenever I started at a new feature I always made sure I layed everything out befoe I actually started typing. With a project this big its important that everything is done right or it will come back to haunt you down the road. For example, when we first started on our entity and component system we knew we needed some kind of manager for both the entities and the components. Though since the components get attached to the entities and updated with them those can really be thought of as the component managers so we dont need anything extra. Whereas with the entities themselves we need something that is responsible for managing all of them. For this I have a game object manager (GOM) to handle all of the game objects (aka entities) in the scene. This manager is also what we interface with when we want to find and retrieve a game object in our scene or delete an object in the scene. Really any kind of interation with game objects gets done through the GOM. However, one thing that may not seem obvious but also gets handled in the GOM is the loading of info from a scene file.

In my engine, scene files are .xml files that hold all of our information. Its holds all the information about all the game objects that are in the scene as well as all the information that goes along with each game object. The scene files are parsed recursively so that it will parse no matter how big the scene is and the GOM will create the entities as it parses also setting those entities given info as it parses.

The approach taken for the custom python scripting was definitely a unique one. I had never never done anything remotely like this before so I tried to absorbe as much knowledge from my professor as possible in lectures to make sure I got this feature working. This feature, for me, is something that would really make the engine stand out since no one wants to use an engine where they have no nice wrapper of the complicated engine code. Step one was basically making our own little .dll for our engine that wrapped up all the "middle man" functions to access our engine through so that we would be able to import our module (called ssuge) using that dll giving us access to our engine that way. To spare super extensive detail here that was really most of the work was doing that. The process after that was really just what methods will the script user need to have the full power of the engine? And once they have that then they have the power of python and their head to do whatever they want with the engine.

Challenges Faced and Things Learned

Im not going to try and pretend like this engine is anywhere even remotely close to the likes of any big dog engine out there. Those engines have the benefit of way more people, money and time. But even though its primative and relatively basic this engine can be used to make a game, granted a small game most likely, but a game none the less. And that was the goal really, make something that came be used to make a game and develop as many skills as possible along the way, and I did just that. This projects personal benefits and so many different skills cannot be stressed more. No one feature was really ever a walk in the part, since even if the implimentation looks simple chances are the information was new and so was the technique used to impliment it.

Every single one of the features (beind the scenes or not) had me scratching my head at one point or another. While that may seem odd to say it means that it was difficult. And because they were difficult I learned something from each and every one of them. From the simpler ones like logging to the most challenging of them including custom scripting and custom physics integration with Bullet. Each one made me a better programmer and all together they made me an even better programmer

How to check out the project?

The engine is up on my GitHub for you to download if you'd like to check it out! I would highly recommend checking it out since the project is so large I cant really talk about each and every detail of it. Its easiest to look at for yourself.