Welcome to the CPlusEngine blog.  Here you will find updates on this new engine written in C++ as a learning project from several book reviews I have written.  You can find the source code at https://cplusengine.zaxisstudios.com where I keep the most current source for this project.

The code has been released as is to the public with to expressed or implied warranty so use at your own risk.

If you have worked on or players 2D based games then you may know a little about a tile map so you can skip a little ahead.  For those just new to a tile map here is a simple rundown:

In a game you have a concept of the game world.  This is typically where your players will see how to interact with the environment based on the rules of your game.  We could use image software like Photoshop to paint an image of our game world.  But say you game world is really really large like 200,000 pixels wide by 100,000 pixels high?  The file size would be well over 50 GB uncompressed for this map.  Can we say ouch!

So this is where a tile map come in handy.  We can define such a world based on a bunch of images that have been broken into tiles.  Now a 1.5 MB image file could be used to paint this large world we want to play in.  It all comes down to efficiency in the game design and many times developers came up with very creative ways to handle this problem.

So what does this mean to the CPlusEngine project?  Well over the weekend I spent a little streaming time coding a new tilemap system that take an tIDE tile map and turns it into something we can draw on the screen.

tIDE uses an XML based data file so instead of writing a parser like I did for my final course in college I decided to look for a C++ based library that could do this for me.  The good news is I found a couple out there but the specific on being used is easy to pull data out of the XML file.  At this stage I’m not sure if I want to integrate the library into the core game engine or just leave it as part of the game developer to implement.  The good news is this library can perform XML parsing in the billion of lines a second.  So this should be able to chunk out a big tIDE map with ease.

The parsing process might get slow because at this point the demo game is parsing the XML structure and pulling out the needed data to build a map.  I do have a couple of complex maps from one of my previous project that I might use for testing the tilemap system.

Once the tile map was drawing I wanted to test to see if we could also have some interactive elements in the game world.  So once the map got loaded the next thing added was loading a test sprite which already attacked events to the mouse click.  Now the test game can move the test sprite around and see how it draw on top of the tilemap.  This test took one line of code so I’ve been very pleased with how changes to the core game engine are not breaking older code.  Blending the two together has been an easy process that makes the design process go faster.

It still needs code to handle maps that use parallax maps because each layer would need to calculate their world coordinates differently.  Plus I still need to test the camera zoom effect to see if we can zoom in and out on the map.

Also added to the core graphics system was a couple of events to help facilitate the map system.  Since it isn’t an object in the engine yet I needed a way to render the map the the graphic system without actually adding it to the game world.  So the new events that have been added to the SdlGfx class are:

I added these events so that the tilemap could prerender to the frame before game objects were added.  Also the TileMap interface requires the implementation of the Draw(IGraphic *gfx) method.  This design decision was made because the graphic system would get over complex if we injected a tile data structure into the render pipeline.  Breaking the mold out so that the tile map could accept the graphic engine it opened up the render pipeline.  Now complex objects can be created and do special rendering calculations that then keep the core render system simple.

This now opens the render pipeline up so that pre and post processing can be applied to the finale frame.  There are a ton of special effects that can now be added to the frame like the fog of war.

Also added to the graphic system an error event.  This way when an error happens the developer can trap these events and help diagnose the specific issue.  The new error system has an error structure so that it can be numbered and provide an explanation.  The numbers are easier to find in the code then the messages but both are provided as a point of failure.  In the tile map classes this gets used a lot and the errors are pumped onto a stack instead of processed in the event manager.  This may change since now we have added an error event to the event system.

You maybe wondering why this update is starting with Day 10 and not day 1.  This is because a lot of the code was worked on while I was reading a book and those updates got mixed into the review.  As time is available I will reproduce them on this page for completeness.

Spent quite some streaming time re-working the event system.  The original system had some major limitations but after today’s work it now will be easier to use.  The major new feature is the introduction into the event system of the interface IHandler which now allows a class that implements this interface direct access to the event system.

There are still some minor limitations like the class has to use the prototype method HandleEvent and then break out each event it will be listening on.  This event system is still far from extensible as the C# event system but the engine at this point should work fine.

After the core event system got upgraded I then worked on a new controller class that allows for the keyboard to be mapped to special commands.  In future development the command classes need to be broken out into separate files but for now they work great.

Also part of this update include unit test project that I have been using to create tests of the code.  This was added so the engine could grow and the tests could be performed on each iteration to make sure the changes made won’t break further code.  This is also a good learning experience for me to write some test cases that will help me better understand the test writing process.  I do a lot of Assert::AreEqual because currently this test guarantees that we are getting expected values out of the system.