HOLEY SHIP
DESCRIPTION
Holey Ship! is a 2 players survival couch co-op game where you play as one of two pirates chained together on a sinking ship! Communication and coordination are essential to navigate your way on the ship and solve the problems before it’s too late.
Stealing the ship seemed like such a great idea last night. But now you and your fellow mate are awake, the rum has worn off, and all the other pirates are really mad. Mad enough to try to sink the ship you’re on without even saying hello!
The only way to survive this is to work together!
PRODUCTION
3 MONTHS
ENGINE
Unreal Engine 4.23.1
TYPE
Team Project @ VFS
GENRE
Couch CO-op, Acrion
TRAILER
INTRODUCTION
Holey Ship! is the biggest team assignment we realized, over the length of 3 months and following strict industry pipelines from Pre-Production to Final. We had the pleasure to get professionals from the industry to visit and help when we got stuck, and it was overall a huge chance to learn and improve in many fields.
Working on Holey Ship! I took care of the Game Design, the Level Design while also being the Project Manager. I had the pleasure to work with my amazing team of 4 plus the help of 4 sound designers for music tracks, sound effects and voice overs.
Although we had an amazing team, we had no designated programmer with experience in C++ or C#, so we decided to rely on Unreal Engine 4 using what we learned during the year in level design: Visual Scripting.
My goal was to focus on the design aspect of the game, making sure our scope was small to leave enough space at the end to deliver a polished game. The fact that I also assumed the Project Manager role, made me struggle to find enough time to complete all my tasks. Luckily, my team didn’t require too much assistance and we hit every milestone in time.
DESIGN PROGRESS
PRE-PRODUCTION
From the very first meeting, where we brainstormed ideas for the game, I heard out every idea and made the final decision based on factors such as resources, time, skills and more. This helped me identify the optimal solution in a short amount of time and move on to the next discussion. The most important decision during Pre- Production was to value and measure our individual and group skills and identify the kind of game that would benefit the most from those. Since we all shared a background in level design, we identified a game with simple mechanics and interesting level design as the perfect candidate to showcase our skills.
PROTOTYPE
The main concept of the game was to have our two characters held together by a chain with the idea of having chaotic and funny scenarios around the necessity of coordination and communication to complete the tasks. This core feature was a big question mark in terms of behaviour, the clip here shows how unpredictable it was, so I decided to prototype the chain early and discard it if it wouldn’t work properly in a week.
Luckily our programmer was able to realize an amazing working chain with simulated physics, avoiding a big risk and moving on to the rest of the prototype.
PRODUCTION
We had two months to create our game from scratch before the alpha milestone, with a strong game concept and just some small things to adjust in the design.
I decided to get a 3D layout in the engine first, to get an idea of the camera angle and collision with the surroundings. I did my best to keep every decision to this point coherent with the pillars and the vision of the game. That came in handy when we had to decide whether we had an elevator between floors or a ramp. After a long meeting with the team, I saw in the elevator the best candidate for the vision of the game and it ended up being a good choice.
ALPHA/BETA
Since our game heavily relied on the feelings the players would experience in game, we got the most valuable feedback only in alpha. The hardest part was to focus the play test sessions on what we needed and gather only the useful information.
My idea was to create a small game that would generate different feelings in the players, from happiness to anger, from frustration to relief, and from panic to calmness. The need for communication in the game definitely generated some feelings in our players. If I noticed too much frustration, or too much calmness, I just had to change some values to try and balance everything out.
POST MORTEM
Working on this project with my team was the best experience ever, I had the chance to learn many valuable lessons from mistakes and positive outcomes. halfway during production we got surprised by the outbreak of COVID-19 and as many others in the field we moved to remote work. We had to quickly adapt and find the best way to work that suited us. These are some of the things that went right and wrong that we found out during the Post Morten meeting.
WHAT I HAVE LEARNED
This experience taught me many valuable lessons and gave me a chance to research and discover many more ways to address problems.
-
As a Project Manager, I learned what are the responsibilities and duties that the position implies. I wasn’t interested in this role in the beginning but I found myself liking the role after all.
-
As a Level Designer, I mastered the use of Level Design factors. I learned how to make increasingly difficult levels for the players, using creativity to populate the level instead of requiring more and more props to be made.
-
As a Game Designer, I made a progressive difficulty system to keep players on the edge of success. I also learned the importance of focused playtests and feedback.
WHAT WENT RIGHT
Maintaining Game Pillars in vision
Once we established our core game pillars in pre-production, I took every decision with those pillars in consideration. Since we found ourselves stuck in a long debate regarding game mechanics, I realized we had to weigh each decision against the core pillars of the game. This process helped us tremendously to make the right decision and also saved us some precious time during the entire progress of the game. In the end, the overall product had much better results since everything in the game was made to enhance those core ideas and keep the overall vision of the game in focus.
Build the game around our strengths
With the initial struggle of losing two members, we had to reinvent our team composition and roles and make smart choices to avoid as many risks as possible. This is the reason why, from the early stages of pre-production, when brainstorming the game, I kept in mind our team strengths and weaknesses and opted for a much simpler game from a programming point of view with a focus on the level design aspect.
Prototype everything fast, polish it later
One last thing that went right regards the way we prototyped our ideas. Once we had the two candidates for our game, we quickly prototyped both of them in a very rough way to get an idea of what could work and what not. For the making of this game, we spent most of the time prototyping the chain: it had to work, be stable and be engaging to play with. thanks to the use of a real life prop of the chain we could check the engaging aspect of it while our programmer made it work and stable in the first week.
WHAT WENT WRONG
Team meetings and daily scrums
With the increase in workload due to the loss of two members (one of which was the project manager) we got stuck with an increased amount of workload to share and we slowly lost the habit of doing daily scrums and meetings. We all had a good idea of what we had to do, so the tasks were still getting done but only after a few weeks I was able to reestablish the daily routines and finalize the design of some mechanics.
Collaboration with sound designers
Even though we had an amazing start with the sound team where they got excited to be part of this project, I was the one assigned as the point of contact between the two teams and I struggled a lot to establish proper communication with some of them. We were getting started with the sound implementation schedule and I couldn’t find a way to get the missing sounds delivered. I got some backup/placeholder tracks to patch the missing sounds and I eventually found the issue with their team and got back on track.
Workload management
Even though each one of us had a specific job, we only later realized that the amount of work each one had was way too different. Some members of the team were burning out, working way over the schedule to keep on track with the tasks while some others had plenty of free time. This caused some internal issues between team members that I had to address and solve by reworking the task list so that who was free or ahead would help those behind.
