The first level I made was for early prototyping and figuring out how big the map should be, how many islands the world should have, how long players should spend on each island, and how they interact with the game's mechanics and systems. The second level used a grid system, and a boss fight test area was added (Blue cylinder walls area). Additionally, we tested time pressure by adding a mechanic similar to battle royales, where the area the players can travel gets progressively smaller and smaller due to a wall of death following the players. This also made sure players could only backtrack a little.

We tested many things such as, cannon balls being something you could buy in the shop, drop from barrels, crates or chests and being limited. Additionally they were carriable physical objects that you could grab, put in a cannon and shoot them (one cannon ball would give each cannon 5 shots). One of the reason for their physicality was to then have variations of cannon balls and being easier for players to chose which cannon balls they wanted to use. Secondly players could use them as objects to throw, and if thrown with enough force cause an explosion that could be fun to deal with enemies on islands.

I designed and developed the User Interface (UI). There were many iterations on what the UI would be, which elements of the game would have UI, and which wouldn’t. In general, we wanted a reasonably simple UI for the game and avoid as much diegetic UI as possible to have more spatial and meta UI. Due to time constraints, we opted to do more important things and stick with the simplest form. Most of the UI is also animated when something happens, making it feel juicy and giving the player feedback. For example, the boat taking damage flashes the crystal colour red very quickly, and the same for the health bar.

Initially, I designed a Hub that would work out as a playground. Players could test and interact with all the mechanics of the ship. Since the game has roguelite mechanics, we wanted a place players returned for after every run. We decided to go with a smaller hub for the players to focus on the game loop as much as possible for us to have shorter tests. The final hub only had a shop and ways for the players to interact to change some of their customisation, which included their hats and clothes. We wanted players to be able to customise the ship and more of the player's clothes, colours and features. However, due to restraints in time, we didn't do it even though we believed this would have incentivised player autonomy.

After we had explored a lot of mechanics and design ideas in the game and been through some playtests at the university, we decided to make a big pivot. We realized the game needed to be more fun. We were too concentrated on the idea of it being similar to "Sea of Thieves" top-down. We spent a whole week revamping our design and trying to make the game more arcade-like and focus mainly on the ship. We weren't that excited about the conventional pirate game we were doing and wanted to do something a bit more different. We decided to make the game feel more arcady and change the map to fit the style and gameplay of a roguelite.

One of the main reasons we decided to pivot was that we observed that the game did not have an effective goal and wasn't engaging enough. So we wanted to focus a lot on having goals and sub-goals so the players didn't feel bad. Additionally, the game did not effectively promote cooperative gameplay. Some players often opted to take on the role of captain and engage in disruptive actions, such as going to the islands by themselves, rather than working together towards common objectives. This undermined the intended cooperative experience we had envisioned.

Another one was the game's open-ended and expansive map, as it posed significant challenges for players. Players generally found themselves getting lost or uncertain about what they should be doing, resulting in a lack of direction and frustration. The size and structure of the map did not align with our goals of providing a streamlined and engaging gameplay experience. Overall we didn't believe the game was fun at that point.

We wanted players to focus more on a shared goal, so we decided to put more emphasis on the ship. We started by making the ship into an octagon. This was heavily inspired by the ship designs of “Lovers in a Dangerous Space Time” and “Don't Starve Together”. We then wanted the ship to have a front so players knew which way we were going.

We ended up also removing the verticality of the ship. Players could no longer leave the ship, which fixed a few design problems. Cannon balls no longer had a vertical effect, they now always go forward without any gravity, so we no longer need to show the trajectory of the bullet, which works better for top-down games. We simplified systems and even removed everything that diminished player cooperation. We made it so players could no longer grab and throw each other off the ship, shoot each other off cannons and headbutt each other.

Instead of having the enemy cannon balls hit the ship and take damage, we made it closer to a tower defense where players have to defend its core. We decided to have a crystal in the middle of the ship that determined that ship's health and gave the players something to protect it. This, compared to the previous version, where you got shot anywhere on the boat and loose heath, gave the players a way to fight the monsters before they touched the crystal which incentivises players to work together and strategise without just being the pilot player trying everything.

We wanted to incorporate more roguelite elements. We believed that adding features such as permadeath mechanics and an upgrade system would increase the game’s replayability and provide a fresh experience with each playthrough. By introducing these elements, we wanted to create a more dynamic and unpredictable gameplay environment.

During the project, I heavily researched the upgrade system. Upgrade systems in roguelike games was my personal sub-research question for the thesis project. I broke down the upgrade systems for “Hades”, “Enter the Gungeon” and “Risk of Rain” in detail. Then, using five categories of importance: Progression, Game Impact, Complexity, Scalability and Game Balance, I did a comparative analysis of these games on each of those categories. Figuring out their pros and cons related to our game and development time/resources and the ideal game.

Once this initial research was done, I designed a few mock-up ideas for what they could look like. We did believe that the most flexible design that also didn’t involve too many new skills which require time and programming was something similar to the “Risk Of Rain 2” one mixed with “Slay the Spire” and a tiny bit of “Enter the Gungeon”. The type of stackable upgrades was based on “Risk of Rain”. We believed it to be the most flexible. The way to get upgrades was based on Slay the Spire’s shop, where players could buy upgrades with a currency that was only kept during the playthrough.

Similar to Slay the Spire’s campfire, where players can choose to sleep and regenerate some health points, they can choose to spend gold to repair the ship’s health. Finally, our game features upgrades that can be unlocked, similar to Enter the Gungeon. There is an external currency that is only awarded when players finish each run and can only be seen and used in the Hub.

The upgrade system was made modular, so designers could quickly add new upgrades, their balance off spreadsheets, and change the rules of the upgrade system. Not all upgrades had to be stackable, some of them also unlocked a new skill. For example, there is a shield upgrade that players could buy, and if they bought it during the run, the ship would gain a new ability. One unlocked players could now interact with the crystal to momentarily bring up a shield that would cancel any damage made to the ship.

Besides making a contained test that only allowed players to go to a shop once per playthrough for game balance reasons, we also balanced our upgrade system using a spreadsheet with all of the upgrades and their different values so we could visualise the data better. Automating our spreadsheet to make calculations that figured out how much each value would be after each upgrade helped us visualise how much each upgrade would impact the base value in a very responsive way, which ended up being very useful. We also tried to figure out what the max values of each upgrade should be to a point where it wasn’t too overpowering/broken.

Apart from the comparative analysis, we decided to break down and analyse some specific roguelite games we researched and played throughout development to figure out interesting ways and common denominators that these games use to make progression and upgrade systems. The games we analysed were “Binding of Isaac”, “Slay the Spire”, “Dead Cells”, “Rogue Legacy”, “Spelunky”.

For our final tests, we used focus group interviews mixed with coding to test our hypothesis. We audio-recorded each interview after they played our prototype and asked questions about different categories. Later, we broke down all meaningful quotes into categories, one of them being upgrades, which I analysed thoroughly to see what the most important things were regarding replayability and additional players want. We learned a lot from this, and there are a lot of systems we would have improved had we continued developing this game.