The Wind and the Wisp Post Mortem -- Art

Tying it all Together (Pun Intended)--Teamwork, Iteration and the Organized Chaos that helped The Wind and the Wisp Find its Art Style.

October 14, 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!

This is post mortem 3 out of 4, here to share the Art team's journey! This post mortem is a blend of my own thoughts and the art team’s reflection on the process. (See here for a full gallery of how much wonderful art the Art team produced!)

First ever Wisp concept!

What Went Well?

The Wisp is Adorable!

A lot of love went into the Wisp! The Wisp was one of the most consistent parts of the project–taken all the way from ideation–and is the most important asset in the game. It went through several iterations, lots of technical experimentation, and the final implementation is a combination of art (texture and normal maps + baked animations) and engineering (procedural animation and vertex shaders).

Art actually drove the narrative here. Our animator proposed the idea of the ribbon being arms, and everyone was obsessed! It resolved the questions about how the Wisp’s arms would look like, but also is where we got the idea that the ribbon is what gives the Wisp life. This led to the foundation for the Wisp’s ribbon coming from the heartbeat monitor line, and using the ribbon at the end of the game to support the Zinnia flower. The Wisp may be gone, but it’s still there holding the garden together.

Early on, engineering built the ribbon and cloth sim. The originally stiff Wisp started to feel a lot more dynamic thanks to the help of engineering.

Wisp without the ribbon and cloth sims.

Final Wisp Implementation!

The Wisp's simplicity was a strength in its implementation–the rig didn't need to be too complicated and overall it was easy to animate. However, the simplicity also meant we had to be creative with finding ways to breathe more life into it. In Autumn 2024, a project advisor told us “the Wisp could be more lovable”, so we started pouring resources into that.

We started by trying to give him some texture, like a knit sweater or emissive particles like Joy from Inside Out. We got feedback that he looks moldy :( It also brought up narrative questions about what is the Wisp made of, what is its weight? This also created some changes in gameplay and character controller.

We ultimately decided to go with a more flowy shape, making the Wisp look and feel light-weight and bouncy, and the red string became more of a ribbon shape.

The main takeaway from this is the Wisp was the consistent through-line of the game, from ideation all the way to release. Put love, time and resources into making the main character look amazing, as this contributes to players building attachment!

Wisp visual between October and November 2024.

2. Collective nurturing of talent. Good pipeline and iteration process for art. Excellent communication and collaboration.

The Art team faced a lot (and I mean A LOT) of unexpected challenges. From updating rigs to learning how to do 2D animation to fighting Unity, Art had an unstoppable attitude of “we will figure out this problem together, as a team. If our current solution doesn’t work, we will find a new way." Artists supported each other extremely well by celebrating strengths and were quick to help each other.

This positive mindset led to a really good culture of delivering feedback–it was always well-communicated and constructive, and never sugar-coated. We had weekly sync to go over art deliverables, and artists were always extremely enthusiastic and praised updates.

This was due to the nature of how feedback was communicated, and feedback was built entirely on critiquing the work, not the person. People would clearly point out elements of which versions they liked, and then the artist would find a way to combine those elements into the final pass. Art had a great attitude of giving feedback on what was directly in front of them. Assets always made it into Unity very quickly as well, with screenshots or videos posted so artists and the art lead could see and make adjustments.

3. Focusing on Hero Screenshots.

Hero Screenshots: Scenes that every single player will go through, and will experience the exact same way.

We used these to prioritize assets. Anything that every single player will see and experience the exact same way should be worked on first and make sure it looks amazing.

The Art Lead put a lot of time into the following shots:

The first shot of the game, the Wisp pacing around.
The first time players enter the Garden look good.
The zoomed out shot of the garden.

4. Good use of 2D, 3D, and Blending between the Two.

Our introductory sequence and ending sequence are both 2D, hand-drawn animations. A lot of players have reported really liking the transition from 3D to 2D–they say the transition feels really seamless! We took a big risk when deciding to do 2D animations (initially, we intended to have 3D animated cutscenes, but time and resource availability made that tricky). We were worried about the transitions, we’d heard art advice that transitioning from 2D to 3D and vice versa, if done poorly, can lead to misunderstandings from players. But players responded extremely positively to the art.

We blocked out some of the animations in 3D and took in-game screenshots, imagining that they were full 3D animations, and the 2D artist painted over some of them directly to harmonize the difference between 2D and 3D.

5. (Bonus!) The Swing!

Little did we know how important this moment would be! It's a common favorite moment for players, and a favorite amongst the art team.

What Could Have Gone Better?

Slow to Settle on Visual Style, Causing some Art Direction and Challenges Delivering Vertical Slice.

Art direction took a while to come together. Our Art Bible was missing a lot of important sections, such as Color and Shape Language. Additionally, we had a lot of assets that were used from purchased packages. Balancing these assets with in-house made assets was very difficult. Textures and modelling style created inconsistencies. We had to re-UV and re-texture a lot of purchased assets, but we weren’t able to re-texture all of them, so we chose based on which textural differences were the most egregious. For this reason, as well, we wish we had tried procedural texturing workflow earlier.

Art Style and References

Art references were often traditional media, and these art styles were difficult to achieve in game. We had to pivot art styles around that a couple of times. For example, we had amazing paintovers from our concept artist. We tried to push the Garden visually towards that (in terms of colors, and vegetation), but the art style was very difficult to achieve. We liked elements of the circles and brushes the paintover artist was using, but they were not achievable in-game based on our available resources.

Materials and Organic Materials

We didn’t talk about material composition when doing concept art. This created some narrative plot holes and created problems with modelling and texturing (e.g. we tried making the Wisp look fuzzy, like it’s wearing a sweater, but did we want to communicate a world that ghosts are fuzzy toys? Do we want the Wisp to feel like it has the weight of a weighted sweater?).

Texture Styles

Texturing pathways and the ground was very difficult for us. We did it with trial and error, and because we couldn’t settle on a texture style, it created blockers in being able to texture all assets.

If we were to do it again, we would have a more detailed Art Bible with the following section (bolded items are things we do not have but ended up being extremely important).

Game Overview + Table of Contents
Naming conventions and Export Rules
Characters
Shape language
Target Poly Counts for:
- Hero assets
- Repeated assets
- LODs
Material composition
Color language
Art motifs
Tech art and VFX references
Workflow and pipeline
Foliage
- Poly count
- Modelling pipeline and optimization strategies (e.g. Cards)
UI style guide
Colors (Color palette + hex codes)
- Fonts and sizes
- Prior art (with games)

Paintover. Beautiful but very difficult to reproduce in engine.

Art direction experimentation with textures and colors.

2. Providing context when something is requested from art.

Art had a lot of requests come in from gameplay. We structured our meetings and syncs to try and keep artists out of long meetings they didn’t need to be in. However, that created some issues in communicating functionality.

For example, design once needed a ladder from art. Art modelled it and it needed some adjustments to match the intended gameplay. We communicated these changes to the artist and she said “oh, I see, okay I didn’t know that’s how it works. I can make that change.” We realized that an asset is never just “an asset”, the functionality informs how artists model it, and we needed to communicate that more clearly.

If we were to do it again, we would communicate the needed asset and gameplay functionality.

3. The Garden was HUGE. Time management and scope. Lots of art assets were not used. Building the Garden Based on Art Concept, not Level Design.

Early garden concept art.

The Garden was particularly tricky for a number of reasons.

First, it was HUGE at the beginning because we built the initial shape based off of concept art instead of a level blockout. This led to a number of issues. For example, the structures being tall and blocking the camera. It also created issues with accurate representations of space, which led to it being too big. We kept shrinking it, both because of design, but also art realized we would not be able to fill the space meaningfully. Players also didn’t really enjoy having to move around so much!

Second, the shapes and architecture. The combination of the details/ridges, overall shape, color, and repeatedness of the pillars made the entire garden look extremely flat for a long time. We addressed the issue by making small modifications to the pillar models (fortunately we used prefabs, so it was easy to update and replace), and experimenting a lot with textures, normal maps and color tones for the structures and pillars.

Color pass on the pillars.

Texture pass on the pillars.

Third, we struggled with vegetation. The Garden needed to look natural and grown, full and grassy, but too much grass would tank our performance. We tried grass from a bunch of different purchased grass packages and shaders, but a lot of them came out of the ground very strangely, and we didn’t like the shape of them blades. We ultimately settled with using flat 2D planes for the base grass, and using a bunch of small 3D textured planes to make the grass stand upwards.

If we were to do it again, we would:

Start smaller.
Do live testing on the Garden size. This would help us design the space and distances within based on player feedback.
Build the level as a blockout first then let that guide the concept art, not concept the space and build based off of that.

4. Implementation and Set Dressing.

Set dressing became a pain point in Spring 2025, as we didn’t have many artists working in Unity. This stemmed from two problems:

Artists made concept art for individual objects based on level concepts (not blockmesh).
Level Designers blocked levels out with cubes and Unity primitives, not temp models that were an accurate representation of the intended asset (e.g. using a cube with a sphere on the top instead of finding a CC attribution tree and stubbing it in).

These two things in combination, unfortunately, led to a lot of assets being concepted, modelled, and then thrown away. We ended up using a lot of purchased assets in the final game, especially for level assets. Cuboids also made it significantly more difficult for artists to do work early. If an asset is stubbed with a similar asset to start with, artists can figure out relative rotation, object clumping, etc. much earlier. We realized that putting in a tree wasn’t just about putting the tree in to replace a cube. There’s a component of rotation, how it casts shadows on other objects, how much space it occupies on the screen, etc. This led to a lot of manual asset placement and replacement late into development, and art didn’t have enough time to do more than a couple of art passes on levels.

If we were to do it again, we would use free assets from the Internet (or have designers messily model something) as blockmesh, not Unity primitives. This would allow artists then to concept based on tangible designs, and replacing stubbed assets would be much quicker because artists had already done some of the overhead work.

Conclusion

In summary, what worked:

The Wisp is adorable!
Art team faced a lot of challenges, and overcame them by collectively nurturing each other’s talents and skill sharing.
Built and polished hero screenshots.
Good blending between 2D and 3D.

In summary, what could have gone better:

Developing a more robust Art Bible to pin down art style before running into making assets.
Providing game context for assets, to inform artists how assets should be constructed.
Start smaller and build don't build levels based on concept art.
Concept off of block meshes and don’t use cuboids for art blockouts.

Page updated

Google Sites

Report abuse