Devlog #02 - Collision Time!

The motivation high continues and since the last Devlog the next 9 commits have already settled on the master branch. One of my biggest worries is now finally done with all the important core functions, notifying, detecting and reacting to collisions! In order for everything to fit together properly, many individual steps were needed:

Variable Hitboxes

It was not possible for the old system to switch through active hit boxes during operation without further ado.

Now, when requesting hitboxes of an actor, a search is performed via the active animation and even via its active frame. This means that for example in a combat game the hit boxes are adapted to the character's movement frame by frame, without any additional effort on the part of the designer. The hitboxes are simply inserted like with the actor and the system selects the most specific suitable hitbox. This makes games with many hit or attack zones, such as Beat'em ups, much easier to implement.

The sudden redefinition of motion-relevant hit boxes is by definition a bit buggy, because suddenly unexpected new collisions can occur where there were none before. Since the previous collision detection only works properly if it is guaranteed that the hitbox is free of collisions before, an "unstuck" is executed preceding each movement, which "pushes" the hitbox out of other hitboxes in the shortest possible way. It is a bit unattractive, already a candidate for refactoring, but now even the most bizarre cases work properly.

Uniform Requesting of Map Sections

Both the rendering of the image and the detection of possibly colliding tiles or actors now runs via a uniform interface. One simply passes in a rectangle in world coordinates and gets a list of the tiles or actors that are in it or intersect with it. Much old inefficient code could now be deleted and the code base is much easier to maintain. This has the additional advantage that now in typical WYSIWYG manner the hit boxes can be up to congruent with the pixels of the tile even with oversized tiles. Before, Hitboxes were limited to the basic tile size. In addition, this will further facilitate the implementation of other tile shapes (isometric, hexagonal).

Passive continuous Collision Detection

The detection of collisions that are not motion-relevant now takes place in a rather deep but not too complex function that iterates over all possible collision partners and their hitboxes per hitbox and checks for collisions. Thanks to the "uniform interface" this is finally no longer a problem. 

Due to the many simplifications and the better abstraction I'm already thinking about when to switch from the AABB("straight" Hitboxes) approach to the OBB("angled" Hitboxes) approach. Now there is in any case much less in the way.

New Benchmark Map

It has been a thorn in my side for a long time how untidy the included example map is and that many assets that actually belong to the "Terra Australis" project are squandered. Therefore, the map has been replaced with a very minimalistic approach that also has a very small tile size (16x16 pixels) and thus takes the second function as a small performance test.

And many many small Things

• Integration of continuously playing music possible
• Camera can be decoupled from the player via events and moved freely
• Symbolic tile sets (which read events or keystrokes) are read into the map properties
• The map entry point is now main.tmx
• Memory management of map layers has been simplified with Smart Pointers
• Removal of superfluous "Speed" attributes

Next Steps

The most important thing is to insert an event as soon as possible, which processes another specified event depending on the collision partner and/or the hit boxes. This is a big part of the game logic. Top things can hurt, power ups do their thing. The whole stuff :-)

The new benchmark map showed me that the engine is very robust even with edge cases. But what bothers me is that the collision detection reaches its limits at high accelerations and very small hitboxes (16x16 pixels) and leaves unattractive visual bugs behind. The complicated approach to solve this would be a Swipe based collision detection and other black magic, but it would be much easier to increase the update rate so that smaller motion steps can be processed better. I will do that soon.

Furthermore of high importance is the implementation of the different tile shapes. I think it alone would be a great figurehead if the engine could handle diamonds and hexagons as well as rectangles.

I know that Terra Australis needs a lot of time and love being a full fledged platformer, so I'm currently flirting with writing a pong-esque little game as a side project that shows: Hey we are here and alive!

I hope the next days will be as productive as the last ones. In any case, I see a really bright future with the RawSalmonEngine!