GOOZILLA
(2024)
Game Description
Goozilla is a pick-up-and-play rogue-like with chaos and destruction front and center! Destroy the city and bring an end to humanity as an all-consuming and ever-expanding blob of slime! Feed on buildings, vehicles, and whatever else you find to grow and unlock new abilities and upgrades. Fight off the military as humanity tries to stop you!
Genre / Tags
Third-Person
Rogue-like
Kaiju-Sim
Villain Protagonist
Highlighted Design Tasks
Player 3Cs
Eating Ability & System
Growth System
Gameplay Loops & Progression
Quests System
Balancing
Designers
Jakob
Jan
Ferenius
Björklund
Design Lead
Scrum Master
Product Owner
Luke
Serafin
Systems & Gameplay Designer
Edward
Serafin
Level Designer
Programmers
Jan
Jakob
Björklund
Ferenius
Product Owner
Design Lead
Scrum Master
Luke
Serafin
Systems & Gameplay Designer
Edward
Serafin
Level Designer
The Full Team
WORK HIGHLIGHTS
Highlights of tasks I did and the design and work processes behind them 🌟
GAMEPLAY & SYSTEMS DESIGN
Highlights on the design intentions & processes behind the gameplay and system design. Check out the Technical Design section below for implementation details, e.g. code, tools, and software infrastructure planning.
Gameplay & Systems Design 🎮
3Cs: Character and Abilities 🦸
When designing the character and core abilities of the player, I did so in three steps:
-
I tried to match the design with player expectations about the fantasy of playing as an evil slime. For example, the slime aesthetics and abilities, such as the dissolve ability.
-
I adjusted the design to encourage certain play-styles and emotions in line with our design pillars.
-
I adjusted character parameters dynamically as you grow to make you feel more powerful.
1. LEVERAGING PLAYER EXPECTATIONS 💭
Before anything else, I had to make sure that we could deliver on the player fantasy. The project's theme – Antagonist – had led us to a game about slimes. By making the player play as an iconic video game enemy, we could leverage pre-existing player associations to make the experience more intuitive, powerful, and memorable. I designed the looks and abilities of the character with this in mind.
The player slime greedily consuming props in the environment.
The player slime character eating things, chasing police cars, and causing havoc. Keep in mind that the player is technically just a sphere, the jiggle-ness is achieved with the material.
The Looks of the Slime 🎨
As a gameplay designer on a team without artists, I handled the character's visuals.
Following KISS (Keep It Simple, Stupid) design principles, I made a slime consisting of just a 3D sphere with a custom material. Using references from games, movies, and anime, I tweaked its color, opacity, etc. to meet the minimum needed to sell the character.
To enhance the fantasy, I planned to add soft-body physics that responded to movement, growth, and abilities. I collaborated with Moa – one of our programmers – but after a week of testing, we scrapped it due to resource constraints.
Dissolve Ability 🧪
I designed the slime's core abilities and collaborated with Luke – our systems designer – on ideas for, and implementation of, the unlockable abilities and upgrades.
I designed and implemented the dissolve ability, which became the main mechanic for interacting with the world and destroying the environment. You overlap with everything smaller than you and collide with everything bigger. While overlapping with edible objects, you dissolve them. To dissolve something, you simply go into it. This was intuitive and required minimal onboarding.
I implemented all the feedback for the ability. E.g. the dissolve material, sounds, VFXs, and EXP pop-ups of different sizes depending on the edible.
Movement 🏃♀️
In terms of movement, slimes tend to jump, jiggle, or slide their way forward. For our character, I used sliding for movement mechanic since it made it easy to keep momentum and precision when dissolving things.
The player going into houses and using slime dissolve ability to consume them. Notice dissolve effect on the edible props and the different sizes of EXP pop-ups depending on the sizes of the edibles.
Code: Eating Ability 💻
Here is code from the player character's event graph that manages the eating ability. The player and edible objects communicate through interfaces. When the player gets close to an edible object, they send their level to the object. The object will adjust its collision response to the player depending on whether the level is high enough or not. If it is, the player will be able to overlap with it and dissolve it. Read more about the edible system infrastructure in the Technical Section.
The slime material reaching out to close-by edible objects.
2. DESIGNING FOR A GREEDY PLAYSTYLE 😈
Aside from making the slime look and behave as players expected, I also wanted to leverage its character design to immerse players in the villain power fantasy and encourage them to greedily consume and destroy their environment.
The main way I did this was by adjusting the slime material to "reach out" towards close-by objects. This provided direction to players and naturally nudged them to go towards edible objects. It was also satisfying and helped drive an addictive short-term gameplay loop; each time you consumed something, the slime material was already reaching out towards the next thing.
I also tweaked the dissolve ability damage. Dissolving objects needed to be slow enough that you felt like objects dissolved, but fast enough to keep the player momentum and encourage the player to always greedily move towards the next thing to eat.
Code: Slime Distortion Shader 💻
The slime shader uses distance fields to determine the distance to the nearest surfacec and then distorts towards it. There are separate parameters for height and width distortion and I also limited the vertical distortion to make it level towards the ground.
3. SCALING CHARACTER WITH GROWTH 📈
As you consume things as the slime and grow in size, I wanted to sell the size and make you feel increasingly powerful by adjusting character parameters as you grow.
For example, aside from increasing the absolute size of the character, I adjusted the slime material "reach out" distortion parameters to nudge the player to stay greedy and go after larger objects.
Scaling the Jump Ability 🦘
I also adjusted the physics parameters of the character to make it feel bigger and heavier. For example, I designed and implemented the jump ability and adjusted the gravity and jump force of the character to sell the size and build anticipation for the landing and slam attack of the jump.
I also added an increasingly intense camera shake to the jump's slam and worked together with our sound engineer Moa to make it sound heavier and more epic. Together, with balancing tweaks to ability parameters like slam radius, etc., these adjustments helped sell the size and made you feel increasingly powerful.
The jump ability for a SMALL player.
The jump ability for a BIG player.
Code: Jump Slam Ability 💻
I implemented the jump ability and all its upgrades, including the slam that damages and pushes away nearby edible actors. This code does all that and the feedback for the ability (camera shake, VFX, sound, etc.)
Gameplay & Systems Design 🎮
3Cs: Camera & Controls 🎥
To sell the slime character to make the size and growth visible, we chose a top-down third-person perspective for the game. The biggest challenge in the camera design was to sell the scale and growth of the character while still encouraging aggressive player behavior. To do so, I worked with the perspective of the camera and narrative framing, as well as dynamically adjusting camera parameters with player size to create a tilt-shift effect as you grew.
Since we aimed for a casual audience and pick-up-and-play experience, we tried to simplify controls as much as possible. Aside from that, I also adjusted parameters like sensitivity dynamically as you grew larger to help sell the sense of scale.
A large player with and without the tilt-shift effect. Notice the change in depth-of-field of objects further away.
Dynamic Tilt-Shift Camera Effects 📹
I applied a tilt-shift effect to the camera. By simulating a real camera and adjusting parameters like sensor width, aperture, and depth-of-field, you can make objects around the player look like miniatures. The intention was to sell the full-grown size of the player, and that it would encourage playfulness and destruction since the environment looked more toy-like.
Initially, I applied this effect already at the start of the game. However, the blurry peripherals disrupted navigation and dis-encouraged exploration, so I applied it gradually instead as you grew. I made the adjustment exponential, so that it became the most noticeable towards the end of the game, at the stage where you were supposed to feel giant and unstoppable.
Challenge
Camera Distance 🤳
I used the distance between the camera and the player to help sell the scale of the player. Initially, the relative distance decreased as you grow, making the player take up more space on the camera viewport and therefore feel bigger. However, while this helped sell the size, it made players more defensive discouraged them from exploring.
To improve this, we adjusted the scaling curve to make the camera distance scale more linearly with a slightly reversed effect. By doing this, we opened the player up to the world as you grew, rather than restricting it, making them play more aggressively.
The camera distance before and after readjusting the scaling curve. Note that the actual size of the player is the same, but the feelings of scale and power differ.
The camera distance scaling curve by player level before and after the change. Notice that the new pattern follows the player size.
Narrative Framing 📖
Initially, I intended to frame the game as a disaster news broadcast filmed from a helicopter point-of-view, essentially making the camera its own character. The intention was that this would make the player feel more empowered, as well as further encourage villainous role-playing.
Aside from the helicopter perspective, I also wanted to add responsive news broadcast HUD elements, e.g. scrolling news headlines. The headlines would leverage a responsive UI system that we had already prototyped for another concept, and I figured that we could use them to reinforce destructive behavior and the players' own stories by responding to their states and actions.
Unfortunately, we didn't have resources to implement this idea, but I believe it would have enhanced the experience and create a more unique presentation and identity for the game.
Mock-up for the news-broadcast perspective idea.
Controls 🎮
For the controls of the player, we focused on the following two areas:
Gameplay & Systems Design 🎮
Designing the Gameplay Loops & Progression 📈
Since the intended core experience was a power fantasy where you grow increasingly powerful and destructive, I designed the gameplay loops as self-reinforcing feedback loops. Major challenges were balancing player power and growth with difficulty to keep the player in a state of flow, and onboarding player objectives. To empower players and encourage them to switch up priorities and playstyles during a playthrough, I also designed a structured quest system with two quest types.
The Core Loop ➰
Intended Core Experience
The core concept for the experience was a power fantasy where you grow from a small slime to a huge city-destroying calamity. Since it was centered on the theme of growth, it made sense that player progression, scale, and sense of power would follow an exponential growth curve. Based on this, I designed the progression loops as self-reinforcing positive feedback loops where actions of exercising power increased and reinforced that power.
Core Loop & Progression Explained
Consuming or destroying enemies or props gives you EXP. Gain enough EXP and you'll level up.
When you level up, you and your destruction range grow in size, you can eat bigger props, some of your base stats increase, and you can select a new ability or upgrade. However, with your new level, more and stronger enemies will also spawn.
Your increased power and an increased pool of edible and destructible objects worth more EXP then increase your overall destruction and EXP gain.
Core Loop Diagram
Gameplay Loops & Objectives ➿
Given the core loop, the gameplay and objectives can be broken down into short-, medium-, and long-term loops as follows:
Short-term Loop 💥 | Medium-term Loop ⏫ | Long-term Loop 🏆 | |
|---|---|---|---|
TIME FRAME | Second-to-second gameplay | Minute-to-minute gameplay | ~20 min (a complete playthrough) |
OBJECTIVE | Eat and destroy. | Level up and grow stronger. | Destroy the largest building. |
GAMEPLAY | Consume or use abilities to destroy props and enemies to gain experience. Evade enemy attacks and don't get hurt. | Gain enough experience to level up so that you grow, can eat larger objects, and gain new abilities and upgrades. Customize and optimize your build. | Grow big enough to annihilate the city and consume the largest building without dying. Reach the highest level you can and try new builds. |
Player Onboarding 🏫
In any game, it's essential to onboard the player to the gameplay loops and objectives as soon as possible, or the lack of direction can make them feel frustrated, dumb, or confused. We wanted to do so in an as intuitive and non-intrusive way as possible and enable the players by nudging them in the right direction and then confirming that they're doing the right thing. I collaborated with Eddie – our level designer – to get things rights.
For example, we:
-
Customized the starting area as a safer learning area.
-
Customized the player's EXP requirements for the first three levels to selectively time the first level-ups.
-
Introduced one thing at a time. For example, eating, upgrades, combat, etc.
-
Highlighted important targets in the level.
-
Added prompts and tips when needed.
The player starting the game, seeing the highlighted skyscraper on the other side of the city (the end-objective), getting introduced to eating by trying to go somewhere, and their first level-up.
Player eating things as they start.
Player Onboarding
Introducing Eating 🍴
The main way we on-boarded the short-term loop was through clear feedback on the main core actions, namely eating. With enough satisfying visual, sound, and UI cues, we would reinforce players to engage with those actions and convey the short-term gameplay loop.
To ensure they would interact with edible props, we placed small props around the player start location so that, no matter which direction they went, they would unavoidably go into them and consume them, giving off positive feedback and encouraging them to search out more edible objects.
Player Onboarding
Introducing Leveling Up ⏫
Introducing eating was the most important thing to onboard first, but, after that, I wanted to introduce leveling up as early as possible. It was the only way to progress in the game and the main incentive for engagement.
To introduce leveling up and growing larger, I worked together with the level designer to customize the starting area as a safer playground area to help the player get used to the concepts, and I customized the EXP progression curve for the first couple of levels to time the level ups well for the progression in that area.
We wanted to let the player to play around, destroy the area, and get a bit greedy and offensive before introducing combat. So I adjusted the enemy spawning to start first when you reach a certain level, and customized the abilities you can choose from at the start so they excluded combat-focused abilities.
First level-up and some destruction in the starting area.
A player starting the game, seeing the end objective and prompt as they fall.
Player Onboarding
Introducing the End Goal 🏆
It's good to introduce the end objective early so that players feel like they have direction and are progressing towards something. In our case, it was to grow big enough to destroy the largest skyscraper at the other side of the city. To communicate it, we:
-
Placed a big animated in-world red arrow above the skyscraper.
-
Added an outline shader to the skyscraper.
-
Made the player fall from the sky at the start of the game, getting an overview of the city, seeing the skyscraper.
-
Added a text prompt with instructions at the start of the game that slowly faded away.
Designing the Quest System 📌
Why a Quest System? 🤔
Without a quest system, there was very little meaningful difference between edible objects in the level. Some were bigger, had more health, gave more experience, or were more dangerous, but overall, it didn't matter what you ate as long as you kept growing and didn't take too much damage. I wanted to add the quest system to make destruction and upgrade choices more mindful and targeted, to encourage players to switch up priorities and play style, and to empower them.
Quest Types 🗃️
We didn't have resources in the team to create a complete narrative or fully hand-crafted quests, so I opted to creating a more structured and scalable quest system with simple formulas for two main quest types, each serving a different purpose to players and the game. The rewards for completing either of the two types would be upgrades to relevant player abilities or stats.
Reactive Quests 🔁 | Crafted Quests 🎯 | |
|---|---|---|
FORMAT | "Destroy N amount of X" | "Destroy target X" |
PURPOSE | Encourage build specialization and role-playing, and reinforce the story the players create for themselves. | Provide extra challenge and prompt players to switch objective and priorities. |
DESCRIPTION | Unlocked when you destroy certain types of targets, or use certain abilities, prompting you to do more of it. | Pre-made quest with a specific target that gets spawned into the level and you have to destroy. |
TRIGGER | Triggered as you consume certain edible types or use certain abilities. | Triggered as you reach certain points in the map or a certain experience level. |
EXAMPLE | You destroy a school, and a a quest appears: "School's Out: 1/10 Schools Consumed" | You reach a military base, a fleeing military vehicle gets spawned in, and a quest appears: "No Escape: Destroy the fleeing enemy general" |
Reflection 💭
Unfortunately, we never had time to implement the quest system, we had to prioritize other features. But I think it would have added a lot. At the moment, the core gameplay loop of dissolving things and leveling up is so satisfying that the game is still fun, but destruction is not very mindful and the gameplay-narrative connection is weak. Here, the system would have helped. It would also have made the level and encounter design more interesting for our level designer, whose work became much harder because of the lack of unique targets, enemies, and story elements to place around the level.
Gameplay & Systems Design 🎮
Designing for Player Flow 🌊
To keep player in a state of engagement and flow, we needed to balance skill and challenge. I mainly tackled this through the design of the health and difficulty systems. However, there were two challenges that required additional adjustments: 1) the game was open world, and 2) it was a power fantasy. To improve flow, we added difficulty zones to the map, dynamic difficulty increases, airstrikes you needed to avoid, and extra difficult and risky encounters. I also designed two basic enemy types.
Flow & Health ❤️
Flow 🌊
For optimal engagement, you want to keep players in a state of flow by balancing skill and challenge. In our case, it came down to balancing the player's health, i.e. enemy damage vs heal amount.
Health System 💖
The game was about destroying things and growing larger, so I tied healing to eating and destroying objects, and I made the player regenerate to full health and upgrade their max health and eating heal amount when they leveled up. I added the full health level-up regeneration to encourage greedy and risky behaviors from the players, in line with our design pillars.
Health System Diagram
Enemy damage hurts you and eating props heals you. Levelling up will fully heal you and increase your max health. You can also choose an optional upgrade to increase the amount you heal when eating props.
Improving Flow 🛠️
Aside from general balancing of the health system, Goozilla had two major challenges when it came to balancing difficulty and skill:
-
🌍 Open World: The level was an open-world sandbox and the player could go anywhere.
-
🦹♂️ Power Fantasy: The game was a power fantasy and compared to the start of a session, the player grew immensely powerful.
We tackled these challenges with the four following additions:
1. Difficulty Zones 🏴☠️
To make sure that players didn't progress further than made sense for their level, we divided the map into difficulty zones with increasing difficulty towards the end target. The further you progressed, the stronger enemies would spawn. We also added extra enemies along the zone borders so that the player needed to be strong enough to survive progressing to the next area.
Zone 1
(Starting & Onboarding Area)
Zone 2
(Combat Learning Area)
Zone 3
(Challenge Area)
The player map, divided into the major difficulty zones.
2. "Dynamic" Difficulty 📈
Difficulty needed to increase with the player's power level so I dynamically increased difficulty each time they leveled up by:
1) Spawning in stronger enemies and phasing out weaker ones.
2) Increasing the spawn frequency and maximum amount of enemies.
3) Increasing the frequency of airstrikes (undefeatable attacks you need to avoid).
Diagram of how the difficulty increases during a playthrough.
3. Airstrikes 💥
To keep players on their toes, no matter of how strong they were, we added airstrikes to the game. These were undefendable attacks that you needed to avoid or you would lose a massive amount of health. They were easy to avoid, but still made the players shift priorities and encouraged them to keep moving. We added major VFX, sounds, and screen shake to them, making avoiding them feel intense and epic.
An airstrike landing close to the player.
4. Risky Situations 😨
We added enemies and areas with extra high damage or difficulty where you'd likely lose a significant amount of health, creating tenser risk-vs-reward dilemmas and encouraging switching up play-style, e.g. hit-and-run tactics. For example, we added more enemies on the borders of the difficulty zone and around military bases. We also added and spawned enemies with extra high damage.
A player getting close to the border of a extra high difficutly zone and retreating back into a safer area.
Enemy Design 🚓
We had two main enemy types in the game:
-
🗼 Stationary enemies (turrets) were used to add difficulty to certain areas and mark the transition between difficulty zones.
-
🚗 Moving enemies (tanks, police cars, etc.) spawned dynamically and served as living targets and challenges.
Moving enemies chased you down, shot at you from a distance, and ran away if you got too close. This encouraged you to be on the move made players feel empowered and chase after them in villainous role-playing fashion.
To add stronger enemies when you progressed and difficulty increased, we added multiple sub-types of each of the enemy types. For example, we had both machine gun turrets and missile turrets, and both police cars, tanks, and missile-launching vehicles.
Enemies getting into shooting range and then running away from the player when they get too close.
Gameplay & Systems Design 🎮
Balancing the Game 🔢
I did all the balancing for the game. It was difficult to balance since it was a systems-heavy game with a lot of interactions between systems. To make this manageable, I formulated I six-step balancing plan and made sure to collaborate with the other designers and programmers to make everything easy to tweak.
TECHNICAL DESIGN
Highlights from the technical design and feature implementation. Showcases software architecture design, programming skills, and collaboration skills. I did a lot of technical work for this project, so these are just a few examples.
Technical Design 💻
Coordinating the Technical Design 🧑💻
As Design Lead and Scrum Master, I ended up coordinating and organizing most of the technical design discussions in the team. For example, I designed level design tools together with the level designer and brought together programmers and designers to create the software infrastructure for the upgrades and ability system. I also designed and implemented many of the systems and features in the game (e.g. the growth, leveling-up and, eating systems) and optimized the performance of the game together with another designer.
Technical Design 💻
Edible & Elemental System 🔥
Everything in the city – every rock, car, bush, house, skyscraper, etc. – was supposed to be edible, given that you were big enough. They were also supposed to be destructible by unlockable elemental abilities such as acidic goo. I designed and implemented the software infrastructure for this edible and elemental system. I made it component-based so that any type of actor could be made edible, e.g. enemies as well. Two challenges with the system were: 1) to make it easy for the level designer to work with, and 2) to optimize performance (we had over 6,000 edible actors in the scene).
Edible System Infrastructure🍴
All props and enemies were supposed to be edible, destructible, and affectable by elemental effects, but only if the player level was high enough. To make the system scalable, I broke the logic down into actor components and Blueprint interfaces:
The eating system and elemental system in action. Notice that objects turned on fire takes damage over time, and that not just the player attacks, but also other things in the environment like barrels can cause them.
BP_EdibleActor Event Graph 💻
Player abilities can turn objects on fire, acid, etc. The Element Manager actor component manages the addition, behavior, and removal of these elemental effects. The interactions between actors are triggered with a Blueprint interface. Damage is applied on Event Tick, which is toggled on and off for performance and uses a custom tick interval
Eating Logic 🍝
The player could only eat edibles if their level was high enough, otherwise, they collided with them. I added a Simplified, the logic could be mapped as follows:
The eating logic in action. Notice how a prompt appears and the player collides if a prop's required level is too high.
Element Manager Logic 🔥
Every edible object could be affected by three types of elemental effects. While these were active, VFX appeared and the object took damage. Since there would be thousands of objects in the scene and each one could be affected by several elements at once and take damage over time from each, performance was important. I put the damage logic for all elements on the same Tick event, added a custom tick interval to slow it down, and disabled Tick when it wasn't needed. While the e.g. VFX and timers could have been handled more efficiently, the performance was still satisfactory with this setup.
Simplified diagram of the element manager logic for adding, removing, and applying effects.
AC_ElementManager Event Graph 💻
Player abilities can turn objects on fire, acid, etc. The Element Manager actor component manages the addition, behavior, and removal of these elemental effects. The interactions between actors are triggered with a Blueprint interface. Damage is applied on Event Tick, which is toggled on and off for performance and uses a custom tick interval
Notice how health widgets are only visible when edible objects have been damaged and you are close enough to them.
Optimizing Performance 🔎
Since we had thousands of edible objects in the scene, we needed to optimize their performance. Another designer and I conducted performance profiling analysis to find bottlenecks. We noticed that the biggest issue was visualizing all the health widgets for the edibles. To improve this, I e.g.
-
Added a trigger collider around the player to make sure that only edible props close to the player showed their health bars.
-
Made sure to disable event Tick whenever possible for the edible actors and all their associated components.
Aggregated, these changes more than doubled the frame rate. See examples in the code in the BP_EdibleProp Event Graph above.
Level Design Tools 🏢
One challenge with the edible props was that they needed to be easy for the level designer to work with, and easy for me to maintain and balance. For example, it needed to be easy to switch between props, and it was important that all the edible system parameters (e.g. health, required player level, etc.) were updated in a way that minimized human error.
We started by discussing our respective needs and preferred workflows, and then we iterated from there. Our solution was to:
-
Only have one edible actor type that we placed in the scene.
-
Create an enum with all the edible prop type IDs.
-
Create a table with all the parameter values for each ID.
-
Select the ID for an actor, and then automatically update all the parameters for the actor in the construction script based on the table values.
-
Manually overwrite the mesh if needed for variation.
User switching the edible ID for a prop in the level, and thereby also its visuals and properties. Also notice how they use a custom mesh and the data table with all the values for the edible IDs at the end.
BP_EdibleProp Construction Script 💻
The level designer can select an EdibleID (enum) for a BP_EdibleProp Actor in the scene and all the edible system parameters, visuals, and physics for the actor get updated based on values from a data table.
Technical Design 💻
Growth, Upgrade & Ability System ➕
Every time a player leveled up, they would grow, various stats and abilities would scale with them, and they could choose a new upgrade or ability. I planned the software infrastructure for this and collaborated with other designers and programmers to implement it. I also designed and implemented the unlockable jump and slam ability, and helped out to implement upgrades for the other abilities.
Level Design Tools 🏢
... discussing with systems designer to fully understand the technical needs for the system and clarifying things, rather than making assumptions from documentation.
... growth
... plan out software architecture... bounce with him and programmer
... implementation
... example, jump ability
User switching the edible ID for a prop in the level, and thereby also its visuals and properties. Also notice how they use a custom mesh and the data table with all the values for the edible IDs at the end.
DESIGN LEAD
Highlights from my work as design lead. Showcases teamworking skills, documentation skills, and holistic design.
Design Lead 🤗
Designing the Overall Concept and Experience 🤩
I was appointed as Design Lead by the team. Throughout the project, I held a one-week ideation workshop with the team to come up with game ideas and establish the core game concept, created a summarized GDD to clear up misalignments in the team, and formalized the core design pillars, narrative guidelines, and other documentation.
1. Ideation Workshop 🧠
Since I was assigned Design Lead, I volunteered to moderate our one-week workshop to come up with game ideas. I find creative processes fascinating and one of the things I love the most with game development is when ideas spread and cross-pollinate between disciplines and give birth to new ones.
Having led several of these workshops before, I had iterated forth a process that worked well to make the most out everyone in the team, regardless of how creative or outspoken they are. It's also great for creating a safe, creative, energizing, and collaborative team environment.
Miro screenshots from the brainstorming sessions and workshop.
Challenge
2. Identity Crisis ⚠️
In the initial game concept we came up with during the ideation workshop, the game wasn't a rogue-like, it was more of an arcade game. But we decided to shift direction since some team members felt that a rogue-like would suit their portfolios better.
This, however, led to an identity crisis where, while it felt like we were all on the same page, we had different expectations about the design within the team and were pulling it in different directions.
Realizing this, and hoping to avoid miscommunication, I quickly summarized the game concept and design explicitly on paper using an elaborated version of a template I'd made for the ideation workshop. It is basically a brief GDD and included what I'd found to be the most valuable questions to establish the identity of a game during previous projects and workshops. This was the fifth iteration. I ran the filled-in template by the other designers.
This helped clear up three major points of confusion in the team:
3. Creating the Design Pillars 🏯
As Design Lead, I took the initiative to formalize our design pillars. Overall, we collaborated closely within the team and talked openly and frequently about any confusions or discussion points. Documentation was informal and minimal. However, I felt like it was important to write down the design pillars so we could avoid more misalignments and so that we had a framework to base our design discussions and decisions on. I noted down five pillars based our previous design discussions and ran it by all of them and the rest of the team.
4. Narrative Guidelines 📖
It was unclear to us at the start which role narrative would play in the game and how story heavy the game would be. We had lots of exciting ideas, but no narrative designer that could go through with them. Moreover, we weren't even sure that a elaborated narrative would fit with the overall game concept.
Narrative Implementation Pillars ✅
It was important to figure out the role of the narrative ASAP. To help out, I drafted pillars and best practices for narrative implementation and bounced them with the rest of the team.
Narrative Implementation Pillars
-
"This is not a narrative game. Keep narrative simple and easy to understand to focus on the gameplay."
-
"The player should create their own story. The city is their playground. Narrative should empower their story, not direct it or detract from it."
Bad Practices | Good Practices |
|---|---|
❌ Too serious. | ✅ Encourages humor & playfulness. |
❌ Skews the player's story. | ✅ Enhances the player's story. |
❌ Limits the player. | ✅ Empowers the player. |
❌ Interrupts gameplay. | ✅ Delivered with & connected to gameplay. |
❌ Requires explanation. | ✅ Intuitive to understand. |
Narrative MVP (Minimum Viable Product)
To quickly create a simple narrative, I mapped out the most important narrative questions for players for different aspects of the game. I then drafted multiple suggestions for each of the questions and discussed them with the Product Owner to select the ones that were the most appropriate for our team and scope.
Game Area | Questions | Answers |
|---|---|---|
Introduction / Situation | Who are you? Where are you? How did you end up there? | Alien blob landed on earth in a timeless stylized city. |
Upgrades | Why do you get to select new abilities and upgrades? | You grow. It's only natural something comes with it. |
Quest Objectives | Why/how do quests appear? Why should you care about them? | Special threats appear or rewarding structures are consumed. |
Motivations | What's your motivations? What's the main objective? | Destroy the landmark to annihilate resistance. |
Ending | What happens when you win or lose? | Arcade type of game. Menu appears. |
SCRUM MASTER
Gameplay & Systems Design 🎮
PLACEHOLDER
Since we aimed for a casual audience and pick-up-and-play experience, we tried to simplify controls as much as possible. Aside from that, I also adjusted parameters like sensitivity dynamically as you grew larger to help sell the sense of scale.