This page covers my approach to:
Co-Pirates is a 3-player local couch roguelike co-op game, where 3 pirates search the high seas in the quest for plunder! Make builds and synergies with your friends to defeat the bosses and get the most gold! This project was developed using Unity Engine with four people in a duration of three months. The game currently features two floors and two very diverse boss fights. Let us know how far you get!
We developed this project for our Master thesis at ITU Copenhagen to help us understand if adding roguelite mechanics to a couch co-op game will make it more replayable. Controller and multiple players are recommended!
This game could have not been made with the amazing Pixel Salad Team. A lot of sweat and pixels were put into this project over the course of three months. The project could have not been achieved if it wasn't for these amazing talented individuals.
To balance our quality of life we took a small team holiday to Portugal, where we all got to surf and relax.
|Adam Saidane||Audio and Systems programming|
|João Parreira||Systems programming|
|Sindre Aasland||VFXs/Art/Animations & Character Controller|
Pitched initial idea and iterated on its design. Documented changes and Game Design of project, came up with new concepts and observed playtests to see what was wrong with the game.
Helped manage the team, from documenting the process, the game design, and iterations to using producing methods such as scrum and explorative Game Design.
Helped develop core systems and their iterations such as the ship, A.I., all User Interface, and many other gameplay elements.
It would be impossible to describe the whole development process here, so here are some of the main high-level stuff that I did mixed with what happened in the project. Additionally, from designing and developing, I helped find music, audio assets, making Vfxs and other minor things that would be too bothersome and long to put here. One of the key Game Design ideas we followed was a process called “Follow the Fun Methodology”, based on Game Maker’s toolkit video “The Games That Designed Themselves”. It consists of an explorative iterative process that allows a loose design to flourish through iterations into what is the most fun. We attempted the initial Game Design idea of mixing couch Co-op and pirates in Global Game Jam 2023. We realized the idea was fun, and we should pursue it further and make it into our thesis project.
During the project, our process was to use Agile methodologies to get us to our goal. As the producer, I made sure we had bi-weekly sprint meetings and that every work day, we had quick stand-up meetings. I also made certain people communicated, helped each other, and managed our Notion pages and our Agile board - Hacknplan. We were diplomatic, and my role as a producer was to help the team in terms of managing its structure, setting meetings, talking about our goals and state of the game, and making sure we got to where we wanted to go while everyone having a say in the decisions and discussions.
We started by playing references video games such as “PlateUP!”, “Overcooked”, “Spelunky”, “Enter the Gungeon”, “Risk of Rain” and “Slay the Spire” to both understand what made these genres replayable and fun. We played Board Games such as “Forbidden Island” and pirate-themed board games. I made a Game Design Document to determine the possibilities of the world, enemies, items and mechanics, even though it became obsolete over time since mechanics kept changing due to our tests. However, it was used almost as a wiki for ideas; for example, a list of possible enemies, possible weapons, and abilities for players and ships.
We tested the game every two weeks, no matter its state since we attempted to do it even though it became obsolete over time since mechanics kept changing due to our tests and quick iterations. One of our first tests was a physical game to test the game loop and some cooperative mechanics.
Talk about Modular Game Design, Gyms and collaboration During our development process, we used a methodology called “Modular Game Design”. When developing our game, we wanted to think long-term rather than make spaghetti, unstructured, un-reusable code. We decided to make our development tools and libraries and use a methodology called “Modular Game Design”. This methodology focuses on the longevity of game development rather than on a per-game basis. Even though the two games might be vastly different, they will likely have common aspects. We build not only games but also development tools that would work for both this project and others. Additionally, this modularity was used for designers and developers alike to quickly create new features without the need to untangle dependencies since code would no longer be as feature-specific.
We used template scenes, which we called “gyms”. They served the purpose of demonstrating the most important mechanics, such as the shop, ship, different types of interactions and so on. This helped us keep structured code with little dependency. It is also helpful for those who didn’t make the feature and can check it out and apply it to a scene/feature they are working on. It’s also perfect for debugging since you can test the one feature.
One of my first focuses was designing and developing a ship that could float and use physics to interact with different aspects of the world. Making the boat use physics made it more natural and gave us new features we didn’t have to program.
Throughout developing the initial prototypes, we iterated a lot. We also made a lot of brainstorms for what the gameplay could be, the type of enemies, and many features, content and systems. At the same time, we researched different games and made mood boards and reference lists.
We wanted to determine the most fun/fitting way to control the ship. There were a lot of variations we tested. The one thing that stuck was that players had to interact with the ship’s wheel to control the boat. The wheel could be used to turn the ship and interact with the sail, raising it up and down to control its speed (There was even a button for an anchor at some point). In one iteration, the sail resembled “Sea Of Thieves”, being its entity that players had to interact with to bring it up and down. Later on, we made it so if there were two players interacting with the sail, it would also be faster. These iterations were made to incentivise collaboration between players even though we all agreed that it just made gameplay more confusing and chaotic, and we already had enough of that.
One of my prototypes of the map was a randomly generated hexagon map. Since we wanted to make a roguelite, we thought about procedurally generating the "dungeons" every time. However, we ended up crafting the levels manually for research purposes, prototype purposes and time purposes.
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.
During our playtests there was a bug where players could walk on water and we realized it was quite a fun mechanic to get to different places. We decided to then implement a row barrel mechanic, so when players entered the water they would have their own controllable row barrel which made them feel more drifty and slidy. This mechanic ended up being very fun and helped us fixing the design problem of going back and forth to islands. We also got a lot of feedback about the mechanic being fun, we considered changing the whole gameplay to be based on this (We ended up not doing it).
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.
When developing and designing the ship, I had a lot of creative freedom and tried many different things. I took care of tasks such as the ship being hit, damage taken, damage given by cannons, audio, VFXs, cannonball trajectories, and generally, making sure the mechanics were fun and what we wanted. I added knockback every time the ship rammed something and even sounds based on its velocity. I tried to make the boat interactive with the world, no matter what it touched. If the ship came into contact with barrels, they dropped coins. There were pick-up power-ups that would boost the ship’s health, speed for a few seconds and other attempts of making it more arcady and interactive.
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.
I designed a tutorial that explained the most basic mechanics, such as moving, dashing, interacting, shooting cannons and headbutting. We wanted to teach the basic mechanics to the players, including how to open gates, an essential aspect of the game. Ideally, we would have made a tutorial that let the players drive the ship and made the tutorial feel like playing the actual game. The tutorial mimicking the gameplay with simplified and hand-made levels specific and even easier monsters and a boss would have made it an essential part for players to learn how to play the game and interact in less restricted environments.
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.
We redesigned the boat shape and eliminated the turning mechanic. The idea was to have a more arcade ship control movement that would allow for a different type of gameplay. The turning mechanic, where the ship rotated before the pivot, needed to be clearer for the players and made it hard for the ones not controlling the ship to know where they were. We wanted to make the ship less realistic and more arcady. We made a few concepts, and this one stuck, even though we iterated until we found a suitable variation.
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.
The AI of the game had two different types: one type moved on top of the water, the other on top of islands and physical objects. Initially, we brainstormed and designed possible enemy AI variations. Our first AI was melee skeletons that chased nearby players and could change targets if another player hit them, or they would go back to patrolling if players were too far away. These skeletons used state patterns just for the easiness of adding new mechanics to them if we find them useful. We eventually made some ranged skeletons, too.
All these resided on islands and were later changed to go in row boats (since we deleted islands). Sometimes, skeletons in row boats come to attack the ship; once their boat gets close to the player’s ship, they can board the ship and shoot the crystal. The game’s first boss is based on these, where a wave of these enemies spawn around the players, and their boat cannot move.
During development, there was quite a bit of iterations of the AI. In general, we used the navigation system in Unity, so we didn’t have to code our own. The enemies had a very simple flocking algorithm to avoid each other. as much as they could.
For the enemies that moved on water in the initial versions, there was a small boat that followed players when nearby and shot at players. Secondly, some giant ducks shot balls at the enemies. They used to be the first boss fight. Honestly, who doesn’t want to have giant ducks in their game that shoot spitballs at them? The boss fight design had three different ducks and had three phases. The first was mostly idle ducks shooting at the players, where the ducks would pop up and down, similar to Wack-a-Mole, and the third one was the same as phase two, but they would rotate around the player’s ship.
In the final version of the game, a lot of the variations were changed and deleted, and new ones were created. Do note some variations are not mentioned here due to just being too much. The enemies the final version of the game included were summoner skeletons, skeletons on cannons, bomb enemies, and exploding barrel-dropping enemies. All the summoner skeletons did was summon bomb and barrel-dropping enemies. The skeletons on cannons shoot at the ship, and the bomb enemies just always head towards the crystal and explode when close to the crystal and can be both shot at and headbutted. The barrel-dropping enemies carry an exploding barrel and, when close to the ship, drop it, forcing the players to have to push it off the ship.
The second boss is the Kraken. At the end of the second level, the Kraken comes out of nowhere and grabs the player’s ship. It has two phases; in the first one, the tentacles attack the ship and are not moving, and in the second phase, the tentacles start moving around the player’s ship. We thought battles to be important to give players an extra amount of challenge on each floor and an extra challenge.