"Submachines: Totally Tanktical" is a topdown, tankbuilding, rts-like game, where you construct a tank from modular parts to combat other tanks made of parts, in a post-apocalyptic world where mankind has reestablished civilization under the sea.

I was brought onto this student project and made to be the lead programmer.

Programming-wise, our programming team inherited the project in a prototype state and were tasked with adding to it. This involved remaking many important systems with leaner more robust algorithms, cleaner architecture, and more thorough documentation. As the project progressed, we managed to improve the overall quality of the systems present as well as build on top them to reach our target scope.

My responsibilities and priorities were:

• Communicate with the product owners to determine what features they wanted in the game
• Ensure that the product owners were kept up to date on all programming tasks, as well as describe the technical problems in a way they could understand
• Delegate tasks to programmers to ensure each member knew what each was doing without stepping on each other's toes and establishing priorities of what needed to get finished before moving on to other things.
• Keep up to date with every member of the programming team and the work they were doing, giving feedback and having peer discussions about their work.
• Create tools and libraries that other members of the team could use, such as the designers, artists, and other programmers.
• Manage a PlasticSCM repo for our version control, ensuring that people were using it properly so that everyone could work on the project simultaneously
• Assemble the builds for the game, rallying other members to get their changes in on time, and making bug fixes and adjustments as needed for the game
• Showing off the game at expo events, like PAX East and the Clark IGDA expo.

Systems I worked on:

• Performance fixes: At an early stage in the project, we were well below our target 60FPS, instead landing somewhere between 20-30FPS. After investigating possible causes in Unity's profiler, we identified the number of meshes being moved each frame as the cause. To solve this, we disabled the meshes from being active until they were needed for specifically placing blocks, and we successfully hit our target 60FPS.
• Block pre-placement visual: Players were having a difficult time seeing where their blocks would be placed when building their tank. So I created a solution that integrated with the existing codebase to place a visual in the game to instantiate an object that would preview a player's placement. Which helped clarify the building functions of the game for players.
• Automatic object initializer: We encountered problems in project organization where some essential items may be missing in the Unity scene. Using Unity's Editor namespace, I created a way to initialize necessary objects for scenes, as opposed to needing the game designers to put it in manually. The tool would load in a prefab to the scene when it was loaded in the editor, and if it was in the list of scenes that needed to have objects loaded, it would load them.

Systems I remade:

• Camera movement: The camera system had multiple bugs in its implementation, many of which were due to its heavy reliance on raycasts. I reworked it to a more robust and simpler solution that simply took the user's cursor input on the screen to move the camera. It has the ability to zoom in and out, pan away from the tank and snap back to it, and the ability to rotate around the object of interest.
• Material Assignment: Our material assignement system was difficult to work with, as it required multiple steps to reassigning materials that overcomplicated what was normally a simple operation. I reworked it no longer need the redundant intermediate steps, and later expanded the systems to handle assigning proper textures for the different damaged states of blocks. With the new system, it was easy for others to add new kinds of blocks to the system, as well as make it easy to assign the proper materials to specific tanks.

"House of Sin" is a horror-inspired "shoot em up" game, where you play as a demon hunter tasked with exorcising the reincarnations of the 7 Deadly Sins that have taken hold of a house. Through each demon you manage to defeat, you are further burdened by their curse, but are also given the power to break them for a short time to gain supernatural abilities like slowing down time. Built in Unity as part of IGDA Clark's 48 hr Halloween Jam 2024.

I was one of the programmers for this game.

My features:

• All the boss code for the two major bosses in the game, Wrath and Gluttony.
• A finite state machine to cycle different boss phases, resulting in dynamic gameplay exemplifying the characteristics of the bosses.
• Event-driven architecture to keep each aspect of the game loosely coupled, and quick to iterate upon.

"DELETE SYSTEM 32" is a sci-fi, shmup game where you play as a rogue computer virus attempting to destroy a computer's operating system. You are thwarted by the system's antivirus software, and must destroy it to achieve your goal. Built in Unity as part of IGDA Clark's 48 hr February Frenzy Game Jam 2024

I was the sole programmer for this game.

Game features:

• Procedurally generation of the towers and enemy spawners in the playspace, making each play through slightly different than the last.
• A finite state machine to cycle different enemy AI behaviors.
• An endlessly scrolling screen to emulate old arcade games, a feature not native to Unity.
• A drop table system for random powerups.