Licky Thief is the largest-scale project I've ever worked on in terms of both time and team size. I had a great time collaborating with all of the talented game developers on my team, and it was amazing to see how fast we could make development progress by working together in specialized roles.

This project was a great chance to practice my clean coding skills. Our programming team used a Canban board to organize tasks, and we worked to mitigate merge conflicts by developing each feature on a separate branch and requiring a formal code review before merging a new feature. We detailed guidelines for useful comments in our tech bible, which ensured that our scripts would always be readable and easy to extend. We would often meet up to collaboratively design complex systems, which was a lot of fun and helped ensure our code was well structured.

In this project, I was placed fully in charge of building and publishing the game, which was a mjor challenge throughout the course of development. This was my first time working on a mobile game, so the workflow was entirely new for me. Our final build pipeline used Unity Cloud Build to build the project, and then used Fastlane to upload the builds to Testflight (for iOS testers) and Play Store Connect (for Android testers). Setting this up took several days of reading through MassDigi's legacy build pipeline documentation and adapting it to work with the modern version of Untiy Cloud Build.  Closer to the end of the of the project, I made app store listings for both the Google Play Store and the App Store and ensured that our game met the necessary requirements to be published on both stores. Overall, the building and publishing project was very difficult, but I learned a lot from it - I now feel much more confident in my abilities to independently build and publish my own apps.

When we began developing Gobloilings, the team got together and rigorously iterated on paper prototypes for the game until we came up with a set of rules that created interesting and engaging strategy. I think this early playtesting and iteration was very helpful to the design of the game; it helped us decide on several core features, including the digger's 'swap' ability, the pusher automatically pushing goblins at the end of each move action, and warning tiles to show the contents of the lower floor. This focus on planning made later development much easier, as the whole dev team was on the same page about what features we wanted to add and how they should work. It also ensured that the final game would have complex strategy that encouraged thoughtful decision-making. Despite making minimal alterations to the rules of the game during development, we ended up with a final product that playtesters genuinely enjoyed engaging with, which was very rewarding to see.

My favorite part of making Gobloilings was getting to work with team Three Sheets to the Wind (myself, Richie DeBlasio, Andre Mata Assis, and Gabbi Herbert). Gabbi is a very talented artist, and her artwork and animations really bring the game to life. Andre and I worked very well together as programmers - we had strong communication and were able to easily divide tasks and explain our code to each other. As a result of this, the code for this project is well-organized and well-commented.

The main issue with the final version of Gobloilings is information visibility. The player needs to be aware of the positions of every tile entity on the top floor and every tile entity on the bottom floor, as well as how the top and bottom floors relate to each other spatially. We spent a lot of development time trying to communicate this information, and features such as the yellow warning tiles, the multi-floor crosshair, and being able to toggle focus between the two floors do help, but many players are still either overwhelmed by the quantity of information or unable to find the information they need. If we were to continue work on Gobloilings, information visibility would be the main challenge that we would have to address.

My goal going into this project was to hone my game development skills by creating a finished, polished product. I chose to recreate an existing game because it would allow me to practice my technical game development skills without the additional burden of needing to experiment with the game's design.

I found myself spending the bulk of development time on asset creation. I wanted to make sure everything looked finished and presentable, so I revised sprites multiple times and made unique sprites for every user interface element. This is also the first project in which I've rigged and animated sprites. Every plant and zombie is animated, often with several layers of animation that overlap. This was difficult to do, but I'm happy with the result. I think it really adds a lot of life to the game, makes it significantly more visually appealing.

I began work on this project shortly after completing a college-level sound design course, so this is one of the first games in which I crafted all of the sound effects by myself. This was a lot of work, but I'm glad I did it. The sounds make interacting with the game a lot more satisfying.

While programming this project, I focused on creating clean, readable, extendable code using object-oriented design techniques. This ended up making the programming overall easier, especially later in the project, where I could reuse more of my already written code. I don't intend to return to this project, but if I did, I'm certain that programming new plants, zombies, and levels would be easy due to the high-quality code I already have in place.

Overall, I think I achieved my goal of creating a finished, polished product. The core game has good visuals with no real rough edges, a well-populated soundscape, and high-quality, well-organized code. Having completed this game, I feel much more confident in my technical abilities as a game developer.

This is the first game I've fully completed in the Godot engine. Building it made me more confident in the engine's strengths, but also made me aware of some of its weaknesses (particularly its lack of support for many object-oriented features, such as interfaces).

Developing the game engine was by far the most difficult part of this project, as it's something I've never done before. But I'm really glad I got the chance to try it, because it taught me so much about how game engines work on a fundamental level. Additionally, this is the largest project I've ever built in C++, so it allowed me to improve my C++ coding abilities a lot. I now understand C++ quite a bit better and feel more comfortable working in it, which is great.
The actual game of Spider Shoot was a lot of fun to design. I especially like that the player's 'silk shot' ability is capable of both killing enemies and repairing the grid - it's a nice piece of dual-purpose design that makes the game a lot more interesting. Overall, I think the game is a ton of fun and very polished for a week-long project. I'm very proud of how it came out.

The game has one of the most unique concepts out of anything I've worked on. You play by learning about the boat characters through clues in their dialogue, and then use your romantic intuition to help them find their soulmate. Designing such a unique concept with my team was a lot of fun, and it helped me practice my skills at designing unique gameplay systems. The core of this game rests heavily on writing and character design, which is an aspect of game development I haven't explored much in my other projects, so it was a lot of fun to try it out here. This game is also the largest collaborative effort out of any of my projects; while there were only 3 core developers, assets were contributed by 10 voice actors and 4 artists (see the in-game credits for more details).

Antline is the first game I’ve developed that is both self-directed and thoroughly planned. I spent several weeks simply finalizing a game design document and planning out achievable deadlines. Because of this, Antline boasts a tightly focused design and clean, bug-free code. My development of Antline has been heavily focused on the ‘background mechanics’ of the game (UI, currency system, persistent player data, etc), which I had mostly neglected in my past projects. As a result of this focus, the game feels much more like a full release. I see Antline as an enormous success in that I was able to make a realistic plan and stick to it, and also in that the final product is both fleshed out and genuinely enjoyable to play.