💡 About Design 💡
Table of Contents
Key Takeaways
- Design Domain Ownership gave us clear, separate responsibilities while maintaining our team roles.
- Follow the Fun!
- Following the fun requires iteration.
Design Goals
Our main design goal was to create a standard running and jumping platformer with a free-form movement mechanic that creates a feeling of freedom.
Design Domain Ownership
In the last two weeks of pre-production, we realized we were having trouble splitting up the responsibility of making design decisions. Based on advice from advisors, we decided to switch our design process to use Design Domain Ownership. Under Design Domain Ownership, team members take responsibility for specific domains of design, ensuring that related tasks are completed on schedule. It is up to the domain owner whether they do the tasks themselves or delegate to other team members; their job is to make sure design decisions happen before deadlines.
The design domains we identified are as follows:
- Player Abilities
- Obstacles and Threats
- Levels and Rooms
- Narrative and Dialogue
- UI/UX and Interfaces
- Art and Aesthertics
- Audio and Music
Because Narrative, Art, and Audio are all asset-heavy domains, you can read more about their design processes here: Art Page -- Audio Page -- Narrative Page
You can read more about how we used design domain ownership here: Game Design Document
Lesson 1: Design Domain Ownership
Once we established our domains, our trouble with splitting up responsibility disappeared, and we felt ready to tackle production as independent members of a cohesive team. Design domain ownership ended up being a great way for us to split up responsibility and allow the team to focus on the areas we’re most interested in.
Design Domains
Throughout production, we each iterated on our domain and brought them together as the game took shape. Let’s go over the major game design decisions of each domain and how we reached them.
Player Abilities
There were three major iterations of player design that we iterated through during our design process.
Iteration 1
The player had a resource meter which increased as the player moved. Basic player movement felt awkward and clunky compared to leaf dashing and flinging. The player had three health but getting hit interrupted the flow of movement, which made taking damage awkward and clunky as well.
Iteration 2
The leaf dash mechanic was changed to focus more on momentum and the fun feeling of flinging. Player movement values were changed to make running and jumping feel more aligned with the freedom of the leaf dash. Overall the player was changed to encourage swapping between normal mode and leaf mode to maintain momentum. The player’s health was reduced to one after feedback confirmed it did not make gameplay too challenging.
Iteration 3
The resource meter was changed to recharge fully on contact with the ground because feedback indicated that charging it didn’t flow well with the new focus on chaining and momentum. Otherwise no major changes were made.
Levels and Rooms
Initially we designed rooms to be small movement puzzles where the player needed to learn how to use their abilities to get to the end. As the player changed over time, the rooms evolved into longer rooms that focus on using forward momentum and staying airborne to overcome challenges.
We balanced gameplay and narrative by trying to ensure that every narrative room had at least two gameplay levels between them to break them up. Our iteration on gameplay taking longer than expected meant that the number of rooms was significantly cut. In the end we were happy with the results of our room designs, because fewer rooms that better support our gameplay experience was more important than having many rooms that still felt clunky to play.
We used a spreadsheet to track the progress of room designs and decoration as we got closer to the end of production. See the spreadsheet here:
Obstacles and Threats
Obstacles and threats in the game were designed to serve one of two purposes: forcing the player to switch between the two modes or creating pressure on the player to keep moving forward. We wanted the gameplay to feel like a continuous line of movement and limit the need for the player to slow down. Early designs featured enemies and spikes that were crowded, meaning the player didn’t have the freedom of movement we wanted. Over time the obstacles and threats were changed to better support the player building momentum and continuously moving in the right direction.
Read more about their designs in the Design Bible.
UI/UX and Interfaces
Our initial designs for UI focused on a simple, clean, and easy to understand interface. The first iteration got decent feedback during playtesting, so we decided it was not worth continuing to iterate on the design.
Lesson 2: Follow the Fun!
Throughout all of these design domains, we were always looking at what playtesters found the most fun and using it to improve our designs. Multiple times we found ourselves back to the drawing board to brainstorm new ideas and find new ways to accomplish our design goals. Even though our initial design ideas have been left behind, that’s okay, because we ended up with a more fun experience for it.
Player Iteration vs. Room Iteration
Throughout production, we swapped back and forth between tweaking our player to match our room designs and tweaking our rooms to match our player design. We wish we had identified this pattern sooner and made the decision to favor just tweaking rooms to fit the feel of the player. Our vision and pillars emphasize the feel and experience of controlling the player, so using that as a design anchor point would have kept us better aligned with our original vision and pillars.
Design Blew Up. It's Okay. What We Did When It Happened
Even with all of this preparation, we noticed in week four of production that our gameplay domains had slowly become mismatched. Once we noticed there was growing friction in the gameplay experience, we took a step back. The owners of each domain met together to realign our design decisions with our vision, pillars, and the feedback we were getting from playtesters. From this discussion we developed a refreshed set of design rules to guide each domain going forward.
These are the rules we came up with:
- Don't stop moving
- Leaf Dash as a performance
- Pressure player through time-based events or enemies chasing
- Chain together dashes to maintain momentum
The intent of these new design rules was to lean into the fun our playtesters found in our game. Up to this point we hadn’t fully identified that momentum was the core of the fun in the game, and taking a step back to assess helped us follow the fun. Knowing when to step back helped us produce a better experience for players.
Lesson 3: Following the fun requires iteration.
We were always tweaking numbers, and adjusting mechanics in our effort to follow the fun. Without this iterative process, game elements like the player would have remained in the clunky unfun state of iteration 1. Our success in following the fun came from being willing to adapt, notice when things weren’t working, and take a step back when needed.
Design Bible
Want to see even more about design? Check out the Design Bible below for all the details.
