Nine Dev Log #2: Design Research

In 2015, I attended a Boston Post Mortem talk by veteran developer Steve Meretzky. It was jam packed with great advice, but one bit that stood out to me was that a good designer strives to be an “overnight expert”.

The concept is fairly straightforward: game designers have to make countless decisions that impact the player experience. The more context a designer has, the more informed those decisions are. And one way to gain this context is to prioritize design research in the early stages of development. I have come to believe that good research can significantly increase your chances of designing a successful game.

NordicResearch
Members of the God of War team on a Nordic Research Trip (photo from “Raising Kratos”)

Designers at large studios may have great resources for doing design research during pre-production. For example, Sony Santa Monica funded a small portion of the God of War team to go on a “Nordic Research Trip”, to countries in the Scandanavian region.

But as an indie, my options look more like:

  1. Play reference games in the space.
  2. Research the subject matter.
  3. Learn from designers in the space.
  4. Learn from the potential audience.

Note that when I say “the space”, I’m referring to the “design space” surrounding the game. This can be very broad, but for the purposes of this post I am going to focus on learning about gameplay systems in the roguelite and platformer genres.

#1. Playing Reference Games

Much of the reason Nine has evolved into a roguelite platformer is because of my past influences. On the platformer side, I grew up playing classics like Sonic, Mario, and Donkey Kong series, and am familiar with some of the modern takes such as Celeste and Hollow Knight. On the roguelite side, I’m a big fan of some strategy games like Into the Breach and Card of Darkness, as well as some action games like Cadence of Hyrule and my primary reference: Spelunky.

But there’s so much more to learn!

In the coming weeks I hope to play:

  • Games that combine roguelite and action platforming elements. This is the core focus area and includes games like Dead Cells, Rogue Legacy, 30XX, Noita, and Catacomb Kids.
  • Popular games with roguelite elements (Crypt of the Necrodancer, Slay the Spire, Roundguard), which can teach me about procedural generation, progression systems, difficulty pacing, and more.
  • Popular action platformers (Ori and the Blind Forest, Cuphead, Guacamelee 2), which can help me make the player feel like an agile warrior cat.
  • Notable flops in the above genres (critically and commercially), so I can learn what mistakes to avoid!

It’s worth mentioning I don’t have the money or time to buy and play all of these games. But I can at least play through the early parts of the best ones, and watch streams and reviews of the rest.

In a future post I will round up some of the more interesting takeaways from my focused play research.

#2. Researching the Subject Matter

I did some research on cats and the “nine lives” concept, and went into a rabbit hole about the significance of cats in various cultures throughout history. It was a fun thematic exploration!

Bastet-MET
A statuette of Bastet at the MET Museum.

 

But I’ll save the details for a future dev log about theme. Let’s move on!

#3. Learning from Designers

There is a wealth of knowledge from game developers who have made roguelites and/or platformers in the past. This information has been dispensed through design blogs, youtube videos, GDC talks, interviews, podcasts, and more. Why should I reinvent the wheel?

SpelunkyBookCover

The biggest and best reference so far would have to be the Spelunky book by Derek Yu, which dives deep into both the personal story of creating Spelunky and the design challenges Derek faced. It surprised and inspired me to learn that relatively simple algorithms could create such rich emergent gameplay. It was also humanizing to see that even a legend like Derek had real struggles dealing with conflicts both personal (like parting ways with Alec) and professional (like dealing with varying player response to Spelunky’s difficulty and randomness).

There are also some great youtube videos on procedurally generated levels by authors like Extra Credits and Mark Brown, but they are mostly a higher level overview of what the Spelunky book covers. Still, it’s handy to see how these authors chunk complex ideas into accessible presentations.

Finally, the podcast The Spelunky Showlike has been a wonderful reference. The show is rooted in pure love for Spelunky, and they use roguelites as a lens to which to discuss game design. The result makes them feel like a team of allies in my quest to understand the design space. I trust that they “get” Spelunky, which means the discussion can focus on the challenges of making those games shine. They have also interviewed designers of notable roguelites like HoledownCard of Darkness, and Roundguard.

#4. Learning from the Potential Audience

The potential audience is the theoretical group of people who might enjoy the game.

A good place to start is with the audiences that already exist. These might include people who enjoy specific games on my reference list or love the loosely defined genres of roguelite or platformer. It makes sense to try and win them over, since there is clear overlap in gameplay systems. Such audiences may also include people who appreciate lighthearted cartoony aesthetics, themes that don’t take themselves too seriously, and action without excessive violence.

But an existing audience also comes with expectations. A roguelite fan might expect the deep progression systems of Dead Cells or the emergent physics of Spelunky. A platformer fan might expect the tightly designed rooms of Celeste or the big roller coaster moments of Sonic. I’d like to win these people over, but there’s also a part of me that needs to accept that Nine is its own unique game that doesn’t fit neatly into those boxes.

To learn from these audiences is to find them, talk to them, and most importantly listen to what they have to say. Even when they’re not articulate, their experiences are just as valid. And the good news is that their expressions of opinion can be found everywhere: in reviews, youtube comments, discords, and more.

Much harder to find is the theoretical person who wants something just like your game but:

  1. Doesn’t know it yet.
  2. Knows it, but doesn’t know how to ask for it.
  3. Asks for it, but is ignored. (<- Actually this is the story of some memorable crowdfunding successes).

I can’t talk to this nonexistent portion of the audience just yet. But I look forward to it very much.

Conclusion

It’s tricky to make time for design research. And it’s hard to prioritize in the early stages especially when you are still rapid prototyping. But I think that if you are trying to maximize the chances of making something great, you really want to immerse yourself in the space and strive to become an “overnight expert”.

I’d hardly call myself an expert of course, but the research I’ve done has already helped frame my iterative goals. I have a better idea of what kinds of problems I’m likely to run into, as well as a larger toolbox for solving this problems. And the immersion has reinforced that I love living in this design space.

I’ll be back soon to report what I’ve learned. Thanks for reading!

Scoping Smart

Whether you are a designer, producer, artist, or programmer, scope dominates game development. It drives decision-making on every scale, makes or breaks production, and defines the relationships between team members.

I find scope, and how we deal with it, fascinating. For the purposes of this post, lets call an the act of dealing with scope “scoping”, and someone who pays attention to scope “scope-minded”.

Scope and Timing

Attention to scope is primarily dictated by production schedule.

Being too scope-minded in the early stages or a project can be stifling to creativity. It can lead you towards safe decisions and prevent you from thinking outside the box. This is why a common rule in brainstorming is “no ideas are bad”.

Yet as we all know, it only takes the blink of an eye for optimistic blue sky dreaming to turn into nightmarish overscoping. It’s an easy trap to think “the more we can stuff in for the deadline, the better”, but refusing to trim down often results in a lower quality product that lacks focus. In addition, poor scoping can lead to crunch and taking shortcuts, creating new design and technical problems down the road that end up costing more time than you saved.

The key here is to not stress out from constant changes, and to recognize that scoping is a reality of game development.

That’s not to say consistent underplanning shouldn’t be addressed, but attempts to force-fit a waterfall production into what is by nature an iterative task, misses the point. The better solution is to facilitate the iterative process. (“Facilitating iteration” is a massive topic on its own, so I won’t go there today.)

In healthy teams, what emerges from this reality is a rhythmic ebb and flow that feels a little like breathing. The ideal is to breath in, absorbing all the ideas and possibilities, keep what is essential, then breath out the excess. It’s never perfect but you keep at it and improve with practice. This rhythm is happening on every scale – for the full project, for each major milestone, and for each sprint.

Scope and Roles

Attention to scope is also dictated by your role in a team.

Designers lean on the side of pushing scope. They want the best game possible, so they are incentivized push scope to the edge of possibility. But this is a delicate dance, because an overscoped design will just result in a worse overall product. I imagine that many creative directors (or other stakeholders with creative input) have very little grasp of scope, and rely on producers and programmers to rein their vision in. But the most effective and versatile designers are constantly balancing an open mind with an eye on scope.

Programmers tend to be be the most scope-minded on a task-to-task basis. They are the most invested in keeping the foundation solid, and will most directly dictate the production timeline for a feature. Programmers may still be ambitious and may get excited by designs (after all if they’re here, they love games), but the best ones seem to always push for doing things the right way.

On larger scales, designers and programmers can only advocate for changes to scope. Someone has to make the tough decisions, which brings us to production.

In a small company, production wears multiple hats. A single person can be CEO, producer, creative director, and manager all at the same time. With so many responsibilities to juggle, all they can do is listen to the different opinions from the team, take into account their own instincts, and make decisions on a case-by-case basis. Key to success is being an all-rounder that lives in all aspects of development.

But as a company grows, production roles become more specific, and eventually someone’s primary role becomes “scope police”. In the worst cases, this can result in fiery battles between teammates and disastrous stalemates. But if the team members in these roles have chemistry, you can get a healthy role-driven push and pull.

For example: Suppose a Lead Designer identifies an issue with the design and pushes for a big change, only to get a no from the Producer. At this point the LD can choose to push for a compromise, or harder for his/her way. Meanwhile the Producer can choose to continue pushing back, or give-in after some time.

With trust and respect, both parties will pick and choose their battles carefully, resulting in a much higher quality game that neither balloons out of scope nor corners itself into major design issues. The process might sound exhausting but it can actually be liberating; the LD is free to be more creative and trust the Producer to rein things in, and the Producer can be more conservative and trust the Lead Designer to push for what really matters.

For me personally – as a designer/programmer hybrid in a small company – I find myself juggling hats. The programmer in me always wants to scope down, while the designer in me wants to consider every avenue. And while I don’t have decision making power on the very high level, I find that this dual mindset is invaluable to bridging gaps between team members, some of who live on extreme opposite ends of the scope-mindedness spectrum. And luckily for me, I enjoy the challenge!

Applying Scope to My Life

As I am constantly immersed in scoping, I can’t help but be scope-minded in my life outside work.

Some ways I am scoping down right now:

  1. I will steer away from large scope blog post ideas (like the “Feedback Loops” series), and focus on off-hand thoughts for the time-being. Occasionally I might write a long post organically (like this one).
  2. I almost started a side game project with a friend, but realized very quickly that it was drawing time and energy from my main work, so I am shelving it.
  3. I will focus my research and learning a bit. In addition to critically playing games, and my daily habit of reading articles/listening to podcasts, I want focus on developing my systems design toolbox.

Soon enough, it will be time again to reevaluate my goals and start dreaming up the big blue sky for my free time. But perhaps – like in game development – this is all part of a natural ebb and flow, and I just need to let myself breathe.