Ahoy, Me Hearties! Blog

Ahoy, Me Hearties! will soon be available for download on my itch.io page.

Idea Generation

My main project’s aim for the postgraduate Media Specialist Practice module at Kingston University was to make a multiplayer game. I was put in a team (as a game designer) with two very talented game programmers, Michael Dorrington Ward and Joshua Lyons.

Like every other great idea, it all started with a sticky note.

Figure 1: An original sticky note which briefly elaborates our chosen game idea

Our initial idea was a multiplayer game in which four players would have to work together in order to survive. If we were to have an X statement, it would probably go something like, “Sea of Thieves meets Among Us”.

Sea of Thieves (Rare Ltd, 2018) was the closest example of an already-made game which would describe our desired game setting, movement and interaction mechanics, player perspective (1st person camera), and general atmosphere. Among Us (Innersloth, 2018) represented our targeted objectives system and the teamwork we would require from our players. The final touch of slight chaos revolving level and obstacle design was definitely inspired by Fall Guys (Mediatonic, 2020).

Game Setting

To be able to recreate the setting, we decided to do a bit of research on the Golden Age of Piracy and types of ships (and crews) which sailed across the Atlantic Ocean in the 18th century. We looked at everything from what kind of roles the crew had on their long journeys to what kinds of items they were transporting and how they managed to control such large ships. Then we stumbled upon this next image, which inspired us to create our level. We wanted our ship to be more trade-oriented, so we made it to be more of a galleon than man-of-war.

Figure 2: An image of a man-of-war (click on the image to follow the source page)

To replicate the ship, we first started making a top-down map. Our initial idea was to have two gameplay areas, the ship’s deck and bilge which is the lowest part inside the ship, where the first signs of leakage would show if the ship was damaged. Below, you can see our first top-down level layout and the prototype made in Unity using ProBuilder.

Figure 3: A top-down layout of the deck, one out of two main gameplay areas, and the matching 3D model made by using simple geometry

Game Narrative

Afterwards, we came up with the game story which followed the British crew that consisted of four sailors on the galleon called HMS Observance in mid-18^th century. They were sailing across the Atlantic Ocean, trying to return to Britain with precious cargo. During their journey, their ship has been significantly damaged. As they were already half-way and could not turn back, they needed to keep their ship afloat until they reached their final destination.

Our goal was to incorporate the gameplay and setting into narrative, so players understand what is happening in the game without really telling the story through common narrative elements we usually see in single-player games.

We have also carefully chosen specific roles (based on our research) each player would have to create the right atmosphere and environment where players can identify with their playable characters.

Figure 4: Individual player roles (from left to right): Captain, Shipwright’s Mate, Pilot Quartermaster, and Shipwright – keep in mind these images are here to just help visualise what each player’s role would be, they do not represent the aesthetics nor the timeline of our characters (click on the image to follow the source page)

Gameplay Loop

According to our initial idea, each player’s role would be different from the other and require different tasks to be fulfilled in order to succeed. Their individual efforts would then be combined and measured through one value – ship’s condition. The end depended on whether players have managed to stay afloat by continuously completing their tasks during their play session or failed and sank with their ship.

During the first week of production, we decided to use Arcweave, an online data base which allowed us to easily create, collaborate and share our design documents. Below you can see how we designed our main gameplay loop.

Figure 5: An original main gameplay loop (planning stage version)

To further elaborate, we can take Player 1 who would play as a captain and Player 2 who would play as a pilot quartermaster. The captain was responsible for steering the ship and regulating its balance, while the pilot quartermaster was responsible for maintaining the sails and removing all unwanted objects from the ship. They were both placed on the ship’s deck and had specific items in their inventory – a spyglass and a bucket, which would help them with their individual tasks. These tasks and items were naturally subject to change. Additionally, we also designed individual player gameplay loops which you can see below.

Art Style

At early stages, we also decided upon having stylized, colourful and cartoon-like graphical style filled with low poly assets because we would improve game’s performance with low-complexed model, and would have an easier time to find desired assets. Additionally, this art style helped us achieve our targeted atmosphere and humorous narrative.

Level Design Goals

In our lectures, we discussed the importance of having level design and counter play goals to allow players test theirs skills in multiplayer environment without getting frustrated or completely limited by the rules of our game. To respond to that, we set a couple of our level design goals:

keep the main and connecting paths well planned to give the players space for making strategies
carefully place objectives and spawn points in the appropriate locations to make gameplay interesting and fun to play even after the players have played the game multiple times
create challenges and obstacles for the player movement, but in a way they are balanced with their tasks at hand

The overall design of our ship made the main and connecting paths easily approachable and accessible. The only thing we were missing were obstacles which would make the level challenging, so we started sketching a couple of types of obstacles we could have in our level. You can see below how we completed the process of implementing obstacles into our top-down level sketch and into our 3D prototype later on.

Figure 7: Step 1 – Adding obstacles to our top-down sketch of the deck; Step 2 – Creating simple prototypes of the sketched obstacles and placing them on the 3D model of our ship in Unity

Level Design: The Final Look

Once we completed our level prototype and used a first-person controller to test the scale of the environment and adjusted the size of our ship, we searched for royalty-free assets on websites like Itch.io, Unity Asset Store, and Sketchfab. Once we found what we looked for, we were ready to use our world building skills to create our desired atmosphere and gameplay areas. Below, you can see a set of screenshots which showcase the final look of our ship (the deck as our primary, and the bilge as our secondary gameplay area).

To translate our humorous narrative, we implemented a couple of “jokes” into our level design. As a result, if you play our game, you may or may not stumble upon an American bison eating a slice of pizza, or find a baby T-Rex in a modern terrarium. You know, because those things existed in 18th century. I’m not even going to mention how “dreadful” the prisoner on board is. High caution is advised when visiting him! (Hint: you can actually see him in one of the screenshots above).

Counter Play Goals

Since our game idea did not involve players playing against players, but against the challenges each game session created, our counter play needed to be achieved through objective’s difficulty. Therefore, we set the following counter play goals:

design and implement appropriate game mechanics which allow players to complete their tasks and respond to their circumstances in multiple ways
game’s feedback must be highly responsive as well – players’ actions must be met with clear and highlighted visual or audio effects
both level design and objective’s difficulty must align together to create interesting ways players can play the game

As our main tasks revolve around picking up and dropping objects, we carefully tested the proper field of view of the camera to enable a clear and wide perspective of everything that is happening on the ship, which allowed players to have a great vision over the entire level.

Also, we balanced the proximity of the objects needed to enable pick-up function, and chose a very distinctive location for players to see what they are carrying. Lastly, we worked on having visual effects as feedback for all players’ actions, so they could understand their circumstances and react as fast as possible. You can see a few images of said examples below.

Figure 8: An in-game screenshot of a clear inventory object placement and a visual feedback in the form of small hermit crabs after the water leaks in the background have been fixed by using the carried ice-cream

Figure 9: An in-game screenshot of falling objects, which indicates how we used gameplay areas (the deck and bilge) to balance the difficulty of players’ tasks; the players need to navigate the whole ship to pick-up and throw objects and since objects fall all over the ship, they need to move quickly and avoid all distractions

Implementation Changes

As we started to implement more and more of our mechanics and design elements, we realized that we won’t have time to implement all desired game systems and functions, so we had to compromise. As always, it turned out that game production takes far more time than expected and two months was simply not enough for developing everything we originally planned. Here is the majority of the changes we made which differentiate the implemented version from our initial game idea:

players no longer have individual roles, but they still need to coordinate and divide the tasks among each other to be able to successfully complete the game session

Figure 10: The latest version of our main gameplay loop (implementation stage)

since there are no individual roles, there are no individual tasks – there are two general tasks that need to be completed, which are directly linked to their matching health bars

Figure 11: An in-game screenshot showcasing main UI elements which display win conditions

the third task (and its health bar) is implemented in the game, but it doesn’t function as intended, so now it serves as a world building element

Figure 12: An in-game screenshot displaying how the instantiate incoming objects script is used to create a better atmosphere since we didn’t have enough time to make it work as a collision damage dealer

the number of types of obstacles is reduced to two
instead of using a hammer and destroying wooden boxes and picking up nails, players now need to use a carrot, destroy an ice-box, pick up dropped ice-cream, and then fix water leaks with the ice-cream – we selected these specific objects because we wanted to create absurdity and illogicality to provoke humour

Figure 13: An in-game screenshot showcasing how the interaction between carrot and ice-box results in getting an ice-cream

reappearing random true or false questions which are meant to stop the game and influence the health bars depending on the right or wrong answer are still present in the game, but they do not interfere with the gameplay at this stage

Figure 14: An in-game screenshot showcasing the implementation of random questions which, at this stage, do not interact with the gameplay

Learning How to Play

We knew that teaching players how to play our game is a very important aspect of game design, but since we have created the tutorial at the end of the production process, our tutorial ended up consisting of written instructions appearing at the start of the game. We used this opportunity to further express our humorous storytelling style to hopefully provoke as many laughs as possible.

Figure 15: An in-game tutorial instructions

The Final Polish

To further develop the right atmosphere and final look of the game, we added in-game background music, and audio clips for both end scenarios, chose a friendly font which suits our art style, and used appropriate background images for our graphical user interface, along other similar visual and audio details. We couldn’t have made it without some inspiring artists who gave permission to use their work, so here is the full list of credits for all assets used in our little sailing adventure!

Ahoy, Me Hearties! Credits Download