Brett Schiff

I was a physics, AI, and gameplay programmer on the team. I also designed and implemented a few of the scenes in the game.

Physics

I wrote the entire physics engine myself. Acceleration and velocity were handled by the Verlet integration method.

It supported colliders of various shapes: rectangles, circles, and 2D capsules. I mainly used the Seperating Axis Theorum(SAT) for collision detection, but I optimized checks that could be faster, for example, circle to circle and axis-aligned-bounding box(AABB) to AABB. All colliders can be rotated, scaled, and offset relative to the object they are on independently of the transform of the object itself.

It had a collision layer system that allowed the user to specify a "layer" on which each object would exist and which other layers any given layer was willing to collide with.

There are 3 different types of collision resolution: solid, passthrough, and oneway. Solid passthrough was typical collision as you would expect; passthrough collision recorded the collision and let other systems know that they two objects had collided without resolving the collision, letting the objects pass through one another; and oneway collision made an object only collide with other objects on the top, which was used for one-way platforms in the game.

The system also allows for raycasting into any layer.

AI

I wrote the AI for the three types of the enemies in the game. We didn't have a true AI system C++ side, so AI was done as a script in Lua that was attached to objects.

One enemy was a flying type. It would patrol an area—either a circle volume or a path along a line—looking for players. When it spotted one, it dive at them after a brief delay, overshooting the target by a short amount if it missed. After a dive, it attempts to return back to its patrol area but starts looking for players again after a delay even if it hasn't reached the original patrol area yet.

The next enemy is a stationary "archer" type. It looks for players in its vision and when it sees one, it fires projectiles affected by gravity at it in a firing pattern specified by delays between shots. Before each shot, the enemy checks to make sure the player is still in range and visible(eg. not hiding behind an object).

The last enemy was a simple "goomba" style character that walks back and forth. We added two things to that: it didn't walk off edges, and when it was attacked but not killed, it got "scared" and moved faster. However, we ended up cutting the scared effect because it didn't test well.

Gameplay Programming

I implemented a bunch of smaller features that contributed to the overall fun and feel of the game. Some of the larger notable things were accelerators, firework cannons, and breakable platforms.

Accelerators are object that use linear interpolation to bring any object that touches them up to a certain velocity. In the game they are displayed as pillars of "wind" that blow players upward. This eliminated the need for bullky and unfun stairs that were common in our levels before accelerators, and they playtested pretty well.

The firework cannon system was a completely customizable system that would shoot firework objects, each of which would spawn particle trails and a big particle "explosion" at the top to look like fireworks. They system ended up being way more intricate and customizable than we needed, because the cannons ended up only being used in the victory screen.

Breakable platforms acted as normal platforms to a single player, but if multiple players stood on the platform, it would break, reforming again after a delay.