Anyone who has been in the trenches as a designer for a while understands that designers have to have a wide-ranging skillset. In fact, the list of roles that designers commonly have to play in team development efforts is so long that it’s not practical to write them all out. Mixed in all of that are certain key skills that make the difference between mediocre designers and good ones.
Today, I want to focus on forethought. Now, you could argue that almost all design work is forethought in some degree or other; after all, designers are usually a few steps ahead of the team, laying down the roadmap so that other team members know how what they’re doing fits into the larger picture. But, generalizing to that degree loses detail. There are a handful of key dimensions to forethought that designers (and those who hire and manage designers) need to be aware of.
One dimension is the ability to translate from a paper design to a player experience. I had the pleasure of working with Brian Upton (co-creator of Rainbow 6 and lead designer of the original Ghost Recon) while I was at Red Storm, and he was an absolute master of this. Not only could he look at a top-down level map and pick out blind spots, chokepoints, and dead zones, but he could look at a controller layout design and immediately parse what action combinations would be awkward or unintuitive for players. Translating from a description of a system to being able to play the game in your head is a skill. It’s not some strange talent or gift that only certain people have; like any skill, it gets better with practice. Brian had been working on this for years by the time I encountered him, and his critiques of my designs inspired me to develop this skill for myself. I don’t pretend that I’m as good at it as he is, but it has been an essential part of my toolset ever since. Particularly when I was on the publishing side and working with designers in multiple genres on a variety of platforms, being able to think ahead about what the actual play experience was for a design helped me to identify problems early and get adjustments made at the design phase, when changes are their cheapest.
A different – but related – dimension of forethought is empathy. Robin Hunicke gave a great talk at DICE last year about empathy and how important it is when making games that aim to have a real emotional impact on the players. Regardless of what type of game you’re making, empathy is a key part of forethought. When you imagine a player experience, you need to be able to imagine not only your experience as a player but also as many of the different types of players you might encounter as you can. In today’s marketplace, you have to be able to reach hundreds of thousands of people to have a sustainable business. Odds are, you’re going to get every type of player imaginable. The more of those people whom you can empathize with, the better you can understand their play experience, the more likely you can make the game accessible, intuitive, and rewarding for them. As a designer, you’re not designing for yourself (most of the time), you’re not just designing for the team (although that does happen), rather you’re designing for the player. The more you can understand – not just clinically, analytically but emotionally – that player, the better. At a minimum, it can help you identify roadbumps, moments in the game that will strike those players as false or even offensive and polish those out of the experience.
Finally, and I may just be making this term up, there is systems forethought. This is critical when you are making large, complex games like MMO’s that have a variety of interlocking systems, but it is also endemic to most games that have mathematical progressions, whether you’re talking about builders, CCG’s, RTS, life sims, or RPG’s. Individual systems can be mapped fairly easily, but interlocking systems can quickly turn into chaotic models (in the science sense) where small changes in values at one stage of the game lead to wildly variant outcomes down the road. As a designer, you have to be able to think through the I/O process of a variety of systems and identify any runaway dynamics, hopefully before implementation. This is different from translating a design into a player experience or empathizing with your players – although modeling the griefer/exploit type player can help in the process – because you have to look at the system models independent of player interaction. You can get runaway game dynamics from procedural generation or AI as easily as you can from player inputs. Like other skills, it takes practice, repetition, and time to develop, but this can save development teams months of work and hundreds of thousands of dollars in development and testing.
As you might imagine, forethought is something that junior designers are often lacking, but your senior designers – especially the successful ones – know how to do this along a variety of different axes. Every detail that gets implemented into a game has some impact (if not, why are you doing it?), but being able to reliably see that impact ahead of time is an invaluable and essential skill that is a part of any good designer’s toolset.
Are there other aspects of forethought that I missed? If so, feel free to leave a note in the comments.