All-Purpose Mat

Summary

After playing through Paper Mario: The Thousand Year Door, I was very impressed with how they pulled off the artstyle. This is why, when given the assignment to recreate a "2D" "retro" game in my first year of university, I opted for this one.

I had a lot of fun reverse engineering the formats the game uses. Each character in the game is an intricate collection of small sprites acting as a fully articulated armature, and I got to re-create this system from scratch for my demake. I ended up designing a custom YAML-based format to store the scene graph and all the animations for each character (click to see an example).
I also enjoyed simulating a 3D effect within the 2D limitations of the engine, which I did by remaking parts of the stage in Blender and rendering out layers, then writing a parallax effect to really sell the effect when moving the camera. I am very proud of how well this turned out.

As I use Linux, I undertook porting the entire engine we were given, as well as its build system, from a Windows-only Visual Studio .sln project to a cross-platform CMake system. With that I also brought support for Emscripten and other platforms, which allowed the final game to be playable online!

Another large part of my engine work went to writing a custom OpenGL 2.1 driver on top of OpenGL 3.3. This allowed me to better debug the various systems at play (the de-facto graphics debugger RenderDoc does not support the older API), while keeping compatibility with existing code. I made my engine modifications available to other students, and others have been able to benefit without changing almost any code thanks to my compatibility layer.

Tech Used

• C++
• Custom OpenGL engine
• CMake
• SDL2
• Emscripten

Things Learned

• Hierarchical State Machines
• Graphics API implementation
• Particle systems
• Data-driven animation
• Armature animation

My role

This project was made entirely by me.
The art however is all from Nintendo's game The Thousand-Year Door and belongs to them.

Summary

In 2010, Notch remade Minecraft for a jam in a very limited form, using the now-defunct Java Applets framework.
Additionally, performance was limited by the single-threaded sequential CPU raymarcher which Notch implemented.

I fully reverse engineered the game, and multi-threaded the raymarcher. However, this was not fast enough to run at a reasonable resolution.
I decided to remake it fully in a fully custom GPU-accelerated ray-marched C++ engine.

My cross-platform engine uses a suite of methods to finagle a lower storage footprint, as was the objective of the original Java game.

• Rather than storing them as space-costly PNG files, the textures are generated through unique procedural algorithms at runtime;
• In place of using a large library, the raymarcher is specifically implemented in compact and efficient GLSL;
• Rather than dynamically linking entire DLL files, the build selectively strips unused functions and statically links libraries;
• The accurate fixed-step physics engine is contrived in a single short function;
• Shadows are inexpensively yet precisely calculated through reflecting rays towards the light source and shading accordingly;

However, this was not yet as small as the original. I made it my goal over several years to fit a playable, hardware-accelerated version of Minecraft into a QR code.
That gives me 2953 bytes to work with, which is smaller than the original Java app.

I have fully docummented the journey in a blog post, this was one of the projects I found the most fun.

Tech Used

• C
• Voxel raymarching
• Manual dynamic linking
• OpenGL compute shaders
• Inline x86 assembly
• GNU Makefiles
• Custom linker scripts
• Executable self-decompression

Things Learned

• Data compressibility optimization
• OpenGL performance profiling
• 3D texture handling and generation
• Procedural texture algorithms
• Complex build environments
• Code size profiling

My role

This project was made entirely by me, with support and ideas from friends.

Summary

My first finished game! Octopuzzler is a puzzle game about managing constraints and saving your files into a floppy disk before the octopus's ink covers your computer.
The game was rated 82^nd out of 5800 entries in the Originality ranking on the 2021 GMTK Game Jam.
I wrote its custom C++ and OpenGL game engine as a way to learn both, and what started as a 3D engine with custom physics (I plan to revisit this!) ended up as a very extensible 2D engine which I used for a few other games. I have since ported it to the web, and updated Octopuzzler post-release to work in it.

Tech Used

• C++
• CMake
• Custom engine called "Outrospection"
• OpenGL 3.3 and WebGL 2
• Emscripten
• GLFW
• SoLoud audio engine
• JSON parsing

Things Learned

• Input binding
• Functional programming
• Event bus
• UI layer stack and event propagation
• Resource management and registry
• Platform abstractions (macOS, Android, Linux, Windows, web)

My Role

I wrote the custom engine for this game from scratch, as well as all the gameplay scripting. The art was drawn by my good friend Smudge, and the score was made by OrchidWolf.

Godotcraft (2024)

Summary

I'm always looking to learn new things, and when I read about Godot Engine after the Unity pricing fiasco, I knew I had to try it. To familiarize myself with the engine, I wrote an exploratory research paper on voxel world generation which, unlike Minecraft's, is extendable infinitely in any direction. To achieve this, all logic is (almost) purely based on its location in the world, rather than neighboring blocks. I had a lot of fun working on this!

Click here to view the paper.

The final demo features three different biomes (hills, plains, mountains) seamlessly blended, overhangs and cliffs, infinite depth-attenuated caves, tree and grass generation, and unbounded build height and depth.

Tech Used

• Godot Engine
• GDScript scripting
• Fractal brownian motion and Worley algorithms
• Voxel Tools C++ module

Things Learned

• Noise layering
• Thread-safety via thread-local resources
• Deterministic algorithms
• Chunked worlds
• Optimization through caching

This is my second original game! Using my own handmade C++ and OpenGL game engine supporting desktop, web, and mobile platforms, Reverse Abduction Simulator is a short game which puts the fun challenge of paying extra attention while letting people accross a border of "Papers, Please!" and combines it with the endless character customization possibilities of the Wii's "Mii Maker" into a frenzied rush to repopulate Earth before your alien boss gets back from his coffee break and notices you accidentally deleted all the humans.

We ranked 283^rd out of 6200 entries in the Presentation criterion of the 2022 GMTK Game Jam.

Tech Used

• C++
• Custom game engine
• CMake
• SDL2
• Emscripten

Things Learned

• Z-ordered 2D drawing
• Deferred async tasks
• Cutscene system (see the ending!)
• Web integration with C++

My role

I wrote the game engine used in this game from scratch, and did the rest of the programming.
The art was done by my good friend Smudge, and the audio design and score is by my friend OrchidWolf.

Summary

As a research project, I expanded a university assignment where we write a CPU raytracer to also support volumetric smoke. I used a raymarching technique to step through voxels of smoke, and cast reflection rays to calculate lighting via Beer's law.

Tech Used

• C++
• CMake
• OpenMP and std::execution (multithreading)
• Worley noise

Things Learned

• Generalized lighting equation
• Beer's law
• Tracey live profiling
• Acceleration structures
• Heap profiling and cache coherence

Summary

As I set up my de-Googled phone, one app I could not find a satisfying FOSS replacement for was my Sudoku app.
I decided to instead write this one both as a way to learn Flutter/Dart and as a surprise present for a friend.
It turned out very polished, and I am really happy with it! It is published on the free and open source F-Droid app store.

---

Tech Used

• Flutter
• Dart pub.dev packages
• Android Studio

Things learned

• Android app workflow
• Fastlane metadata setup (for F-Droid)
• Performant UI code design
• Async APIs with futures and promises

My Role

I wrote this whole project myself.

This project aims to “demake” the Virtual Reality game Beat Saber on the Nintendo Wii console.
I used the ideas from this writeup in order to achieve accurate 6DOF tracking on the Wiimote.

I learned to use the Wii's GX GPU API to render sabers and blocks, the JSON format to parse user-generated maps, and the wiiuse library to interface with the Wiimotes.

Tech Used

• C++
• Wii Homebrew toolchain
• KDevelop
• wiiuse
• nlohmann json

Things Learned

• Euler's method of integration
• Low-pass filtering
• Rapid development on alien platforms
• Embedding files into code at build-time

My Role

I made this project entirely myself.

For the DAE Unwrap 2024 game jam, I decided to challenge myself and learn something totally new. I had heard about the WebGPU graphics API, which is a next-generation API that works not only on web but on desktop platforms with high performance.
Its complexity is akin to Vulkan but it is compatible with far more platforms, as it can use many different backends under-the-hood.

I wrote the game engine in two days right before the jam, and we put together a team with fellow DAE students brave enough to try something new.

Tech Used

• C++
• GLFW
• WebGPU
• SoLoud Audio Engine
• Forgejo Git Forge

Skills Learned

• Working in a team
• Learning new APIs on-the-fly
• Git + Kanban board workflow

My Role

I made the entire engine and some of the gameplay logic for this game.
The sound integration and rest of gameplay is written by my friend Yarno, and the art was done by fellow DAE students Luiz, Oskars, Giorgio, and Pelakauskas.