Ignite

Timeframe: 8 weeks (20h/week)

Team: 4 programmers, 3 designers, 5 artists

Engine: TGA2D - Schools in-house engine made in C++ and DirectX11

Inspiration: Super Meat Boy

Contributions

Collision resolve

Developing the enemies for this project was a challenging process that required multiple iterations to get right. I felt somewhat constrained by the limitations of the collision resolution available.
For collision detection, we used a combination of AABB, triangles, and points. The enemies used a point-to-AABB approach for their movement mechanics, which was effective but had some limitations for my purposes.

Zero gravity & flying enemy

Initially, the enemy was designed to move in a back-and-forth pattern upon colliding with a wall or reaching the edge of a platform. The development of this feature was an ongoing process, leading to progressively more complex scenarios. Instead of simply changing direction when reaching the end of a platform, the enemy was set to follow the geometry effectively ignoring gravity. Hence the name "zero gravity enemy".

The flying enemies were quite straightforward. One point on each side, checks for collisions to initiate a velocity change.

<-- Flying enemies

Implementation

The void pointer system (as seen below) for each state was a bit excessive seeing as all states just assigned new velocities and point locations. But the performance impact was negligible anyways, one dereferencing of a pointer each frame.

The zero gravity enemies had a total of 12 points which were used for collision detection, as you can imagine this was really tedious to work with.

If any of the edge points were no longer colliding with the environment, the model would begin rotating in a particular direction. If any of the middle points were no longer colliding, the enemy's velocity would change. The direction of rotation or velocity change depended on the enemy's current state.

Improvements

If I was to implement a similar feature again I would come up with a different solution for sure. First of all, I would probably use a circle for collision detection. Have a downward force vector that constantly points towards the point of contact effectively always pulling the enemy towards the geometry. All the while setting a correct velocity in the direction of travel. Through the downward vector, I could extract the rotation for the model.

Overall, really fun game to work on, and the result was a highly replayable and competitive platformer. This led to a lot of speedrunning within the group. At one point two people got the same time, which prompted us to display another decimal.

See below: first picture with 2 decimals, second with 3.