Category Archives: Portfolio


Ctrl-Seek was a game developed at the 2015 Global Game Jam. It’s a two player game that creates interesting social interaction by having two players to share a keyboard. Before each match, each player sets the movement controls for the other. Each player turns away from the screen while the other sets his or her controls. When the match starts, neither player knows which keys to use for movement. Players must try different keys around the keyboard in order to gain control and destroy the other player.

Gameplay Systems


For player movement, we knew that players were going to be pressing many keys in succession to try to find their correct movement keys, so our goal was to make it fairly obvious that you had hit a movement key, even if you just tapped it along with several other keys. To accomplish this, and to keep players from sitting still too much, we went for a movement style similar to air hockey, where players keep some of their momentum and drift around the board, bouncing off of walls and each other. For added feedback, when a movement key is hit, we display an arrow on the screen informing that player which direction key or combination of keys is being pressed.


We wanted combat to be simple enough, but still fun and strategic. We made the decision early on to keep the fire button constant, so that two players holding a keyboard between them can easily reach the fire key and fire at each other at every opportunity. To cut down on unnecessary and complicated aiming, players are always facing each other, and will always fire in the direction of the other player. To prevent matches ending too quickly, players have a hit cooldown that prevents them from taking too much damage at once.


We wanted to reward players for figuring out their movement, or cleverly utilizing a partially discovered movement set. Naturally, as a player gains more control, it becomes easier to defeat his or her opponent, but we also added in some power-ups that can help players or mix up the flow of a match in other ways. There’s a shotgun style upgrade which turns each shot fired into three, making it easier for a player to hit his or her opponent, a quad shot upgrade, which shoots four shots, in a rotating spiral around a player, which can rapidly damage the nearby environment and may trigger explosive spaces, and finally, there is a health replenishment pickup, which can quickly turn the tide of a match.


The buttons for fire are constant, and are positioned on opposite ends of the keyboard so that players can fire with their thumbs while holding the keyboard.

To keep firing simple and fun, players always fire in the direction of the other player. Once a player has discovered his or her controls, collecting power-ups and taking cover behind scenery become the keys to winning a match. There are explosives that can appear around the stage too. Hitting one of these with a stray shot will damage and knock nearby players around the stage. This can set off chain reactions that can send players bouncing around the stage. One of the more nuanced design mechanics is that explosions only do modest damage to players, but they ignore damage cooldown, meaning that a chain reaction can devastate a player’s health.

Ctrl-Seek is a simple game, but I’m proud of the polish and design decisions that my team and I put into it. You can download it and play it for yourself through the link below.

Download Game

Level Design Mod – Vylkinmar




In an effort to continue to refine my level design skills, I started work on a level mod for The Elder Scrolls 5: Skyrim.  I was looking for a project to work on that would allow me to build a polished level in a reasonable amount of time without having to build core mechanics and create assets.  This project allowed be to work with mechanics and player agency already built into the game, and utilize a library of modular assets.  The ability to purely focus on encounters and level flow, as well as the fact that really enjoy Skyrim, made this project very enjoyable to work on, and I was able to take the level from concept to completion in just a few short weeks.

I kept a detailed document describing all the encounters and puzzles, as well as my process and challenging parts of development.  If you’re interested in a more detailed breakdown than what I’ve provided below, take a look at the linked document below, otherwise stay on this page if you just want the short version.

Level Design Doc

Brief Description

Vylkinmar is a level mod that takes the player through a Nordic styled dungeon that features several unique elements not found in other dungeons in Skyrimk, including an inventory based puzzle to gain entry, an vertical dungeon entrance, and a boat ride with enemies firing arrows and spells at the player.

Gaining Entrance to the Tomb

To enter the tomb, the player must complete a ritual involving placing the correct 3 items in a basin and using a spell or staff to light the basin on fire.  The player is clued in on how to complete this ritual by a journal he or she picks up after defeating a pair of necromancers.  Completing the ritual successfully opens the sarcophagus that serves as the entrance to Vylkinmar’s Tomb.

Boat Ride

After reaching the second part of the tomb, players embark on subterranean boat ride inside of a massive cavern beneath the ocean.  While on the boat, players are fired upon by ranged draugr using spells and arrows.  Players can fight back with their own spells, arrows or shouts, or can do their best to avoid the incoming attacks.

Frozen Ship and Vylkinmar

After reaching the boat’s destination, a door leads the player to an area buried deep withing a glacier.  Here the player learns the fate of Vylkinmar and his ship, and must defeat Vylkinmar to complete the quest and the dungeon.

Development Challenges

Sarcophagus Entrance

The sarcophagus asset isn’t meant to be used as a means to enter a dungeon in Skyrim.  This caused a few complications that I had to account for.  The basin puzzle that the player must complete in order to open the sarcophagus required a bit of scripting, but nothing I couldn’t handle. To make the sarcophagus a working entrance however, required some thought.  I used a dark plane to make the sarcophagus look like it led into a dark chamber far below.  Some invisible trigger volumes allow the player to enter the tomb by activating the space inside the sarcophagus or by jumping in.  I needed to give the player a way out in case he or she decided to exit the dungeon partway through, so I set up a rope that the player can use as a door.

Moving Boat

Skyrim doesn’t really use moving platforms, at least not ones that the player can base on.  I scripted a fairly simple waypoint system to move the boat, but accounting for any companions the player might have had in tow made things a bit complicated.  I created an AI package to tell followers to boatd the boat at a certain time, and navmeshed both where the boat started out and where it came to rest so that followers could find their way on and off the boat.  While the boat was in motion, companions didn’t really have to move, and even managed to engage enemies in ranged combat despite the lack of proper navmeshing.. I also had to consider what would happen if players or companions jumped or fell off the boat.  I created a series of trigger volumes to keep players on the boat while it was in motion, and used another trigger to detect if a player or companion did somehow managed to fall off and place them back on.  Also, Skyim’s standard enemy behavior allows enemies to attack players, but only within a certain distance.  I had to create custom packages that told the enemies to fire at players on the boat even though they might be far away.

Non Modular Glacier

The third section of dungeon I constructed featured a fairly small, but very tall area.  It needed to be able to fit the crashed ship, and I wanted players to be able to look up and see the sky far above them.  Because of the height and demensions of the room, I had to use non modular glacier pieces instead of the standard tillable ice cave set.  Constructing a fully enclosed area that allowed for easy player navigation without using a tileset was a bit of a challenge, but I think I managed it pretty well.


This project gave me a chance to work purely on level flow and planning and implementing encounters.  It gave me an opportunity to learn a new toolset as well as see how Skyrim handled things like scripting and quest implementation.  At first glance, it’s easy to view the creation kit as a bit clunky and lacking in a few modern features like support for multiple viewports, but once you dive deep into it, you start to notice all of the nuanced features it offers that help speed up content creation.  Things like quest aliases and leveled items can be really powerful tools.  There were a few elements of my level that I wanted to incorporate but had to cut because the toolset wouldn’t support them, but it still proved a very capable tool for level creation.

 Download Link

Download Mod

NCARB Grant Project – Studio DAG

I had the opportunity to work on a joint project between the SCAD architecture department and games department. Our friends in the architecture department applied for and received a grant with the NCARB to develop an interactive game that teaches architectural students the professional skills and practices they will need to succeed in the real world.

The project lasted for two terms, around 6 months.  For the first term, we had a large development team of around 20 or so, and for the second, our team shrank to about 6 or so.  We collaborated with architectural students, who were able to give us very valuable information and an informed viewpoint that helped us tailor the project to the field of architecture.

–Systems Design Breakdown —

The core system went through two iterations.  The first incarnation of the system had largely been worked out by my professor and project lead when I joined the project, but I was involved in further developing and building out that system.  Later down the road, we decided that we needed to change the way our progression system worked in order to make scenario creation easier and faster.

The basic structure of the game involves players working their way through a number of different scenarios, talking with clients and responding to different situations that arise during a contract.  Each decision players make affects their scores in seven different categories, Finance, Ethics, Environment, Communication, Public Relations, Time Management, and Office Relations.  As players make decisions, they are constantly being evaluated based on these categories, while also trying to keep the client happy. This creates an interesting dynamic where these different factors are in opposition to the wishes of the client.  Players must balance keeping the client happy, while considering the brander impact of their decisions.

Scene Progression

The way our system originally worked, a scenario consisted of three possible ‘tracks,’ or sets of scenes that players could follow as they went along.  These tracks weren’t necessarily linear however because it was possible for a player to jump from one track to another after any given scene.

scenario flowchart

It broke down like this:

– The player would select his or her chosen response to the given scene

select choice

– That player would be awarded positive or negative points in seven categories based on his or her choice

value points

– Those points were then compared to another set of values for those seven categories which represent the client’s desired outcome.  This determines an umbrella “Client Satisfaction” value.


– This value then determined which of the three possible scenes the player was given next.

cs values

We tested this system pretty thoroughly and found it worked well to move the player through the scenario.  The issue came about not as a result of the system not working, but our three path structure and evaluation after each scene meant that the premise of a particular scene could not be a continuation of a previous scene because the player could conceivably arrive at that scene from anywhere.  This became a problem for our architecture friends as well as our chief writer because each scene had to be pretty much agnostic of anything that came before it.

In the end we decided it was best for the project to switch to a more open ended branching structure for our scenarios.  This was not an easy decision to make, as it meant throwing out the system we had developed, and reworking a lot of the coding I had done.

So we went back and came up with a system that allowed our writers to create scenarios as with as many branching paths a they wanted.  Now, any choice can lead players to any in the scenario.  We did however restrict them to the three choices per scene format.  This was done for a number of reasons, a consistent markup format and interface being among them.

Office Relations

Working in an office isn’t just about finishing your work.  interacting with your co-workers is a necessary part of working anywhere.  To simulate this, we implemented a minigame in which players must interact, or choose to ignore, their co-workers.

There are four different NPCs that approach the player’s desk.  depending on which pose they appear in, they could offer the player advice, ask for help, or they could want to share the latest gossip. Players can then choose to ignore them or talk with them, but doing so will have an effect on the player’s time management and office politics.  The player has to balance being a good coworker without wasting too much time on idle gossip.

Scenario Creation

For our second term of development, we had a student from screenwriting bought on to assist us with writing scenarios, but during the early days, the other grad student, David and I were very involved with the scenario creation process.  The architecture students provided us with situations they came up with that would provide interesting, challenging dilemmas that an architect might face.  It was then our job to take these concepts and make them workable in the game.  We had to go through and assign point values for the categories that each choice effected, as well as write dialogue that would make each choice sound viable to players.  One big takeaway I found was that it can be pretty challenging to create choices that you know are wrong, without making them sound wrong to players.

— Development —

In addition to acting as a systems designer, I was also the head of Unity development for the project.  It was my job to ensure that assets and code all made their way into the engine, and ultimately my responsibility to get all the pieces working together.  I did a lot of coding for the project, and was able to learn a few techniques that I had never used before.  I decided that our scenarios should be saved and read in as xml files, which made then easily editable.  I hadn’t worked with reading and writing xml files in the past, so it was a great opportunity to learn.

Taking code that had been written by several other people and getting it all to function together proved time consuming, and if I could do the project over, I would have handled some elements differently, but I think it was a success overall.


Aeroblazer was the visual component to my MFA thesis. A thesis at SCAD has two components, A written thesis paper, and a visual component that demonstrates the concept or argument of the thesis. My thesis was titled Gameplay Driven Content Generation, and it can be read in its entirety here.

Aeroblazer Alpha Footage

My goal with Aeroblazer was to create a system in which levels are created dynamically while the game is being played. These levels are created in response to player actions, so that the created level becomes the result of how the the user plays the game.

Mechanics Overview:

Aeroblazer is a turn based game involving a vehicle that can both fly like a plane, and hover along the ground like a hovercraft.  In it, two players compete by alternatively flying and driving, creating a track while they do so.  Each turn consists of two phases: the driving phase, where the active player must drive the length of the track and make it to the end, and the flying phase, where the player adds to the track by flying a plane around, avoiding obstacles, collecting powerups, and trying to create a tricky section of track for the other player.

Each turn lasts for a limited amount of time as indicated by a meter in the center of the screen.  Within this time limit, the active player must make it to the end of the track in order to add onto it.  If the player fails to reach the track’s end before the meter runs out, he or she will not be able to add onto the track, and it becomes the next player’s turn.

Since there is no track when the match begins, the driving phase is skipped on the first turn, meaning the first player starts off by flying around the environment.

Aeroblazer Turn 1

Once the first player’s turn has ended, the second player takes his or her turn, starting in the driving phase.  He or she must navigate to the end of the track before time runs out, then continue building onto the end of the track.

Aeroblazer Turn 2

The match continues on in this manor until one of the two winning conditions is met.

Time equation

Timer(in seconds) = 10.0 + v*0.08

Where v is equal to the total number of verticies in the track.

This equation ensures that as the track gets longer, the player is given more time to both navigate the track and to add onto it.

Winning conditions

There are two ways a match can end.  The first way is if one of the players’ health meters is reduced to zero.  Players can lose health in a few different ways.  During the driving phase, players can lose health by hitting the bumpers on the sides of the track, falling off of the track, or failing to reach the end of the track before time runs out.  During the plane phase, players can lose health by colliding with obstacles.   This will cause the player’s turn to end, and discard the section of track he or she was creating.

Aeroblazer Taking Damage

The other way for a match to end is by collecting all five checkpoints.  These checkpoints appear one at a time, and are randomly placed throughout the creation space.  Once a player passes through a checkpoint, he is given a point and the next checkpoint appears.  Aeroblazer CheckpointOnce all five checkpoints are collected, the match ends, and whoever has more points wins.  Three points are needed to win, but the match doesn’t end once one player has three points, meaning the other player can still win if he or she can reduce the winning player’s health to zero before all five checkpoints are collected.


There are powerups scattered throughout the environment that can help players in various capacities as well as alter the track that is being created.  These powerups can be collected in two ways.  First, players can collect a powerup by touching it with their vehicle, either in the driving or flying phase.  Second,  while the active player is taking his or her turn, the inactive player can control a cannon mounted on top of the active player’s vehicle.  With this cannon, the inactive player can shoot lasers that collect any powerups they hit.  This not only gives the inactive player something to do during the other player’s turn, but also allows both players to compete over powerups and influence each other.

There are three powerups, and each one has two different effects.  These effects depend on if the powerups are used during the driving or flying phase of a player’s turn.

YellowAeroblazer Yellow Powerup

Yellow powerups give the user a speed boost if used during the driving phase, or create a gap in the track and a ramp with which to jump over it if used during the flying phase.

Purple Aeroblazer Purple Powerup

Purple powerups give the user a shield that protects him or her from losing health from hitting the side bumpers if used during the driving phase, or creates a section of track where the bumpers take away more health if used during the flying phase.

RedAeroblazer Red Powerup

Red powerups give the user back some of his or her health if used during the driving phase, or create a narrow section of track if used during the flying phase.


Aeroblazer is currently in an alpha state.  It is playable and the core experience has been refined and balanced to an extent, though I am still developing the game, and there are a lot of features I am still implementing or improving.  Some of these are described in my thesis paper.

Ruins of Mono’Zhe

Playthrough Video

I designed and implemented a level called Ruins of Mono’Zhe in UDK.  I designed the level’s three event systems and implemented them using Kismet.  I first blocked out the level, then set-dressed it using built in UDK assets.

Level Design Doc


Narrative Overview

Mono‘Zhe is an ancient subterranean ruin located within a vast cave chamber. A local myth tells of a mythical weapon of great power locked away within the forgotten ruins, garnering the attention of international arms research firm Anepco who have started excavating the ruins. Poor working conditions and economic instability have caused the workers to strike, leaving the dig half finished, and the dig site deserted save for the company’s automated defenses. The player has discovered a secret way into the ruins, and decides to venture into the ruins and claim the sword before Anepco can send replacement workers.

Event Breakdown

Event 1: Cave Entrance: Improvising a Torch

After a dramatic vehicle accident, the player finds himself in a small wooded enclosure near the mouth of a foreboding cave. The player can attempt to explore the cave, and may even make his way through it, though the path is treacherous and a miscalculated jump could result in a fatal fall into shadowy depths. The way through can be made much easier with the help of an improvised torch created from one of several dried sticks scattered about. To make the torch, the player must find one of the sticks and light it in the flames spewing out from his overturned vehicle. The torch allows for safer passage through the cave, but the player must hurry as the torch will eventually burn out and must be re-lit.

Event 2: Inner Ruins: Block Placement Puzzle

Once inside the ruins proper, the player is confronted with a closed stone door. In the same room is a plinth with a large square recess. The player can find an assortment of stone block pieces in different shapes scattered around the room. She can pick these pieces up and bring them to the plinth to place them. They can be moved and rotated over the plinth and placed anywhere they can fit. The player’s job is to place all five block pieces inside the plinth in order to open the door and progress.

Event 3: Excavation Lift: Repair the Generator

The final task for the player is to make his way out of the ruins via an elevator that has been built to accommodate an ongoing excavation of the ruins. Upon reaching the lift, the player notices that the lift gate will not open due to a lack of power. The player must then deploy a remote controlled drone to repair the lift generator. Things get complicated when the deployment of the drone alerts the dig site’s security robots. The player must control the drone and fight off the robots while staying close to the generator to repair it power the lift.

Mechanics Study – Barrel Blitz

A while back I did a mechanics study to try to recreate the barrel cannon mechanic from Donkey Kong Country.  I recreated the mechanic  from the mechanics in UDK using a whole mess of Kismet.

The barrel cannons operate pretty much exactly as they did in Donkey Kong Country.  Red Barrels shoot you automatically, while the blue ones fire when you press the ‘f’ key.  There are moving barrels, collectable goodies throughout the level, and eventually obstacles that you have to avoid using precise timing.

While doing this study I learned a lot about how Unreal works, and how to really dig deep with Kismet.  I also learned that most of the things I had to implement with complex Kismet sequences I could have accomplished much easier by modifying the player package.

In doing this project I also learned a ton about the design language of the DKC games.  There are a number of elements that I noticed in the original levels that I was able to implement in my own example.

Take The Plunge

Barrel Blast

Barrel Blast



Placing items right at the edge of players’ vision is an effective way of luring them to areas they might otherwise perceive as dangerous.  As long as you provide a hidden means of safety, this is definitely a fun way of hiding secrets.  This is used all the time in DKC.


Give Them What They Expect

Barrel Blitz

Barrel Blitz






This is something I didn’t foresee.  I placed a hidden item to the left of this cannon at the top of a vertical crevasse.  The cannon shoots the player right, but if you jump over the barrel to the left, you can find a secret.  The interesting part is that everyone that found the secret stopped searching to the left immediately after finding it.  The arbitrary pickup was enough to satisfy players’ curiosity.  Up until this point in the level I had been training players to look for these hidden spiky things, so once they found this one they were satisfied and moved on.  Smaller secrets can be effective means of concealing larger ones.

Follow the Glowy Things

Barrel Blitz

DKC does this all the time.  Notice how the next barrel the player should fire themselves towards is nowhere to be seen.  The only indication of direction is the trail of glowing things.  By this point the player knows these things are good, so sometimes that is enough to lead him or her.

Accidents Will Happen

Barrel BlitzBarrel Blitz






Surprising the player with a secret when he or she expects to fail can be really fun.  Here the player has to fire the rotating cannon to reach the next barrel.  If the player fires straight up instead of to the right, either by accident or by intention, he is rewarded with a secret path and a huge haul of goodies.


Non-Digital Zelda

Non Digital Zelda

I did a bit of non-digital game design.  I was given an assignment to convert an existing digital game to a non-digital analogue while still keeping the spirit of the original title.  I chose to convert The Legend of Zelda: The Four Swords to a four player board game.  I really like the cooperative/competitive dynamic of the game in its digital form, and wanted to touch on that with my non-digital counterpart.  Players work their way through various dungeon tiles while competing ot collect the most rupees.

Looking at the final product, I think it needs some revision.  It plays a bit too slow and combat feels a bit tedious for my liking.  It was a great project to work on though, and I’m still working to improve it.  Zelda is a series I have a lot of passion for, which really motivates me to make this adaptation do the series justice.

Take a look through the design document for a full breakdown of the rules.

Game Design Doc

Wave Trekker

Wave Trekker


Wave Trekker GDD

I created a complete design document for a theoretical game called Wave Trekker. The document covers pretty much everything short of actually making the game. It’s a 3D open world style boating adventure in which the player travels around an open ocean in search of massive sea monsters to defeat. It was really liberating being able to design a game without having to actually make it at the same time. I really had fun working out the systems, writing out dialogue, and mapping out the areas.

Take a look at the design document to view the details of the game.

Selected Systems Breakdown

To demonstrate some of the finer aspects of the game, I’ve selected a few of the game’s major systems and broken them down below. For a much more complete explanation, take a look at the design doc linked above.


There are a number of items in the game that the player can collect. These items do various things, from loot that the player can sell to upgrades for the player’s boat. Below is table of all the items in the game. I also made a Google docs version which can be found here

ITEM Usage Location Buy Value (in scales) Sell Value (in scales) Purchasable from Dropped By Drop Percentage (%)
Repair Kit Restores 75 health points purchased, found, pirate common drop 100 60 Tidewind, Ebshore, Antra, Pluthe Pirate 60
Fuel Reserve Tank Restores 75 fuel purchased, found, pirate rare drop 120 75 Tidewind, Ebshore, Antra, Pluthe Pirate 20
Sailfish loot Sailfish drop – – – 10 – – – Sailfish 100
Chomper Scales loot Chomper common drop – – – 20 – – – Chomper 60
Chomper Fin loot Chomper rare drop – – – 40 – – – Chomper 20
Sawray Teeth loot Sawfish common drop – – – 30 – – – Sawray 60
Sawray Gel loot Sawfish rare drop – – – 50 – – – Sawray 20
Salt loot Brine common drop – – – 20 – – – Brine 60
Nautilus Shell loot Brine rare drop – – – 70 – – – Brine 20
Engine Parts Allow player to access rougher areas, allow player to boost Galmalok drop – – – – – – – – – Galmalok 100
Advanced Hull Armor Increase player health to 150 Manja drop – – – – – – – – – Manja 100
Advanced Ammo Loader Decrease all reload/cooldown times by 20% Hispaniola drop – – – – – – – – – Hispaniola 100
Fuel Tank Expansion Increases fuel to 150 Purchased at Ebshore trader 400 – – – Ebshore – – – – – –
Advanced Torpedo Launcher Increases torpedo capacity by 4 Recieved from Oflora High Council OR purchased from Antra Trader 700 – – – Antra – – – – – –
Advanced Booster Module Increases boost speed to 3.0, increases boost damege to 15 Purchased from Pluthe thrader 800 – – – Pluthe – – – – – –

Fuel and Boosting

The primary way the player moves around the game world in Wave Trekker is by boat. One of the key decisions I had to make was whether or not the boat’s engine would consume fuel. The most obvious concern I had was what would happen if the player ran out of fuel in the middle of the ocean? Additionally, I didn’t want players to have to keep track of a constantly depreciating resource that would ultimately bog down the experience and draw focus away from the more important elements of the game such as exploration and combat. I did end up incorporating a fuel resource, but it is only consumed when the player uses the boost ability.

Part way through the game, the player’s boat gains the ability to boost. This can be useful as a means to travel across the world more quickly, evade enemy attacks, or ram certain enemies. This boosting ability consumes fuel, limiting how often the player can use it.

Fuel Consumption Equation:

Fuel Consumed = 5+(10*t)

where ‘t’ is the time in seconds that the boost button is held down

The initial cost of 5 units of fuel as soon as the button is pressed ensures that boosting has an up front cost followed by a slower burn. This makes it more cost effective for players to utilize longer, more carefullly thought out boosts rather than quickly tapping the button. Initially, the player can hold a maximum of 100 units of fuel, meaning that a single boost held down for 9.5 seconds would completely drain a full fuel tank.

A normal boost doubles the boat’s speed. However, the player can collect an upgrade that will increase the boost speed to 3 times the normal boat speed.

Damage output equation:

Boost Damage Output = 100*(Boost Speed)

This means that boost damage is increased along with speed once the player collects the advanced boost module.

Bombs Away

Bombs Away

Software Used: Maya, Photoshop, Unity

Role: Lead Programmer, Designer

Bombs Away is a competitive action game for up to five players. The project was planned as a game played on both iPad and PC together, but we ended up finishing the standalone PC version and a separate version for iPad. There are four bots all competing to be the last bot standing. They do this by picking up bombs and throwing them at other robots, or picking up other bots and throwing them into bombs or spikes. There is also a player called the overseer. He controls the environment by moving spikes around, rotating the environment, or placing additional bombs in the arena.

Bombs Away Gameplay

This was the project I worked on for my senior project at Drexel. I served as lead programmer on a five person team.  Due to the size of the team, we all had to contribute to pretty much every aspect.  In addition to programming I had a strong influence on the design of the game.  Though it was tough working with this team at times, and the way our senior project is structured was frustrating, I still enjoyed working on this project. It was nice to get pretty much all the functionality we wanted working in the game. I learned a ton about Unity through this project.  Most of my scripting skills come from working through this project for six months

Here’s a video explanation