On Teamwork
Most of my game design experience prior to this project was solo development on digital games. I would implement a feature in my game, playtest it, think about how I felt about it, and use my reflection to implement new features.
However, this was my first time making a game as a team, so I have a lot of strong thoughts on the experience. Most notably:
- Pros
-
- Working on a team really covers your blind spots. After playing hundreds of hours of various card drafting games, my perspective of what a good card design looks like and what good drafting mechanisms look like is heavily skewed, and I’m grateful that I had a team that was willing to keep me grounded and object to my ideas. For instance, I remember I wanted to model my card design after games like 7 Wonders or It’s a Wonderful World, which featured stackable resource cards that help players understand the game state at a glance. However, I encountered opposition from my team since they felt that this type of card design would interfere with the game’s learning goals, and that’s great! For instance, Mayshu wanted players to be able to see the art of the meals they were building, making the game more immersive and educational.
-
- Diversity. The word ‘diversity’ definitely suffers a bit from semantic satiation, but it truly is important. For instance, some members of our team had less experience with some tabletop gaming conventions, like drafting, and this ended up being a good thing. To clarify – we initially had a pair drafting system, similar to Cascadia. This type of drafting is familiar to people that have played a lot board games, but for people that have not, it can be a bit of a hump to get used to and can hinder the reinforcement of our learning goals. Because of this, we spotted the encumbrance early and changed the rules to something more intuitive. Relying only on yourself or people similar to yourself can trap you into narrow design spaces or bias you into certain ways of thinking.
- Cons
-
- When developing as a team, suggesting ideas can involve walking on eggshells sometimes, where you have to think about the social ramifications of what you say – you don’t want to undermine other people’s ideas if they spent a lot of time considering them. Sometimes, for microdecisions in game design, a developer might feel that keeping smooth coworker relations is more important than preventing suboptimal game design decisions from making their way in, which can accumulate and is a bad idea in the long run. By contrast, in solo development, there are only good ideas and bad ideas, with no social strings attached.
-
- I was really struggling with how much slower the iterative design process was when working in a team. When I have an idea in solo development, I can just implement it myself, try it out, and see if it works. But in a team, you have to verbally pitch the idea to people whose vision for the game is different from your own. Sometimes difficult decisions are settled by a democratic vote, which can lead to safer and less ambitious design and isn’t usually correct for creative works.
Ultimately, this was a really valuable experience for me. I learned a lot about playtesting and prototyping. Usually, the first prototype isn’t very fun, but you can tell what’s good and what’s bad about by watching your playtester’s body language. What parts make them look bored? What parts make them lean into their chair or get excited? This was a skill I felt like a picked up, and I’m really excited to put this into practice for future game projects. Perhaps the most satisfying aspect of this project for me was when Cole told our group that she felt like she now understood how to actually assemble more balanced meals – it was as if the results of our playtesting and ideas had come to fruition, and I was truly grateful.
