Parting Thoughts

Lessons Learnt and Reflections after a Year-Long Thesis by Sammy Chuang

Going into my thesis year, I was petrified of two things:

Delivering the damn project. Historically, I felt like a lot of projects I'd been on had failed because of my inability to deliver. I felt I'd done more harm than help.
Leading the team. My ultimate goal was for everyone to come out having a project they would be proud to put on their portfolio, and to have fun along the way.

These fears stemmed from lack of confidence, and historical struggles on past projects I'd been on (prior to my own thesis, I'd contributed to Metamorphosis: Thyota's Journey, Starweave, Pig & Chikin and Oopz Oofs).

Those fears turned into two major learning experiences for me:

Learning to work with those who don't have the same work style as myself and, in essence, "let 'em cook".
Learning to trust my intuition.

"Let 'em Cook" -- Learning to Work with Various Communication Styles

I owe a lot to my fearless design lead, Bernice Wang. We had quite a few disagreements and difficulties working together in preproduction, but I've also come to believe that our most difficult collaborations are our greatest learning experiences.

Bernice and I come from drastically different backgrounds, and that impacted our ability to get on the same page. For a little context: they come from a dance and performance art background, whilst I come from a technical design and engineering background. Our biggest source of miscommunication came from this, we'd often be discussing one of their ideas, or they've give me a piece of documentation, that was beautifully written, emotional and expressive. However, as an engineer, I had a hard time visualizing it and understanding what I was being asked to implement. We faced these challenges head on, and Bernice and I put a lot of care and time into resolving our challenges. We picked up a number of communication methods including mirroring, paper prototyping and slide decks. Despite all of the difficulties we faced, Bernice has become one of my most trusted collaborators and I greatly respect their dedication to design and self improvement.

Additionally, we learned that our various backgrounds served different parts of the design and development process. Bernice was able to use their strengths to set emotional tone and experience across both the entire project or a single area, whilst my skills came more at a translation level. Taking ideas and poetry and turning it into something tangible.

Learning to Trust my Intuition

I had a lot of doubt about my ability to lead a team. Due to that, I tried to take as objective as possible an approach to every single decision I made. This meant using playtest data to decide the direction of the project. I started leaning too much on statistics and playtesting to drive decision making. There were times I actively went against my intuition if it wasn't supported by the data, and the project suffered for it. It really came to a breaking point that it felt like the project was being torn into several different directions (See "Wind or 'The Wind'?" for more details, as this was the breaking point). I have to really thank one of my industry advisors for both helping me understand why the project felt like it was getting split, and helping me navigate get the project back on track and cohesive again.

I learned to use my subjective intuition as the objective metric of which a project's current ability to achieve its goals was measured against.

That's a lot of fancy words, but basically: I learned how to use my intuition to shape the creative goals with which the project should follow, whilst using data to show whether or not those goals were being met. I stopped using playtest data as the way to determine the creative goals of the project (if you're doing that, it probably means you have a weak concept, and you as the director don't know what you're trying to communicate). This tumultuous time helped me to become more confident in making decisions, and I think that showed for the project going forward.

I learned that it's okay to make decisions based on your intuition. After all, the director knows the project the best, and your team will understand throwing away work as long as you, as the director, are honoring the goals you'd previously set out to achieve. Because, after all, if the director can't speak for the voice of the project, then who can? This isn't a free pass to change your mind on a whim, but just know that it is okay to express when you think the project has gotten off course to get it back on track.

Things that Went Well

This section is a mix of notes from the team's post mortems (each discipline held their own) and my thoughts from the year.

Excellent Team Culture. Just a Bunch of Friends Making Something Cool Together

Without a doubt, the team social culture. I spent a lot of time with the team, building up good social culture, and supporting each person individually. This is where I think my past experiences on projects also came to play. I was lucky enough that many of my past collaborators reached out when they heard I was embarking on my own thesis journey (one even said to me: "I knew you'd have to do your own thesis eventually, I've been waiting two years for this day" (I cried afterwards)). So fortunately, the core team was just a bunch of past relationships I'd built and become friends with over the years.

Additionally, I'm someone who loves spending time doing hands-on work, and spending time in engine. This naturally led to me dedicating a lot of time to the team and all of the volunteers. I spent a lot of time in particular with engineering, art and design. Engineering because I come from an engineering background, art because I was the bridge between art and engine, and design because The Wind and the Wisp is generally a "design-foot forward" project.

I've also always been super passionate about getting to know my team members well, and finding ways to both utilize their strengths and provide learning opportunities to areas of interest. I've come to learn that this is a particular strength of mine, not just saying "oh hey, thanks for doing this thing" but instead saying "oh, hey, it's cool that you did this thing in this way." I've found general curiosity for why people do things a certain way is not only where I've picked up most of my technical knowledge, but also contributed to making people feel heard and appreciated for their craft and goals, not just their output.

Additionally, when building the team, I looked more for enthusiasm and ability to integrate with the team's positive values. Hard skills can be taught, a positive attitude towards challenges and treating others with respect cannot. I wrote a set of Team Pillars and showed it to the project's producers to make sure we were always being held accountable for them.

Read the full "Production Pillars" here but in short, they were:

Compassion and Respect
Communication
Ownership and Constructive Feedback
Healthy Work/Life Balance!

Excellent Communication and Collaboration

A little bit related to the first point, but distinct enough to be its own section. I believe that the team had some of the best communication and collaboration that I've seen on an MFA thesis at USC. The entire team shared aspects they really enjoyed about the positive communication and collaboration on The Wind and the Wisp.

The team collectively nurtured talent and learned from each other. A lot of people would post to the Discord asking for help.

Wholeheartedly agreed. People were not afraid to express praise, or confusion and feedback. Art and engineering particularly got very good at communicating with each other. People would often post questions to Discord ("hey, having trouble exporting the rig, any thoughts?" or "the save system is throwing an error here, anyone have experience with this error?"), and there was always a palpable hype in the air when people posted videos/screenshots of new assets, or completion of new features!

Feedback was always clear and constructive, with minimal sugar coating.

Big plus one from me! I remember very clearly, one engineer said: "I found several calls to functions like FindObjectsOfType<> and FindGameObjectsWithTag in the code this week - these work ok but the issue is they look through every single object in the scene (THE GARDEN 😭🙏) when they’re called, so i would recommend avoiding them esp during update loops that run every frame :0". This simple piece of feedback was clear and objective, with easy actionable items (avoid these functions, and we should look into removing existing calls to them)." This wasn't the only instance of such feedback, but it was one that stuck out to me very clearly of minimal sugar coating, whilst being clear and constructive.

Fast iteration on processes.

A core moment in the project to me was when the engineer Emma told me she was frustrated she didn't know what design was doing. Oftentimes there would be a request from engineering with just the "what", no indication of the "why" and "how" it would happen in game. I learned how important it was for people to understand the context of their work, because it would impact the way they approached implementing it. We quickly experimented with pivoting to pod meetings, instead of discipline meetings, and it was really positively received. It led to clearer communication and expectations between design and engineering in particular, and I think people grew closer due to that as well, since they were getting more exposure to the other teams.

Commenting and documenting code, and lots of check-ins!

Historically, I'd been an engineer or engineering lead on a lot of projects. Along the way, I picked up a lot of lessons on how to lead an engineering team in particular. In school, "engineering" can kind of be a nebulous discipline. It can mean a lot of things, and it's super important to get clear about what is expected from an engineer. Engineering was probably one of the most efficiently run teams in the project. See here for a deeper dive on what running the engineering team for The Wind and the Wisp looked like.

Worked Extremely Fast and Very Iterative. "Scrappy"

We always worked extremely quickly. We had fast turnaround times with implementing changes, and playtesting them. I like to say we were very "scrappy". Even those who were less technical found ways to communicate and playtest, which was a massive win-win: they'd get feedback they needed immediately, whilst also buying them a little more time to slowly work through the implementation. Because of our "scrappy" approach to testing and building, work got done, tested and iterated on on a day to day basis. The project was constantly evolving and playtesting. One of the most validating pieces of feedback was around April, 2025, when one tester said "I can tell you guys really playtested this a lot, even amongst yourselves."

Things that Could have Gone Better

Scope

As is the nature of game development, and The Wind and the Wisp fell victim to the scope cut. The design lead Bernice Wang and I sat down in late February (right after we hit sequence complete) and gutted the game. Fortunately, everyone took it well, however, it did mean the entire Calendula level did need to be cut, we had to find places to use music that had already been composed and recorded could be used, some already completed art assets had to be thrown away, and most importantly, we had to redesign a large part of the Garden's level design/flow to adjust pacing issues that arose.

Cutting scope helped us to cut off about 1 month of development time, however, it led to a lot of chaos and crunch for the first two weeks after the cut, because most teams had a little backtracking to do and cleanup related to the cuts.

If I were to do it all again, I'd be a lot more aware of how cutting scope doesn't just mean chopping a single level, but it ultimately changes the pacing of the entire game. Cutting scope isn't the hard part, it's adjusting all of the content that remains that was reliant on the cut material. Overall, removing levels and segments from the game did cut the overall scope, but it bloated it in other areas that we didn't account for.

(Aside: I'd love to say "if I were to do it all again, I'd scope appropriately", but this answer feels unrealistic and naive. Ruthlessly cutting scope was a healthy part of our experience. I think seeing the entire game as we originally wanted at a blockmesh level showed us that our intended design didn't even work. Our scope cut helped get the game into a much healthier place from a player perspective. It felt more balanced and like an overall enjoyable experience. So in my eyes, "scoping appropriately" isn't really an answer to the question of how to avoid cutting scope. If anything, it's more of a lesson in seniority and experience designing games, but that isn't realistic for a student project. Being totally truthful, I'm even a little skeptical about if seniority can address designing a well-paced game without the need for scope cuts. But who knows, this might be a naive answer as well).

Bernice and I sat down for nearly three hours and ruthlessly gutted the game!

Risk evaluation exercise that helped us realize... we needed to cut a lot.

Clearer "Why" When Assigning Work

Similar to one of the points above, but it could have been taken a step further. I kept the teams separated and abstracted from each other, especially in the first half of development, mainly to try and reduce information overload for irrelevant parties. However, engineering pointed out it led to implementation challenges because they were unclear how the big picture fit together. Later on, during the Art Post Mortem, a couple of artists mentioned they wished they understood what was going on in design or engineering world more. It would have both helped them understand the requirements for assets they were making, but also see how their work fit into the entire game as a whole.

If I were to do it all again, I would have bi-weekly build reviews for the entire team, in which everyone can join and watch someone play through the build (we did this on a leads level, when we realized leads were not always on the same page about the current status of the project, but it should've been opened up to the entire team).

Slow to Pick up Momentum

We rushed into production. Summer 2024 was technically our preproduction phase, with production starting in September. That wasn't true, and we spent a lot of time in the autumn saying we were in production when in reality, we were still ironing out core design issues. It was around December that we finally settled on a direction (to focus on mechanic and building a relationship between the player and Wisp, and move away from narrative/storytelling) and the team was finally able to start picking up momentum. Production became significantly more predictable after December, because we finally understood what we were trying to make, and therefore could feasibly understand how long it would take.

I think I rushed us into production, because I was eager to make sure we were on pace to finish and say we were hitting goals/deadlines we'd previously set for ourselves. In reality, it led to an awkward situation where some teams were ahead of others, and being "in production" led to a strange mentality at some points of "this is the way things have to be, we're in production, we can't go back on it now." Fortunately, as a student project with no real stakeholders, we could kind of ambiguously float between production and preproduction for a few extra months.

If I were to do it again, I'd be slower and more patient during preproduction.

Parting Parting-Thoughts

Now that the thesis year has ended, I've spent a lot of time reflecting on challenges I knew would arise, and how I overcame them. I'd like to speak really briefly to lessons I didn't anticipate learning (both positive and negative), but have nonetheless come up and I hope to bring to my future projects.

Nurturing and Motivating

Something I learned about myself is my strength is with people and understanding them. Not just encouraging and appreciating them, but my curiosity for why they do things a certain way is where I've acquired most of my technical knowledge, and I've found it's actually the best way to support their work. Instead of saying "hey, thanks for implementing that!", I tend to say "hey, it's really cool you implemented it that way, that's really clever because xyz". It helps people to feel appreciated for their work, and understood, and not just like a statistic in the list of work that needs to be done. This also increased people's motivation to complete the project. We focused a lot less on individual tasks and nitty gritty task tracking, but instead had a clear vision of where we needed to go, and used collective intuition to understand when we were and were not moving towards the correct goals.

I also spent a lot of time with a lot of members on the team, particularly those that were solving really challenging issues in unknown territory and the leads. I am very nurturing, and like spending time with people to understand their strengths and how to help them achieve their goals. This was my absolute favorite part of my project. I got to know everyone really closely, see what drives them and how to draw out their best qualities and work. I would say it was really successful, particularly with engineers and artists, many of whom which I've become close friends and would collaborate again with in a heartbeat, because of a mutual trust and support I've built with each of them individually.

Deferring (to Leads) -- You Don't have to Carry Everything Alone

This one was a hard one for me personally, and is something I will need to continue improving on as I step forward into my career. I have a tendency to solve every problem on my own, take on difficult conversations on my own. My thought process is "oh, this will be a tough conversation, I don't want so-and-so to have to deal with it or the repercussions. I will handle it on my own." At the end of the project, the leads and I all got together and I opened up about some of the interpersonal hardships I'd had to navigate with difficult conversations, and all of them, without fail, said "I wish you'd told me! I would've helped and supported that situation!" It was a really helpful reminder to me that leads are a team of people you trust not just with leading different disciplines in the project, but to help managing individual team members.

Setting Boundaries and Over Accepting Blame

One thing I struggled with a lot was setting boundaries and over accepting blame. We had a few conflicts come up in situations that I was not clear and expressive enough about boundaries. My lack of willingness to set these boundaries ultimately hurt the project and workflow. It led to me taking on way more work than I should have, and therefore s

Flexibility in Thought Process

I've noticed I'm extremely flexible in my approach to doing things and willing to try, but not so flexible in my thought process. There were a few occasions in which we encountered an issue, and someone suggested "why not this way?". I'd immediately reply like "oh, this probably won't work because xyz" and we'd discuss it a bit, I'd try it the way I thought and it would fail. Then we'd try someone else's suggestion and more often than not, it worked. Fortunately, we still always found solutions to the issues we encountered, but if I'd been more flexible in my fundamental thought process, we could have avoided doing things my way first, and just gotten straight to the conclusion.

To anyone reading my ramblings! Thank you for reading! <3

And as a final thank you, I give my entire heart to everyone who contributed to The Wind and the Wisp. Thank you for trusting me and believing in the project. Thank you for letting me be your director <3

<3 Sammy

Page updated

Google Sites

Report abuse