A 2D game engine written in pure C that supports Lua scripting, tilemap loading and rendering, and a script and level editor.

Short Postmortem: This project was a particularly good learning tool for memory management and editor/game interfacing, and I definitely learned a lot from it that I applied to Hyrdogen. I implemented Lua scripting for the first time in this engine, which was a very interesting challenge to try to do efficiently and elegantly, but I think I'm happy with the result. It was also very interesting to try to grapple with C's limitations in this context, as I had primarily previously (and since!) focused my efforts on C++.

A small 3D game engine written in C++ supporting AngelScript scripting, basic 3D rendering, and cloud-based asset streaming. Also includes an editor for asset management and server synchronization.

Short Postmortem: To be written soon

A plugin for the Unity game engine that allows live streaming of assets stored on a server.

Short Postmortem: The Helium Asset Streaming plugin was developed as a small offshoot of the larger Hydrogen Game Engine (see below) that uses the core of its asset streaming. Assets can be uploaded and downloaded from within the Unity editor with fully integrated tooling both in-editor and in scripting. The server is written in Python and serves the content via HTTP.

A game-specific editor for an unfinished 3DS game, written in C++ and C with ImGui for the UI.

Short Postmortem: This editor (GnagTool) was a tool for designers to create, iterate, and test levels for a game (Gnag) for the 3DS that I directed and developed with some friends over the summer in 2024. The game engine and code were written in pure C using the homebrew 3DS development kit "devkitARM", so there was a need for a designer-friendly interface tailored to the specific game we were making (a turn-based strategy game.) I implemented a level editor and a UI designer, both of which support drag-and-drop as well as data editing, and export to JSON for loading in the game engine.

Carve your path through the galaxy in this space farming roguelike - destroy slimes, plant bombs (and plants!), and crush bosses while collecting tech points and seeds to improve your drone. Explore an endless universe of hostile worlds! How long can you survive?

Short Postmortem: This is definitely the most complex game I've had the privelege to work on so far, aside from large-scale projects in internships or other jobs. I was lucky enough to work with and direct two other programmers (Xavier Olmstead and James McKibbin, the whole team was just us 3 programmers!) and put together what I think is a really excellent and fully realized project. With the guidance of Simon Marchand, a Montreal professor and programmer at Ubisoft, we spent 3 months creating this game. All three of us shared programming responsibilties of course, but in particular I worked on and architected the underlying systems such as world generation, graphics and shader work, state management and UI interfaces, and movement mechanics/enemy AI. I also created all the art and music, as well as managing the codebase and making sure the project was on track to meet our deadlines. We utilized Unity and C#, and I built custom in-editor tooling for the in-game cinematics and sequencing, world generation iteration, and enemy AI state machine control. Please give it a try and let me know what you think! We're all super excited to share this project.

Make words and blow up tiles in this Tetrisesque puzzle game.

Short Postmortem: I put this little combo of Tetris and word-searches together in 48 hours for a game jam at my college, and I'm exceptionally pleased with how it turned out. It's the first time I scoped for an idea fully and then actually entirely completed the scope within the time frame I had, with multiple hours left over for 3D graphics and excessive polish. I personally have a ton of fun playing this one, and I hope you enjoy it too if you get a chance to play!

Fight your way out of a dungeon while crafting new and unique weapons out of monster pieces!

Short Postmortem: Braeden Trefethen and I put this together in 72 hours for the Ludum Dare 55 game jam. I did all the pixel art and the programming, and Braeden handled the audio, both music and sound effects. For this project we decided to try to integrate the middleware Audiokinetic Wwise, which worked out really well and allowed Braeden to have much more control over how his audio is presented in game and also serving as a really good learning experience for both of us. Although the results haven't been released yet, we're both super happy with how it turned out and are excited to see how people like the final product.

An endless cooking game where you play as a dragon and balance managing your kitchen with dealing with a human infestation!

Short Postmortem: I spent most of this semester developing in Unity for classes and projects, so getting back to Godot was really refreshing, and Champlain Montreal's Thanksgiving game jam was a really great opportunity to do so. I worked solo and had a really good time experimenting with Godot's pathfinding meshes and UI hierarchy, systems for generating satisfying but challenging orders, as well as pushing myself to create the best pixel art I could in 48 hours. I'm beyond happy with the final product and I find it as fun to play as it is nice to look at which is a new balance for me that feels really gratifying to finally reach. I've also been working on adding some extras to it in the weeks since I finished it which I'm looking forward to publishing for everyone to play as well.

DEATH AND TAXES is a short game about pushing papers and pedestrians off of ledges to try to obscure the evidence of your tax fraud. Submitted for Ludum Dare 50.

Short Postmortem: This is definitely one of my favorite projects I've worked on; it's super polished and was my first time trying to set up a good system for cutscenes and simple animations, and I'm very happy with how the intro cutscene turned out. Unfortunately, the gameplay is a little abbreviated because of all the effort that went into the beginning of the game. I wish I would have spent a little more time designing fun levels or at least giving the gameplay more attention. It's still fun and I'm super pleased with how it turned out but it's a little more short than I would have liked. I think establishing the gameplay in an almost overkill, crystal-clear fashion might have helped with that - I think I stalled a bit when adding polish because I wasn't completely sure of the gameplay. Overall, very happy with the results and I'm glad I got to try to do some new things in Godot. Placed 95th out of 2900! (And 31st in Humor!!)

VoiceOS is a small operating system style game made for the Mini Jam 100. I completed it in 48 hours with Braeden Trefethen and Jacob Nelan, who helped out with the audio and design, respectively.

Short Postmortem: Highly polished, and I'm super happy with the way the visuals came out. This was my first foray into vector art, and after floundering with Illustrator for a moment I landed on Photoshop for all non-pixel-art graphics. The audio is very nice, although I wish I had requested more audio from Braeden to create a more dynamic game. The weak point for this game was the gameplay. It's pretty shallow and not the most engaging because we tried to have many gameplay loops at once (leaning into the chaos theme). On the programming side, the challenge that I'm not sure I fully tackled on this project was the focusing system and making sure the user can't click on items that are occluded by other windows or that shouldn't be interactable. There are a few bugs in that area, but retrospectively it seems like it doesn't get in the way of the gameplay very often. Overall, I think we hit the tense and frenetic design we had in mind, and I think the visuals really work well for the aesthetic and building a bunch of smaller, more polished gameplay loops was really rewarding from a programming perspective. Placed 6th out of 176 entries!

WOBBLE is a short game I created for Ludum Dare 49 with some design help from my friend Braeden Trefethen. I programmed the game using C# and GDScript (Python) in the Godot Engine, as well as creating most of the pixel art and graphics and about half of the music. Levels were designed using the in-editor tilemapping system. Placed #94 out of about 3000 entries in the "Fun" category!

Short Postmortem: Playtesting was super crucial for this game. It's a puzzle- and skill-based design, so tuning was essential, and I'm very glad that we were able to test the game with our friends and polish it to a fine sheen. I'm also glad that I limited the scope of the art severely - it's cohesive while retaining charm and character that helps set it apart in a flood of Ludum Dare submissions. If I could change one thing it would probably be to fix some of the mouse controls, and to try to test with a wider gamut of people - some found the mouse controls to be buggy or unintuitive, which our test group of mostly gamers was able to get past more easily.

Balance-game is a game I created for the eighth installment of the Code in the Schools game jam. I worked with my friend Nicholas Miller, however everything that ended up in the final product was created by me. I used Godot with C# and GDScript/Python, created the pixel art graphics in Aseprite and made the music in FL Studio.

Short Postmortem: Scope was great on this game. I had a borderline too-simple concept that I executed solidly. The art for this game took the bulk of the time (especially because it goes hand-in-hand with the level design.) I would probably have made the game a little less detailed and added more levels or polish if I could go back, but this was a really great experience, even if I did have an unfair experience advantage. Placed #1! (In an admittedly very small and local game jam.)

A short Metroidvania-type game I put together on really outdated hardware in high school; simple platforming physics and basic AI. About 20 minutes of gameplay total!

Short Postmortem: The engine I wrote for this game is pretty bad. It's all very hacked together in a way that having a really open framework and a dynamic language permits, so I blamed most of my bad design choices on the flexibility of Lua and LOVE2D. It was definitely part of the issue, but I also had minimal experience making game engines. This ended up sending me down a rabbit hole of making game engine experiment after game engine experiement in various languages, and was overall a positive thing for me that might not have happened without this game.

Keeping the art super limited was a big help for this game. I kept each tile (including the player) to 8x8, and there's only 6 colors in the game total. I think these limitations made it much easier to go from idea to implementation, and probably helped with the longevity of the project. I would not want to do this again without someone to collaborate with.

A "drum machine" that can generate physics-based rhythms over MIDI and allows the user to move around platforms and portals to create complex emergent "music" or experimental noises and beats.

Short Postmortem: I really enjoyed working on this one for my VR Development elective sophomore year, and I particularly am happy with how the controls feel to use and how fun it is to play around with. It really is very inspiring and it would be cool to see it integrated in a larger MIDI-based synthesis set up. Most of the work on this project went into the MIDI integration and tuning the Unity physics to make sure it was relatively stable over a long period of time as well as working with the limited set of inputs I had to work with on the physical controller and devising an input scheme that was intuitive enough while also being powerful enough to really manipulate the objects and their arrangement in space. It's not great at keeping basic rock-and-roll time but what it lacks in stability or conformity it definitely makes up for in inspiration! Hopefully others find it as fun to play with as I do, it was definitely enjoyable to put together!

Make A Lisp is an online course/tutorial that details how to implement an interpreter for a Lisp-like language. It helped me learn a lot about data driven programming and about how the internals of compilers and interpreters work. I worked with Quintin Forrer on the project, however we both wrote our own copies of the interpreter.

I was able to skip Python and Advanced Python in high school, and jump straight to the "advanced" CS elective. In sophomore year I took Distributed Computing which focused on the networking and architecture required for processing across multiple computers. For my final project in that class, I worked with Quintin Forrer to implement a peer-to-peer networked "game" that turned out more along the lines of a tech demo, but it was still my first experience with multiplayer even if it was in a somewhat unconventional way. We used C# and FNA(?). I can't remember what made us go with FNA over something more conventional like Monogame. NOTE: The GitHub version looks like it's incomplete.

This is a small GameBoy program that I was hacking on with the intent of creating my own tools (besides the compiler). It's using C and GBDK to compile the code, as well as two Python scripts for converting Tiled- and PNG-format assets into compilable C headers. It was also a really interesting experiment to compile my code to intermediate Assembly and look at how things I did in C affected the generated code. I'm interested in finishing this and making it a full game, but I don't have any ideas at the moment.