Split Mateys

Project Summary
This game was created in my program's 4-day long game jam known as Design Week. As a second year at the time, I worked along side students in the program and took on the role as lead programmer and game designer. This jam's challenge was to create a game inspired by escape rooms, and our team choose to make a co-op pirate puzzle game. Our game requires 2 players, one controlling the ship and then other solving puzzles. The twist is that both players are split and cannot see each others tasks, making communication key if they want to complete the challenges ahead of them. 

Gameplay Demonstration
Process
With only 4 days to come up with an idea and execute it, our team quickly decided what we wanted the core focus of the game to be: communication. Taking inspiration from puzzle games such as Keep Talking and Nobody Explodes, we wanted both players to feel agency in the game and be able to give and receive feedback. I first began developing simple boat controls that would be easy to learn as players would likely only be spending several minutes playing the game. 
While I wanted to keep the controls simple, I still wanted to add in visual queues that would give the feeling of sailing a boat. These included the boat's wobble when steering and when still, and drawing/raising the sails to increase speed. I was able to utilize the scroll wheel inputs on a mouse, giving players the physical feeling of drawing/raising a sail as they need to constantly scroll.
After implementing the boat movement, I began designing the escape room like puzzles that the players would interact with. My aim was to make puzzles that provided partial hints, requiring players to make connections to what they're experiencing in the game. With the level being entirely static apart from the player, I needed to design unique puzzles that only involved the players navigating the boat around the environment. 
I ended up design 4 unique puzzles, all that could be solved in any order and are required to complete the game. With communication being our core focus, these puzzles involve the player with the puzzle sheet asking for visual hints, providing instructions based off the response, and listening to the outcome. In the examples shown above, one puzzle involves finding a code through the rock formations in the game, while the other involves navigating through a maze using a given set of directions. 
After testing among our team, we realized that the downbeats between puzzles lacked engagement for the player with the puzzle sheet. While they did have a map to guide the player to the next puzzle, they we not involved in any of the obstacle avoidance or steering. To solve this, I came up with the idea that the puzzle player would also be in control of the speed of the boat. As shown above, the puzzle player now needed to listen to what speed the boat player needed to go. This reinforced our core focus of communication and made downbeats much more engaging for both players. 
We received great feedback from testers, who enjoyed the experience and found the communication aspect very engaging. The nature of the game led to many laughs and lots of shouts between players as they stumbled or aced their way through the puzzles. My biggest takeaway from this game jam was that sometimes removing features that are expected can be just as compelling as adding extra features. 

Other Projects

Back to Top