The Wind and the Wisp Post Mortem -- Design

Designing Games about Grief is Hard. Alt Control Games are also Hard. Level Design is also Hard. Designing Games is Hard!

October 7, 2025

Between May 2024 and August 2025, the project faced many development challenges, and each of the disciplines came together to do post mortems. I’d like to share the results of those conversations, as celebrations of the project’s success, and reflections on the challenges that will help us grow in future projects!

In May 2024, the Design team faced a great mountain: making a game about grief. And about two characters. And an alt-control game!

Last week, I posted the Engineering Post Mortem, this week I'd like to share the design team's! This post mortem is a blend of my own thoughts and the design team’s reflection on the process.

What Went Well?

Teaching the Main Mechanic and Player Engagement.

Design had a lot of really difficult questions to resolve early on:

How do we get players to blow?
How do we get players to do different breathing interactions?
What are the different breathing interactions?

Design iterated on a lot of different blowing mechanics and UI. Our initial design was built on objects that Wind can interact with, like fog. However, players didn’t know to blow on the fog, or expected to be able to blow on it from far away. We experimented with a UI element in the lower right that is always showing you the state of your blowing, but does a special animation when you are near a puzzle that needs blowing. This was unclear and did not draw players attention enough.

We came up with a dandelion UI indicator that appears when there’s a blowable puzzle (e.g. a dandelion). This was more effective because dandelions have a real-life counterpart that people already know to blow on. We also narrativized calibration to explain to players that when they see the dandelion UI, it means something nearby can be blown away.

The primary takeaway here is: with alt control, it’s difficult to get players to understand how to use the control system, so use real-world metaphors as signifiers to communicate affordances. See here for a full, comprehensive breakdown of microphone iteration across engineering, design and UI/UX.

Original-UI-Bottom-Right.mp4

Early UI Prototype

Original-UI-Bottom-Right-2.mp4

Early UI Prototype

A lot of Playtesting and Iteration, with Good Communication and Prioritization.

We had weekly playtests that encouraged fast iteration time. Responses and feedback were always delivered in a timely manner, and priorities were always clear. Additionally, designers didn’t get bogged down with trying to perfect something before testing it. The constant playtesting and iteration gave designers a strong sense of meaningful iteration and priorities.

The constant playtesting and fast iteration was particularly important for the first level of the game, Chrysanthemum Mountain. It defined how we tutorialize the blowing mechanic, set up the narrative, and even defined some of our core mechanics. This level underwent the most iterations, and the most dramatic iterations, with at least one thing from every iteration being included in the final version.

The first iteration included:

Wisp auto pathing (taking away player control and having the Wisp move on its own when the player does something that the Wisp didn’t like).
The original Wisp movement interaction (press ‘E’ to enter the breeze, this has now become the Dandelion).
Blowing away phantom pillars to reveal broken ruins.
The Chrysanthemum flower did not have a unique mechanic.

These playtests help reveal flawed parts of our design, such as:

Entering a breeze feels mechanical and uninteresting.
The flowers don’t feel special.
Blowing away pillars and fog doesn’t feel crunchy, it has no gameplay function and creates no meaningful outcome other than revealing the map.

The final result of Chrysanthemum Mountain in the game is the result of 6 major rounds of iteration. See here for a full breakdown of all level iterations!

The Garden went through several scope changes too!

Communicating Two Characters: The Wind and The Wisp, and Achieving Design Goals in a Game about Grief.

The thesis of this game was to explore the portrayal of grief in games, leading to our experience and project goals:

Players will feel like they are the Wind, like they are the friend who misses the Wisp.
The blowing mechanic should cause players to physically feel the emotions we want them to experience, strengthening presence in the narrative.
Players will feel bitter sweet at the end of the game.

This led to our most complex design goal: a game in which players control two characters through different modes of input and perspectives. The Wisp is the on-screen white ghost controlled in the third-person while Wind is the petal VFX that gets triggered when the player blows into the microphone and is seen in the first-person. We want players to feel as if they are taking on the role of the Wind, and the Wisp is their friend.

We prototyped many different narrative and character implementations early on. Playtesting these prototypes revealed players didn’t know the Wind was a character--it felt like an environmental force they could trigger. This led to a feeling of detachment from both the Wind and the Wisp. Later on we discovered that players felt like they were the Wind when blowing allowed them to interact directly with the Wisp, because it felt like they were playing with a friend. For example, at the beginning of the game, blowing to get the Wisp’s attention. Or blowing a dandelion, causing the Wisp to get swept away as well, rather than blowing at the dandelion, and pressing ‘E’ to have the Wisp grab a dandelion seed in the breeze.

As we shifted our design towards a stronger focus on the interactions between the Wind and the Wisp, players started reporting a feeling that they were a presence in the game. One playtester said: “I don’t know if I am the Wind the character, but I think I identify with the Wind more than the Wisp, if that makes sense.” This was validation that we’d achieved our design goals. This increase in sense of presense, and the Wisp responding to the player, led players to report they felt attached to the Wisp.

The primary takeaway here is that telling a story about grief is not the same as creating a moment of grief for players. We achieved this in The Wind and the Wisp by creating space for the player to become attached to their friend, and lead to the grief moment at the end of the game, rather than telling a moving story that allows players to empathize.

My favorite playtest feedback of all time: “I didn’t really understand the narrative but somehow I still felt moved at the end.”

Great Overall Pacing and the Final Game is Very Positively Received on Steam!

The entire game is paced very well, even despite the massive scope cuts, we always had sharp attention to ensure the entire experience was communicating its goals, not just individual levels. The final game is on the shorter side, averaging about 25-30 minutes for completion, but the length serves the message we are trying to communicate, which is the most important measurement of the game’s success.

This has been validated by Steam reviews after release. We have a 97% positive rating. Many players wish it was longer, but also recognize the impact of the story and the ending! It’s been extremely rewarding to see players, who are downloading and playing the game independently and are touched by the ending.

What Could We Have Done Better?

Slow to Pick Up Momentum.

We struggled with narrative decisions in September - December 2024. At that time, we were exploring whether we should pursue a narrative heavy experience or focus on developing the Wind/Wisp relationship. This largely stemmed from a big fundamental question we had yet to answer:

Who is the Wind? Are they the player? Or are they a concrete character, with thoughts, feelings and emotions?

The original story followed the 5 Stages of Grief and ended with a big dramatic climax in which the Wind and the Wisp come to terms with parting ways. We prototyped many different narrative implementations–including one with a full text implementation and dialogue representing the Wind’s thoughts–but these prototypes created more player confusion. Even worse, it created confusion amongst the team what the goal was.

We revisited the project goals and they served as a reminder that the central thesis of this game is to have players feel like they are the Wind, they are the person that misses the Wisp. Adding a narrative voice actively hurt those goals. We looked back at playtest data to carefully look at which parts of the experience players were responding to and why. Players really enjoyed the first moment in the game, when they meet the Wisp, not because of the story, but because players liked getting the Wisp’s attention and the Wisp is very endearing.

We decided that the Wind is not necessarily a character, but they are the player's window into the world. As long as players feel like they the Wind allows them to interact with the Wisp, than they indeed are taking on the role of the Wind. We threw away a lot of narrative prototypes, and went full steam in the direction of designing interactions around the player (A.K.A the Wind) and the Wisp and abstract the narrative. After this decision, the entire team began to move forward with a lot of momentum. For full iteration progress on the Wind and the narrative, see here and here.

I would say a lot of this prototyping was productive, because it did narrow down the effective parts of our design and help steer us in the correct direction. However, if we were to do it again, we would look back at project goals more often, which might enable us to make decisions more quickly and not waste time and resources.

Wind-Follow-Proto-1.mp4

The Wind as a persistent, on-screen character that follows the Wisp. This was ultimately scrapped.

Early iteration of more lively Wind VFX coming from the player/camera.

Communicate Level Scope and Constraints Earlier.

This one relates to the previous point, but because we spent so much time and resources on resolving narrative and direction issues, level design had to hit the scope chopping block.

As we were navigating narrative issues, level designers were not given very strong direction or clear instructions on what they should be doing. Each level had a very vague explanation on the macro, which each level designer worked off of. Level designers figured out the meaningful arc as they were designing, which led to some levels being really long, or with mechanics that were too complex. When we hit Alpha in February 2025 (sequence complete), we looked at the state of the project and realized we would not be able to complete the entire game to a consistent level of polish by May. This led to a ruthless scope cut–we cut an entire level, reduced the garden size, and condensed all the other levels. Once we set these constraints clearly, every level moved very quickly in spring 2025.

If we were to do it again, we’d standardize gameplay levels, which would allow us more time to polish level mechanics and reduce the amount of work that gets cut. For example:

Define the gameplay length of each level.
Communicate technical constraints (e.g. this level cannot have water).
Write mini arcs for each level, visualizing the gameplay, earlier so designers can create blackouts/prototypes more meaningfully.

Scope Evaluation

Testing Levels with Microphone and not the Space Bar.

All of our external playtesting was conducted using the microphone, which was the intended input method for the final game. However, during internal testing, most of the team tested with the Space Bar to simulate blowing. This led to some balance issues, especially with the Petunia level. Due to time constraints, we finalized the blow sensitivity values for the Petunia mechanic shortly before release and were only able to internally test those changes. A lot of playtesters reported that the Petunia level is a bit too difficult, and they get winded from all the huffing and puffing!

If we were to do it again, we’d ensure internal playtests were done with the microphone.

Pod Meetings and Communication Between Design and Engineering.

Design and engineering had difficulties prototyping gameplay early on due to unclear asks and deliverables. Early in the project, design held weekly meetings to share updates and blockouts, while producers relayed information and requests to engineers. However, this indirect communication created bottlenecks and led to some features being implemented differently than intended.

I implemented this structure as a way to abstract engineering and design work, preventing engineers from doing more work than they should have. However, the lack of context created issues for both engineers and designers.

If we were to do it again, we’d start immediately with level pod meetings. This creates better trust between team members, allowing for designers to clearly show their work, explain what they need an engineer’s help with, and for both engineers and designers to openly brainstorm solutions and negotiate work together.

Additionally, we found a meeting structure that worked extremely well for levels:

Before the meeting, the Designer does their best to implement the level/gameplay gameplay.
In the meeting, Designer walks through the level, in editor, and explains the level flow to an Engineer.
1. The Designer explains which parts they need help with (e.g. “I was able to get the Wisp to move with the car, but the player needs to manually move the Wisp. The Wisp does not move automatically with it).
The Producer summarizes what needs to be done, assigns tasks, and the Designer and Engineer confirm.

Conclusion

In summary, what worked:

Teaching the main mechanic and player engagement via real-life metaphors to mirror how to engage with unconventional controllers.
Playtesting a lot revealed parts of the design that were working, and extrapolating those learnings drove the success of the rest of the project.
Achieved a heart-felt, emotional ending, by focusing on creating player attachment with the main character.
Looking at the game holistically, not level by level, to create a strong overall arc.

In summary, what could have gone better:

Lack of adherence to the project goals led to slow ramp up time.
Communicate level constraints and scope earlier, especially on levels, to allow more time for polish and consistency between levels.
Test with the alt control/microphone more, even for team internal playtests.
Create meeting structures that allow for context and direct collaboration between design and gameplay engineers.

Page updated

Google Sites

Report abuse

The Wind and the Wisp Post Mortem -- Design

Designing Games about Grief is Hard. Alt Control Games are also Hard. Level Design is also Hard. Designing Games is Hard!

October 7, 2025

What Went Well?

Teaching the Main Mechanic and Player Engagement.

A lot of Playtesting and Iteration, with Good Communication and Prioritization.

Communicating Two Characters: The Wind and The Wisp, and Achieving Design Goals in a Game about Grief.

Great Overall Pacing and the Final Game is Very Positively Received on Steam!

What Could We Have Done Better?

Slow to Pick Up Momentum.

Communicate Level Scope and Constraints Earlier.

Testing Levels with Microphone and not the Space Bar.

Pod Meetings and Communication Between Design and Engineering.

Conclusion