Unity, Qualisys, Motion Tracking
Hands on Deck
Scroll ↓
Hands On Deck is a unique game experience where the player IS the controller. The game was made with motion capture in mind, and players must physically move around a room to play.
You and a friend play as two jellyfish pirates aboard a pirate ship. Players must aim a real life cannon to fire cannonballs to destroy enemy ships, while making sure to dodge enemy fire and collect ammo. If a player is hit by enemy fire, they 'die' and must stand over one of two grates to respawn after a short time. Players collect bonus points according to how fast enemy ships are destroyed, and if any enemy ship reaches the player's ship, the players take one hit-point of damage. After ten hit-points, you lose!
We shifted to a three-porthole system, where one player would move a single cannon, and the other player would fire by pressing a button at the back of the play area. My contributions were as follows: This cannonball would automatically calculate the angle and speed it needed to travel to hit the first enemy in whichever lane the cannon was in, essentially homing in on the enemyship. Enemy cannonballs would fire at a random location on the deck every 5 seconds, providing a reason for players to move. The cannonball would leave a hole in the deck where, if any player stepped over it, they would 'fall through' and die. If any player was dead, the cannon would not fire.
Julie was responsible for most of the motion tracking, set design, and real-world input.
I completely revamped the enemy cannonfire, changing it from total randomness to picking one of several patterns to follow. I also made it so that the cannonballs had a visible shadow on the deck that grew larger and darker as it fell, so players could see where they were going to fall and avoid those spaces. I changed from the three-porthole system to one large porthole so players could fire the cannon from anywhere horizontally, and removed the 'homing' functionality. I made adjustments to the motion tracking code and added a shadow beneath the players for better visual clarity. I added functionality for points based on how fast an enemy ship was destroyed. I made various particle effects for different things: cannonballs hitting the deck, players firing the cannon, enemy ships being destroyed, enemy ships blinking red as they get closer to player ship, and enemy ships hitting the player ship. This increased the visual feedback that players got, and made the game feel much more responsive.
Gameplay footage showing the Kraken Boss Fight
I was responsible for coding, alongside my teammate Julie.
As we developed this idea, we honed in on one idea for a minigame we had, and decided to make it into a full game: Pirate battles. The goal was to create two cannons on horizontal rails. Players would move side to side to avoid getting hit, and have mechanisms for shooting their own cannons. Ships would spawn in one of three lanes, and slowly move towards the players. We quickly realized that this would be both impractical to implement (the rail would need to be several feet long and sturdy), and plain unfun. We wanted to get players moving all around the room, not just side to side.
Our first playtest gave us a LOT of insight. Due to a bug in our code (the calculation happened before the motion tracking data came through), the players were able to aim the cannonballs wherever they wanted, meaning the player with the cannon just stood in one spot while the button-pusher spammed the button. The random enemy cannonfire felt too unfair, and players had trouble distinguishing where they were in the playfield.
We noticed that players actually enjoyed the manual aiming, and the issues with the game lied elsewhere. Thus began the great overhaul.
Gameplay footage showing various reworked functionalities
We began production on a kraken final boss, but realized it was too much work with what little time we had left. With more time, I would have loved to complete that Kraken boss fight, but it was simply unfeasible. I am most proud of my patterned cannonfire mechanics, which is itself a very complex system. It is a list of patterns that contain a list of transforms and delays from the previous cannonball. The game manager chooses one of these patterns from a pool at random, and excludes it from the pool until every pattern has been used.
Overall, I am extremely proud of how this project turned out. Even though design choices shifted frequently, we created a clean, fun final product for enjoyment of players.
Check out the itch page here to see the more details, including gameplay and trailers!