For my first publicly released game, Repulsor, I challenged myself to build a larger game in a short, focused time period by making use of strong up-front planning and time management.
Repulsor is a level-based action game rapidly developed in twelve days.

High-Speed, Iterative Physics Action

Repulsor is composed of thirty, very short and frantic levels where the player can only defeat enemies by pushing them them into hazards, or vice versa, or enemies into enemies!

Being a game heavily reliant on physics, the design leans into a very frantic style: the player is always moving, enemies are aggressive, and projectiles fly all over the place, and everything dies in one hit.

While Repulsor is very action-y, the extremely fast pace actually makes many gameplay scenarios too quick to reliably react to. This interestingly has the effect of requiring the player to plan out their route to beating a level ahead of time- eventually building up a strategy which can fully tackle the level (However, there is a limited slow-motion slide ability to help line up tricky maneuvers).

Persistent Data

This was my first project which made extensive use of persistent data. Levels needed to track high scores and the number of points earned per level, as the cumulative point count is used for unlocking more levels.

To store this persistent data, I coded an entire system for serializing level completion data, settings, unlocks, and customization. As an added piece, I also figured out how to make beta save files backwards compatible!

In learning another engine, Godot (v3.5), I worked on recreating a unique card game designed by game developer Tom Scott, Gridcannon.

Card games can be surprisingly tricky to implement for a few reasons! They require a lot of input validation, complex state machines to match the many game states, and effects / transitions to guide player's attention. Many rules in card games can also be somewhat non-trivial to translate to code.

This project also featured a pretty hearty save system which would also double as an undo / buffer system. Saving information about where every card needs to go and the game state to a file was an interesting challenge to implement, as I wanted reloads to occur smoothly during gameplay without creating unnecessarily large files. I eventually managed to save everything in just 624 bytes!

This project is unfinished, though I would like to return to it or re-implement it in Godot v4 one day.

The Marching Cubes algorithm is a technique which generates an isosurface from a 3D field of scalar values. The isosurface created is a surface which straddles between data points in the field which transition across a particular threshold value.

Marching Cubes was originally developed for and saw much usage in the realm of medical imaging coupled with CT and MRI scans. By obtaining a 3D scalar field of densities within a scanned patient, an isosurface of particular tissue can be rendered by using the known density of the tissue in question. For example, doctors could create a isosurface of the patient's skeletal tissue from the scan to observe abnormalities.

RD_View Implementation

The algorithm itself involves evaluating each data point as a voxel whose edges could potentially indicate a threshold-transition across two points in the data. There are 256 possible shapes within each voxel depending on which edges possess a transition! My RD_View implementation only covers 180 of the 256 cases (which is why there are "holes" missing in parts of the surface), but this is enough to demonstrate the algorithm.

Smoothing

In order to increase the smoothness of the created isosurface, trilinear interpolation is used to ensure that each voxel's transition points are moved to the exact point of threshold-intersection within the data set (rather than at the middle of the voxel edge). This makes the resultant isosurface look less 'cubic'.

Furthermore, the gradient at any given isosurface point was calculated via bilinear interpolation across the surface, which can then be applied to the vertex normal to remove jagged edges and create a much smoother appearance.

Both of these smoothing features can be toggled on and off via command line options, as there may be some cases where smoothing is undesirable or obfuscates the observable data.

In graphics, it is often desirable to model curved surfaces which appear remarkably smooth without having to explicitly place create thousands of vertices.

To achieve this, curves are often expressed as mathematical functions between points which are modulated via control points. This expression is seen in Bézier, NURBS, and B-Splines curves.

In RD_View, we implement Bézier curves as our curve solution, which allows curves to be rendered and modulated via at least three control points. The De Casteljau algorithm is leveraged to perform interpolation between the series of control points in order to find vertex positions across the 2D curve.

Further, a 3D Bézier Patch can be created by interpolating between two or more Bézier curves spanning the same direction, creating a very smooth, curved surface.