Andrew Friedland

My first large project at DigiPen was to create a reusable game engine with a small demo game in half a semester (7 weeks). We were provided with a sample component based engine and told to dissect it so that we could then create our own. The engine I created was based off many of the ideas in this sample engine, but implements many features differently, adds more functionality to many features found in the sample, and also adds many features that did not exist in the sample. For the last week I focused on building a simple game on top of the engine. The game is a Geometry Wars style arena shooter where the player is trying to use snowballs, fireballs, and their own mass to knock the enemies off the platform.

I learned a huge amount while working on this project. I had worked with a component based architecture before on BeeStruction, but I did not fully understand how the engine worked at the time. Now that I have built my own component based engine from the ground up, I now truly understand the power and freedom this type of engine provides. In addition, I had always felt that the serialization system in Beestruction was limiting and irritating. However, now that I have spent more time thinking about why we want a serialization system, and have spent time creating one, I have realized that I did not give serialization the respect it deserves. Serialization allows for very simple and easy level creation, and the fact that I can change some variables or add new components into a text file, press a button, and have the changes I made appear in the game immediately makes me realize just how powerful this system can be.

One of the many new ideas I came across while looking at the sample engine that I decided to integrate into my own was the intrusive linked list. I knew that I would need some data structures to hold all of my various components and compositions, but I was unsure of what data structure I should use. All of the STL structures require calls to malloc and free when any item is added or removed, and while this might not be an issue with the demo game, these system calls might end up being an issue in future games, so I did not want to rely on these. The intrusive linked list solves all these problems for me with very little work. It has a slight overhead of having every component having memory that might not be used, but in exchange for this this I do not have lots of little chunks of memory being claimed for each node in the list. One problem I see with my current implementation is that each component can currently only be part of one single list at a time. This has so far not been an issue, but I can see how it might be in the future and am planning on fixing it in my next project.

One large issue that I ran into is level specific code. Right now I have components that do many things for me, but I feel like there are some bits of code that are specific to each level and I do not know how to handle those at the moment. In my sample game I was able to work around this issue, and the only code I needed was for the game logic to keep track of which composition is the player. I have not yet found a good solution to this, but at the moment my plan is to create classes for each level that requires special code and have the factory create the correct level object as well as all the various components.

The thing I am most proud of in this engine is my serialization system. It has an issue in that it requires the programmer to write code for how to serialize every different component, but I am unaware of how to automate the creation of that code. Beyond that, it is an incredibly flexible and powerful system. I have archetype files which include default values for many of the variables in each type of composition, be it a snowball or menu button. In addition, there are level files which load the various archetype files and then modify the variables as needed for each instance of the archetype. The system I have created allows the level to specify any variable in any composition in the level, so that each level can take any archetype and modify it however it needs, including adding components that are not in the archetype. In addition, since archetypes and levels are all stored in text files and not code, I only need to reload the level to see any changes I have made, allowing me to tweak variables or change which components are in a composition on the fly without recompiling.

The game I built on top of the engine is a relatively simple arena shooter. I spent most of my time on the project working on the engine, but once I started working on the the gameplay and logic it all fell together incredibly quickly. I was able to get all the gameplay done in less than a week, giving me time at the end of the project to add a few extra features and hunt down a few bugs I was ignoring. The game is not very complex and could use a few more levels, but works just fine as a proof of concept for the engine. The speed at which I was able to create all the game logic, as well as how easily I was able to implement new ideas as they popped into my head, clearly demonstrated to me just how powerful a component based engine can be.

I really enjoyed working on this project and learned a huge amount. There are certain parts of the engine that I would like to go back and do differently now that I have more experience, but I am very happy with how the engine has turned out in general, and I plan to use it again on projects in the future. Penguin Game is a very simple game that doesn't do anything too crazy, but the speed at which I was able to put it together made me realize that I had created an incredible engine, and I am looking forward to being able to create a much larger game with it.

C++

Windows XP, Vista, or 7

Andrew Friedland

The engine for this game is based off a sample engine created by Chris Peters at DigiPen and a small amount of the code was copied directly from this sample engine with permission from Chris Peters.