OSAKABE
Release Date:
30/06/2021
Academic Year:
Year 2; 2020/21
Project Duration:
32 Weeks
Roles Performed:
(System) Designer
Product Owner
Lead Designer
ABOUT
Osakabe is a game the was worked on for three blocks of eight weeks each as a year two project. The individual blocks had their own specific focus, these where: ‘Concepting’, ‘Pre-Production’ and ‘Production/Release’. While these were individual blocks and you could switch projects in-between them I personally stayed with the Osakabe team/brief throughout.
THE GAME
The MVP-release is a single-player, first-person horror game with only one enemy. With the exception of one lightning strike the entire experience is AI driven, so there’s no reliance on scripted events for jump scares for example. The player plays as a child who’s only real objective is to escape the Japanese castle while avoiding encounters with the Osakabe wherever possible.
MY CONTRIBUTIONS
I’ve worked on the game for the three blocks meaning I’ve been involved from the initial concepting, all the way through to the release. My primary role was that of the System Designer while on the way I also took up part-time side roles, such as Product Owner during block C and Lead Designer during block D, when they became part of the project brief.
Concepting (Block B)
The way the block was set up was to have three two weeks sprints where the team would split off in strike teams and make a prototypes with somewhat of a game jam mindset. Then in a fourth and final one week sprint all the prototypes would be mixed up to form one single coherent concept that would be pitched and go through a greenlight process where the teachers acted as outside investors to determine whether or not the concept would go through to the next block. I’ll show my prototypes for each of these three sprints. Do keep in mind these and quick and dirty throwaway prototypes so don’t expect anything near a shippable state of quality in this section.
Sprint 1: Wall crawling player movement (+ complementing enemy ideas)
During the initial brainstorming and mind mapping the boards and conversations were dominated with ideas on wall crawling player movement from spiders to squirrels. I was assigned to the strike team to test some of these ideas out. On a team with a character artist, animator and level designer I prototyped the functionality.
The wall crawling player movement was the main point. The player can seamlessly walk up walls and do a full loop while the camera adjusts (including its gimbal lock). The gravity is still existent, meaning that if the player would jump or shoot a projectile, they/it would fall to the ground. While it worked and gave lots of new gameplay possibilities, it was an idea that would put a lot of constraints of the overall design. Therefore this was not pushed further as we were looking for ideas that encouraged even more diverging while this one would require us to scrap all the other ideas, which we decided not to do.
I addition I worked on some very quick and dirty enemy prototypes. Although these are completely fake (no AI whatsoever, just trigger-boxes) I think the results are quite something. The one swings back and forth while also swinging its ?tentacles?. If the player touches these they are restrained by slowing their movement down and the enemy sounds the ‘alarm’. The other one has something like a whip that turns into a spiderweb which is then used to launch itself it the player gets close. While their end functionality isn’t too crazy, these were mainly mind map board pieces on how we could make simple enemies still be very interesting to the player.
Sprint 2: Atmosphere Prototype
For this prototype the goal was to test out ways to create a (horror) atmosphere. To test this I created a setup of a looping hallway that would change every time you walked a loop. This way we had a base environment to compare changes we made to.
The results of the prototype weren’t what we were looking for but still helpful. We found that very little of horror games is to do with gameplay but relies a lot more on cinematic techniques. After I did the initial setup me and a level designer made iterations for it. We weren’t getting the results we were looking for as we discovered just how important aesthetics are in horror (while we as designers were always programmed to look at gameplay mechanics first). We learned that we as designers would need to work closer than ever with VA to nail the game feel as the aesthetic layer proved more important than mechanics, something we would struggle with for the remainder of the project. While still helpful, if we wanted to realize the original purpose of the prototype we should’ve tackled it with environment artist instead of designer.
Sprint 3: core gameplay prototype
This sprint was about testing out gameplay based off a narrative concept from a strike team that researched Japanese folk lore during the previous sprint. We were tasked with prototyping an enemy that the player couldn’t directly look at. While the original concept would kill you on sight, we also tried version that could only be seen in the mirror but not without. During this sprint I primarily took responsibility of her spirit animals.
Our game thus far was very much lacking a real core game loop. As we were to make a horror game we wanted the keep a bit of the fear of the unknown alive of the main enemy, meaning we couldn’t over saturate the experience with it. I then thought about how the spirit animals could fill the void. The final concept was a fox that would search for you in your surrounding area, if found it could attack you but instead would run to the Osakabe to alert her. During this moment the player could still stop the fox at the risk of running straight into the Osakabe herself. The sudden rush of faster gameplay and increase of risk was a nice flow switch with the creeping slow stealth. It was able to reflect the intense horror climax with intense gameplay that would create stress as the game suddenly speeds up and the player needs to make life depending decisions. While the prototype worked and it became the core game loop it had to eventually be scrapped during production due to down scoping to just one enemy/AI.
Pre-Production (Block C)
Next up was the Pre-Production block. This introduced several new aspects such as the PO role. This was also the first time we would start a block where we left off last block. This introduced us to challenges such as on-boarding new team members who also may not fully agree with some decisions from the concept phase.
It’s also noteworthy to mention this was a largely individual block. While we were all working on the same project we weren’t a team. DP, VA and PR were separated and it was acceptable if not everyone’s work lined up. Any issues that would come from this would be dealt with in the next block, for this one the focus was put on the individual level.
Product Owner Role
As mentioned, the PO (side)role was introduced this block. This is something I took up for the Design discipline. While I had often been ‘implied’ lead, this was the first time it became my direct responsibility. Leading a relatively small team of four designers my core responsibilities were:
– Maintain, update and prioritize the product backlog.
– Review work and determine whether user stories are done.
– Share and maintain the creative concept.
As this was my first real gig in any form of leadership position it served great in a way to find my leadership style. However, as mentioned, it was a very individually focused block. Thus this role almost became more that of a facilitator as I was enabling the team to reach their own goals instead of pushing towards the product’s priorities. Additionally our team was small enough to discuss most topics together instead of leaving it with just the PO. I would however take another leadership role in block D so I will discuss my leadership skills and experiences more at length there!
System Design Work
The before mentioned role of PO was just a side role, my primary role within the team would be that of Systems Designer. As this was a fairly individual block we each had our own feature we were responsible for. Mine was the main enemy, the Osakabe.
Right out of the gate there was a massive scope issue. The concept was made by and for a team of 8 designers and 4 programmers. Unfortunately, with the new team I was all that was left to work on the enemy. The concept was already ambitious, with Alien Isolation as an important reference, for the old team, let alone for me as an individual. Aware of the little amount of time there was to play with I divided up the work and time-boxed it on the topics to ensure I would get to everything.
Design
Production/Release (Block D)
Text
THE TEAM
Not the entire team took part for the entirety of the project, the indicator with the name states for which blocks they were part of the team (B = Concepting/Marmelades, C = Pre-Production, D = Production/Release).
Design & Production
Andrei Olenic (D)
Antonio Minev (C, D)
Jip Haas (B, D)
Luuk Sieberichs (D)
Samat Imanalin (B, C, D)
Stefan Kwak (B, C, D)
Riccardo Lusuardi (B, C)
Shane Breedveld (B)
Renato Civadelić (B)
Sem Lefering (B)
Jip van de Reijt (B)
Visual Arts
Alicia Heredia (D)
Anastasiya Fedaseyeva (D)
Bernhard Altena (D)
Hanne Hammarstrøm (B, C, D)
Niamh Noordam (B, C, D)
Linda Fijlstra (D)
Lyubomira Petrova (B, C, D)
Veronica Redlaff (D)
Zsófia Danková (C, D)
Isa Weijers (C)
Svetoslav Tsekov (B, C)
Jack Glavimans (B)
Programming
Angel Dimitkovski (B, C, D)
Davey Vermeeren (C, D)
Jordan de Jong (B, C, D)
Szymon Tydrych (B, C)
Brian de Lange (C)
Diana Calistru (C)