The Wind was an incredibly difficult part of the project to design! The challenges arose from a multitude of factors:
What is the narrative we are trying to tell?
Who is the Wind? Are they actually the soul of the friend who misses the Wisp?
During preproduction, The Wind and the Wisp drew from prior art and had an intense story about grief. It had classic narrative elements following the Five Stages of Grief and would utilize character animations to convey the Wind and Wisp’s emotions. There was a level for anger, where the Wind is breaking objects in a fit of rage over the loss of their friend. A level for bargaining where the Wind breaks an animal’s home and has to repair it, believing they can control everything. A level for depression, where the weight of the flower weighs the Wisp down until they fall down into the depths of depression. A level for acceptance where the Wind sees beauty in the world and uses their abilities to bloom flowers again. Most importantly, there was a major climax in which the Wisp has made peace with their death and is ready to move on, but the Wind isn’t ready to let go and prevents the Wisp from leaving. After a confrontation, the game ends with the Wind accepting that the Wisp wants to go, and likewise the Wind realizes they have moved on and also no longer needs the Wisp to cope. However, this raised a lot of narrative questions. How would we communicate each character and their goals? How would we get the player to stop the Wisp from moving on? Throughout the entire game, the player is helping the Wisp collect flowers and repair the garden. Why would the player want to prevent the wisp from moving on at the end of the game? The Wind wants to, but would the player want to? Playtest feedback showed the narrative was unclear and complex and the two core questions we needed to address were:
How do we communicate that the Wind and the Wisp are two different characters with potentially different feelings?
How do we make the player feel like they are the Wind and not the Wisp?
With these challenges in mind, we did rigorous playtesting early on with the mechanic and character interactions. The very first prototype had the player controlling the Wisp, and blowing away fog so they could move the Wisp forward. There was no text or tutorialization explaining either character. These playtests showed us that players identified with the Wisp, and didn’t even know the Wind was a character.
This playtest feedback was logical and understandable. The Wisp is the character on the screen players see and have direct control over moving them. There was no reason for players to believe that there was the Wind as a character, and that blowing was part of the character narrative. Design came up with two solutions for this:
Have the player only control the Wind. Players blow into the microphone to create Wind, and WASD controls the movement of it. The Wind will pick up the Wisp, and the player would have to balance the Wisp on the breeze.
Autopathing and Wisp autonomy. Have points in the game in which the player loses control of the Wisp, and the Wisp does something of their own free will.
The former option was appealing, but would’ve broken other aspects of the game and required a lot of engineering work to pivot. The second option, autopathing, was a feature that triggered automatically when the Wisp entered an area or a specific event occurred. The Wisp would take control, and move on their own. We playtested this and learned people did not like this feature. Not only did players dislike losing control of the Wisp, but they perceived it as a cutscene instead of an actual part of interactive gameplay. We ultimately deprecated this feature because it was not serving our design goals correctly.
Autopathing playtests feedback. Player response to autopathing. It was overall negative.
The importance and function of autopathing raised a few questions with our narrative design: is the Wisp actually the spirit of the Wind’s deceased friend (which would support Wisp autonomy)? Or is it a conjuring of the Wind to cope with the loss of a friend (which would answer why the player can directly control the Wisp)? What exactly is the story we are trying to tell, and how are we telling it?
With the original narrative, there was a very intense story that was difficult for players to understand and feel like they were in the game. In order to address the disconnect, we came up with the idea that text would represent the player/Wind’s inner monologue. By letting the player know how the Wind was feeling, maybe we could inspire them to feel the same way. We also fully fleshed out the Wind character and introduced a robust narrative prototype that had a UI text box representing the Wind’s internal monologue. Players reported they liked the new narrative direction and started to understand the core conflict more, but were confused about who the voice belonged to. It suddenly felt like there were at least three characters in the game. The Wind, the Wisp, a narrator, and then the player observing these events externally. Although the narrative changes were overall well received, it did not sit well with me nor did it align with the project goals.
Navigating this decision of who the Wind actually is was the single most difficult part of the project.
One of my industry advisors was able to help me understand why the project was in so much pain. The project could go in one of two directions: narrative-driven, or mechanic-driven. Was the game trying to tell a story of Grief and the Wind and the Wisp navigating the Five Stages to heal from their separation? Or was the game trying to create an experience of loss and focus on the relationship between the Wind and the Wisp?
I also revisited the core explorations of the project:
Introducing narrative and text that represents the Wind would succeed in telling the story, but would struggle with putting a player into the story. This led to the decision we had to make: do we pivot in favor of telling this story? Or do we try and adjust the current story to be back on track with the core explorations? Or do we scrap all of our changes entirely? I knew intuitively it was wrong to run away from one of our core explorations, but I was afraid to express this to my team, because we’d spent almost a month prototyping narrative, building UI systems and Figmas. Moreover, playtesters were reacting positively to these new systems. This made me even more worried to bring up this design concern, because we had qualitative evidence that people liked it.
At this time, my narrative lead and producer brought up the concern that adding a voice to the Wind wasn’t in line with our previous narrative discussions about what the goal of the game was. We had previously agreed that it’s okay for there to be ambiguity about if the player is the Wind or not, as long as the core that this is a story about grief and saying goodbye to a friend at the end, the narrative goals are being met. Turning the Wind into its own character is one way to achieve that, but it might not be the best way that’s in harmony with the rest of the project’s goals, such as having the player feel as if they are in the game. Players ending up feeling like they were observers of the story was "red flag" feedback, as well, because it was destroying the most successful parts of our existing design.
This is when I clearly made the decision to move fully towards developing interaction, and move away from concrete narrative. The player is not just the Wind or the Wisp, but that they are in fact the Wind and the Wisp. This decision not only resolved our most challenging design question—is the Wisp actually the soul of the deceased friend, or is it just a figment of the Wind’s imagination, conjured to cope with the loss of their friend?—but also strengthened the feeling of the player having to juggle the complex relationship of both characters. This narrative decision also fit into our existing design.
The most important thing about this is that it flipped the core drive of the project a bit. Instead of making it character-oriented, it made it player and interaction-oriented. It also fully accepted that the Wind might not be a character in a traditional sense, but it should be a force that the player identifies with.
Making this decision was painful, because it meant nearly a month's worth of work would be thrown away. UI systems, writing, animations. A good chunk of it became unusable.
The development of the narrative and decisions on how we should design the characters and interactions was one of the most fascinating parts of The Wind and the Wisp’s design and development process. Initially, there was meant to be an intense story, with the Wind and the Wisp having their own desires and stakes, and utilizing the Five Stages of Grief for storytelling and creating grief in players. However, playtest data revealed to us that this was not one of the existing strengths of the project, and therefore would not be the most effective goal towards achieving the experience goal of having the player feel like the Wind and like they are in the game. The project had developed its own voice and personality, and the team listened to what the game wanted to be to make decisions and scope appropriately.