Devlog #01 - Calm after the Storm

There have been a lot of changes to the RawSalmonEngine over the last few weeks. Now that the workload for the summer semester has settled down, I could finally find time to breathe some life into the project.

Terra Australis Alpha #1 Bandicoot

"Terra Australis" is the demo game we designed as a testing ground for the engine. For the first Alpha we have now finally defined all the necessary features which must be implemented so that finally a small game can be made of it.

1. Map change in general
2. Death of the player including reset to the beginning
3. checkpoints
4. Collectable objects (coins, for example)
5. User interface with health points etc.
6. Menu

We are currently working on realizing all features, but meanwhile I had to realize that some problematic sections have accumulated in the code and begged to be restructured. The scope was anything but small, but now I am much more satisfied because working with the codebase has become much more comfortable for me as a developer.

Event System Refactoring aka. C++ Template Hell

The events run the logic of the entire gameplay and therefore they are integral to the engine. They are parsed via XML files (currently integrated in the tiled map), can hold data and modify an object via its public interfaces. This means, if a character should run over the map, you can send one or more events to animate, move and check for collisions.

The old approach had two main problems;

• The memory management of the events ran via an "intermediate" class in the inheritance hierarchy (I wanted to somewhat prove myself that I could get something as crazy as the CRTP to run in this context 😀).
• And the type of objects on which the events operate was fixed, which had a lot of duplicate code.

Now the parent class is no longer "ActorEvent" but template-ized "Event<Scope>", which allows to implement events that can operate on arbitrary objects. In addition there is now the template class "SmartEvent<Scope>" which takes care of the memory management of the evil event pointers. Also the "registration" of the events with the parent class was automated, now nobody can forget this step and wonder why the parser complains that the event is of unknown type.

The icing on the cake; I finally wrote a small Python script which generates new event classes. So you only have to add member variables, tell them the parser and you already can start writing the "actual" code executing the event.

Stop MapData from being greedy

The class "MapData" was long enough the jack of all trades and got relegated to its place. Much of the functionality it has stolen from tilesets and map layers is now in the "TilesetCollection" and the "MapCollection" which are much better suited for these tasks.

Also new is that there's not only "one" map anymore, but maps are created on a stack to easily create something like menus, pause screens, etc... Fittingly there is also of course a "LoadMapEvent", which was much easier to implement due to all the previous improvements.

Further outlook

A lot of progress has been made, Feature 1 is done and for 2, 3 and 6 a solid foundation was laid. My next goal is to restructure and unify the collision, primarily for feature 4. Currently, the collision process is more or less topsy-turvy.

• First the standard hitboxes of the actors will be checked for collision with the standard hitboxes of the tiles (which happens automatically when the actors move). 
• Then all hitboxes of the actors are checked for collision with all hitboxes of the tiles except the standard hitbox.
• And then the collision of all hitboxes of the Actors with each other is checked.

If the check of the collision is positive, the callback "onCollision" is triggered (which is implemented as an event), which additionally contains information about the collision partner and the names of the hitboxes.

In addition, the active frame of the animation should also carry hitboxes, temporarily add them to the actor and temporarily overwrite hitboxes of the same name. Especially for fighting games like "Street Fighter" with different hit and attack zones this should be very useful.

"Nice to have" would of course be the render orientations "Isometric" and "Hexagonal" as well as all four possible rendering orders. Since I have to work on the MapLayers for the collision anyway, I could just implement it while I'm at it.