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.

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!

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.)

Caeeba was a cute and very small game I worked on for the Jumpstart Jam run by Becker College over the summer in 2020. I had some art help from Alexander Nguyen, but all code, music, and sfx were made by me. The game was implemented using Lua and LOVE2D, as well as Tiled as a tile editor and some custom map loading in between. Not a terrible result for a game made in 24 hours!

Short Postmortem: This game really needs polish. Some of the movement and physics are buggy, which could have been avoided if I didn't try my hand at writing a collision system in such a short time window, and I'm surprised we got as many levels cranked out as we did. I started to use Godot a lot more for jams because of its built in physics, which are always something I've found I struggle with in game jams especially.

Seven Nights in Siberia was a game I worked on with 4 of my friends in a discord call at the very beginning of the pandemic. I wrote all the code, created some of my favorite music I've written, and did the sound effects. Two of my friends did the art one of which did the animation, one did the level design, and one dropped out about halfway through. I also tried to keep the whole thing functioning smoothly which was a rewarding challenge on its own. We used GDScript and Godot.

Angus Goucher: programming, music, sfx
Graham Mack: art, animation
Josh Byrd: art
Nicholas Miller: level design
Amanuel Seifu: prototyping, design

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!

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.

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.