Shipwreck Showdown is a networked multiplayer game where a small crew of pirates operate a ship to take down a legendary kraken. Each player takes on a different role to accomplish this. One player operates the captain's wheel to steer the ship to dodge attacks from the kraken and align the cannons. There are two cannons on each side of the ship that players can use to aim and fire at the kraken, after being loaded with a cannonball. The kraken's minions will board the ship and attempt to take out the captain, requiring other players to remain alert to defend the ship.
The kraken has several different attack patterns with several more being unlocked once the kraken falls below 50% health. The kraken will move to either the front or the back of the ship in an attempt to avoid being in line-of-sight with the ship's deadly cannons. The minions that board the ship will initially target the captain, but will prioritize players that attack it or those aiming a cannon in some circumstances.
This game was made for KnightHacks VII, a 36-hour hackathon hosted at the University of Central Florida. This project won the "Best Game" category.
For this project, I did most of the gameplay and network programming. This includes ship, player, and cannon movement, cannon shooting/loading, and the health of all the units in the game. I also integrated my other team members' work into existing systems and made sure everything was properly replicated over the network.
The most complicated system that Shipwreck has is the possession system. Players are able to take control of parts of the ship, such as the captain's wheel or the cannon, to perform certain tasks necessary to beat the game. Each "possessable" unit would come with different abilities and completely different modes of movement. On top of that, the entire system will have to be replicated and server-authoritative, since multiple players should not be able to possess the same unit.
To break down this problem and start thinking about a system to model this behavior, I first made a UML diagram. UML diagrams are an important part of my technical design process since they are excellent tools to visualize systems and carefully consider the flow of data. It is also much easier to identify issues and improve the system on this high abstract level than it is after you spent time writing it in code.
Once I had a good idea of the system's architecture - thanks to the UML diagram - the rest fell into place relatively smoothly. There were plenty of roadblocks along the way, but with some debugging and a couple energy drinks, the end result was a robust and seamless transition of control between players, the ship, and cannons.
This game is mostly made with strong server-authoritative design. For example, firing a cannon from the client involves sending a request to the server, which then decides if the cannon should fire or not. If so, it then sends a callback to the client to do any clientside things like sound effects and UI updates. The health system is also entirely server-authoritative, meaning a malicious or rogue client can't severely alter the game state, such as by ignoring damage from enemies.
Some parts of the game, like player movement, are client-authoritative to ensure player movements felt responsive and smooth. In the future, I would like to work with a networked movement system that uses prediction and reconciliation to allow for server authority while also preserving clientside responsiveness.