top of page

FIEA Game Engine and XML Editor

During the second semester of the Florida Interactive Entertainment Academy's(FIEA) programming track, each programming student must create a game engine. Throughout the semester we would work on assignements that would eventually make the FIEA game engine. The engine was developed in C++. It uses XML as its scripting language. At runtime, the engine reads from xml files which will contain the game world and all the entities in it. Classes can either be defined in XML or in C++ as long as they inheirit from an engine base class. 


By the end of the semester, each programmer would have a game engine. We were split up into teams and had to make a game using our engine that worked for both directx and opengl. I worked with a team of eight and we chose to make a geometry wars clone. During this project, I focuesed on making tools to help us write XML files and a line drawer that would output the necessary XML for our drawing. I also worked on enemy AI and spawning. I developed the enemy behaviors, enemy multiplier drops and scoring. The game was made in two weeks though the engine was made over fourteen weeks.

















I made the tool in visual studios using WPF and C#. The tool can open a XML file and fill out all the sections it needs using the data in the file. The user can then add to sections or remove sections. The user can also change the data if needed. By clicking the ADD button in a section, a new window pops up with all the options that the user can add. These options come from a XML file so if the user needs a new option then they simply have to find that file and add one line of XML.


I eventually want to change it to read from the game engine itself and fill out the options that way so if the user adds a new class in C++ the tool will update, but I did not have time to write a C++/CLI wrapper to open the game engine library to the C# tool. I also want to add features like copy and paste, drag and drop sections and an undo feature, but I had to take care of the next part of the tool and the gameplay elements I had mentioned before. 















The second part of the tool was a line drawer. Using the tool, the user can pick the color of the line and its thickness. The user can then draw the desired objects and add it to the XML. This made it really easy to draw out the characters for our game. This part of the tool has an undo feature which was implemented using the Memento design pattern.















We started the semester making stl containers from singly linked list to hashmaps. All were template containers. Next we made the base for our scripting by creating a class whose type is defined at runtime. This class is the Datum class. When the engine is reading from a XML file, the engine will set datums to specific types at runtime based on what the XML file says. In other words, if it reads an integer it will make a datum that holds an integer. If it reads a vector, then it will create a datum that contains a vector. These datums are put into scopes. Scopes make the heirarchy of the script. Scopes would contain a vector of datums and datums could contain scopes as well as many other data types. This creates the basis of a scripting language.


Next we created XML parsers to read from XML files. I used the chain of responsibility pattern to handle the parsing. I created a master parser who would accept request and pass the request to helpers. The helpers were made to parse a certain kind of request. This allowed me to make a helper for every request. The request would be a certain element read from the XML file.


Next, we started working on the things to fill our game. We made a World class, Sector class, Entity class, and Action class. The world class is a scope that acts as the base for the game. It contains everything for the game. Sectors are scopes that contain Entities and Actions. Entities are scopes that define a character in the game and Actions are a scope that define an action that an Entity, Sector or even the World can do. 


Lastly, we developed an asynchronous event system called Reaction. Reactions define not only an action to listen for but also the actions to take when the event has been heard. This was especially challenging since it was asynchronous and we had to deal with data races and locks.

January 2016 - Present

bottom of page