Location:
On a train traveling between Chicago and San Francisco.
Description
In the aftermath of the most devastating battle in recorded galactic history, one ship, crippled and broken, survives. However, a nearby star has begun to collapse into a black hole, drawing in the remnants of the battle. In order to escape this fate and return home, the pilot must scour the battle field for any parts in the debris that can be salvaged for their craft. Armed with only a damaged engine and a tractor beam, will the pilot survive and return home?
Contribution
This game was made in 52 hours during Train Jam 2018, aboard an Amtrak train from Chicago to Emeryville, California, en route to GDC.
My role was gameplay programmer, focusing on the player controller and gameplay loop. Our original focus had been on 2D spaceflight and a tractor beam to pull in the various ship parts needed to repair the player and achieve the victory condition. When our design was altered halfway through the jam, I focused mostly on the physics-based tractor beam and using it to sling mines into wreckage to reveal replacement parts.
The design was altered to focus on the physics and tractor beam due to play-testing feedback. Originally, we had included mines as a hazard that could be accidently grabbed by a distracted player when they were trying to pick up a replacement part to add challenge. However, we noticed that due to an unrefined tractor beam, players were able to slingshot pullable objects. In fact, players would actually seek out the mines and other draggable objects and just sling them around wildly instead of seeking out their objectives. Based on that observation, changed the core mechanic to be slinging mines to destroy debris.
Lessons Learned
Our initial design included a simple AI system for enemy entities and a simple level generation system that would build a level based on some premade room prefabs. The AI system, though primative, was in place and working well, but was later scrapped due to the fact that the final level design included lot of dynamic, moving objects. The simple AI system was not equipped with an obstacle avoidance system that could adequately handle non-static obstacles. However, I did interate on that code to create my AI Steering Behavior system.
Light The Beacons
Engine: Unity
Language:
C#
Description
Light The Beacons is a retro style adventure game centered around fire. The player controls a castaway who has washed up on the shore of a mysterious island, littered with ancient ruins. Armed with only a torch, the player must master the challenges hidden within the ruins and reveal their purpose.
Light The Beacons is based around the concept of fire, its attributes, and how it interacts with the world. Themes of light, heat, and ingition play into the core mechanics that the player uses to solve puzzles and progress through the shrines and the world.
Completing a shrine will *light the beacon* on top of it. Light enough beacons and the mysteries of the island may start revealing themselves.
Awards
Media
AI Steering Behaviors
Engine:
Unity
Language:
C#
My 2D Vehicle AI library was designed based on Steering Behaviors For Autonomous Characters by Craig Reynolds. The state machine used by each actor is designed using the Delegation Pattern, where the actor's controller class is passed through the state to its actions and decisions, with any state change being applied directly to the controller.
Current steering behaviors supported:
Seek
Pursue
Arrive
Flee
Evade
Avoid Obstacles
Wander
The library is designed to support non-steering actions, such as attack, that integrate seemlessly into the system, allowing a designer to create various states that can comprise of multiple actions with ease, all with no code changes. For instance, an attacking state for a starfighter could compose of seek/pursue as well as an attack action that controls firing missiles on an interval. A different state could be created for the fired missle that has a pursue action as well as actions and decisions to handle a limited lifetime before object destruction.
This type of flexible design is thanks to Unity's Scriptable Objects. Using scriptable objects rather than just regular C# classes allows the classes to be accessed in the Unity Editor, without the excess overhead of the Monobehavior class. This is where the magic happens, whereby using this architecture, different actor types can be created entirely in the editor, with no code changes needed, so long as the pieces exist. It's basically a bin of Lego's that allow a designer to put together sets from the available pile.
Auto Taxi is a small little game where the player is the operator of a self driving ride share vehicle. The idea for Auto Taxi came while implementing the IGrid interface of my pathfinding library to handle an any-angle type nav map. I wanted to prove that my A* IGrid interface could truly handle non-grid based nav maps and the idea of non-uniform city streets struck me. It also game me the excuse to use wonderful Gallet City tileset by Adam Saltsman.
In Auto Taxi, the player plays the part of a remote operator for an autonomous ride share company. When the car has no passenger, the operator selects the next rider to pickup from a list of active users. They are given the pickup and drop off locations, as well as a final fare, which is calculated based on the distance of the ride and adjusted for the operating cost to drive to the pickup spot, so it is possible to have a selection option that would result in a net loss for the company. Once a rider is chosen, the car will drive itself to the pickup and drop off points. The navigation for the autonomous driving uses my A* library with the aforementioned nav map implementation.
Depth of Extinction is a squad based, tactical turn-based strategy game with rogue like elements developed by Atlanta-based Heart of Fire Studios.
I was brought on to play test new builds for bugs and feedback on the gameplay experience. I meticulously tracked and recorded unreported bugs and gameplay issues while also verifying the bug fixes and new features in each build. I was brought on during the final months leading up to release and also was contracted back after release to test some post-release patches.
Trailer
Who Needs Heroes
Role:
Programming, Design, Art
Engine:
Unity
Date:
Fall 2018
Who Needs Heroes was made during the Gamemaker's Toolkit Jam 2018. The prompt was Genre without the main mechanic. I chose a MOBA without heroes.
Gameplay
Who Needs Heroes is a single player game against an AI opponent. The player has an "ancient" to defend while both sides spawn waves of creep units every 30 seconds. When a creep scores a kill, their player is awarded some amount of gold. Gold is used to upgrade the creeps in one of the three lanes. The goal is to overpower your opponent and destroy their towers and eventually their ancient to win the match.
Upgrade System
The player spends the gold earned by their creeps on upgrades. For each of the three lanes, the player can choose to permentantly upgrade one of the creep types (melee or ranged) that spawn in that lane for a high cost. The permenant upgrade increases damage, health, and move speed by a large amount. Alternately, for a much smaller cost they can choose to upgrade one of those stats, but the buff only applies to the next wave that spawns. The idea behind the temporary buff is to be able to strategically boost a lane to tip the scales and take advantage of an opportunity.
AI Player Behavior
Since this was a solo jam game, I did my best to code a simple AI system that still allowed for variance in decision making. The AI player has the same upgrades and gold system as the player. It behaves in an pseudo-turn-based mannor. Its decision making goes as follows:
Before every creep spawn (every 30 seconds) the AI rolls a dice for one lane.
Based on the roll result, it attempts to take an action.
The AI will then attempt to take the chosen action.
If the chosen action exceeds the amount of available gold, the action will not take place and no re-roll occurs. This lane is "passed" for this turn.
Importantly, the current available gold does not affect or weigh the dice roll.
With the above system, it would be very likely that the last lane to have a decision made would have a reduced gold pool, and thus always be weaker due to lack of upgrades purchased. To avoid this scenario, the order in which the AI makes decisions is also randomly set. Each lane thus has a possibility of being evalutated earlier in the turn, when the gold pool is higher, thus increasing the possibility that it will receive upgrades.
Location:
University of Georgia College of Engineering
This was my term project for a Virtual Reality Course at the University of Georgia. The requirements were that we had to use 2+ different types of virtual reality instruments (inputs/outputs/displays/etc) and follow the theme of "Disability".
Using the Unity 3D engine, we built a smart apartment for a wheelchair bound individual. We used an Oculus Rift DK1 for display, a Razer Hydra for movement, and an iPod Touch as an additional input. The big feature was taking the input from the physical iPod Touch's screen and mapping it to a digital representation of a smartphone inside the VR environment. The user could then control a multi functional "app" we built into the scene to control various aspects of the apartment. These included opening and closing doors, various lighting fixtures, and electronics such as TV and radio.
Unfortunately, there is no easily playable version. This is because the middleware and app used to link the iPod touch to the experience was software written by my professor and kept in the lab, but I can at least describe how it worked. What it basically did was transmit the input data from the touch screen to a server running on a Raspberry Pi. Then, Unity would read in that data to a script which the other scripts could then access and use.
Student Projects
The Adventures of Ninja Boy was a class project during my undergraduate program at the University of Georgia. It is a 2D action platformer in the style of the Mega Man. The requirements of the project were more focused on basic gameplay and learning the engine, as such, the AI is nothing spectacular. This was made entirely in ImpactJS, a Javascript game engine. In addition to the programming and design, all art was done by me.
A little pathfinding demo I built as part of refreshing my knowledge on A* pathfinding. The code is light weight. Any calculations that vary between a grid type or heuristic are handled by an interface implementation. The core methods of the interface are GetNeighbors(), GetDistanceBetween() - for GCost calculation - and GetHCost(), because these are needed in general for A* to function, but will vary based on the navigation grid/map implementation. The core A* pathfinding algorithm code remains unchanged reguardless of what implementation is used.
Currently, I have implemented the following Grid Type and Heuristic pairings: 4 Directional/Manhatten Distance, 8 Directional/Diagonal Distance, and Any Angle/Euclidean Distance. All of these are available in the demo project. Next on my list is to implement a Hexagonal Grid implementation as well as weighted tiles, both of which should still be just different implementations of the IGrid interface.
Have you ever wondered how carrier pigeons always know how to get to their destination? The answer is Intuition! In Carrier Pigeon, two players must work together, one as Carrie, the carrier pigeon and the other as her Intuition. Featuring a split screen blocked by a piece of cardboard, both players are given half of the information needed to make deliveries and must work together through verbal and in game mechanics to find their destinations, all without being able to see either other's half of the screen!
Contribution
My primary role was gameplay programmer, focusing on mechanics dealing directly with the pigeon player control and the main game flow. Each frame, the pigeon moves forward. Its rotation is determined by the location of the mouse cursor. The amount of rotation per frame is limited and smoothed, but the forward movement speed remains unchanged by rotation. This produced a very floaty, gliding feel to the flight movement that got a lot of positive feedback in playtesting and demoing at the Jam.
Challenges overcome
Obstacles such as mountains and forests posed an interesting issue since player forward movement was never stopped. To address this, we implementated a bounce system wherein upon collision, the pigeon's speed was reversed a a bounce multiplier applied. This resulted in a fast rebound, with a window of time when the acceleration was ramping up to max forward speed that the player was essecially floating in place. This window gave the player enough time to rotate and course correct to avoid the obstacle.
AstroMender is a StarFox style arcade space shooter where the must collect energy to survive. AstroMender was created in 48 hours by a team of 10 during Global Game Jam 2020.
The player's ship is damaged and leaking energy. The player must fly around gathering energy crystals floating in space while defending themselves from enemies. Filling up the energy bar will repair one of the damaged systems and give the player a new ability. The catch? Every action - from shooting to steering to taking damage - also costs energy, depleting the ship's energy reserves. If the energy bar runs out, a system returns to being damaged. Run out of energy with all systems offline and the ship is destroyed. Survive as long as possible and rack up a high score!
Contribution
My primary role was systems programmer, focusing on the core energy and upgrade systems. I also assisted with small features like the score system where needed.
Energy and Upgrade systems
The energy system has an interface with simple methods that all other parts of the game can call. For instance, if the player presses the shoot button, the player controller will just call the Shoot() function in the interface. The energy system will then evaluate if the "guns" are powered, if the ship has enough energy to fire, and if so, will deduct the energy cost and return a true value to let the calling function know the shot request is approved. The energy system does not actually fire the shot, it determines whether or not an action can be taken, alters the energy level accordingly, and returns its decision.
Loot system
I also developed a rouge like loot system. After a player had repaired all core systems, they could still level up by collecting energy. If this happens, the player would be prompted with 3 options for buff items. Examples would be a small boost to attack speed, reduced energy cost for boosting, damage reducing armor, etc. The chosen buff would be added to the ship. It would function like one of the core systems, where they could be damaged and repaired based on energy levels. This system would allow the player to author a "build" for each run. It was unfortunately disabled in the final Jam build due to us not having the time to balance the loot, but its still in the code.
