Engines Of Play Case Study: Relic Entertainment

[Note: This post (originally published at darklorde.com) is all about the Engines of Play. If you are not familiar with Taste/Satisfaction Maps and their uses, the Big 5, Self-Determination Theory, etc, I highly recommend watching this video before reading the article. It will make so much more sense. Like, Oh Em Gee.]

A Random Encounter With Relic

I’m in San Francisco. It’s GDC, so the sidewalks of the Moscone Center are packed to bursting with nerds of every stripe. The day is bright. I cross Fourth street, on my way to Moscone North--and someone calls, “Jason!”

I wasn't surprised--it happens to me a lot at GDC. Stay in the games biz for long enough, and GDC will eventually become one big reunion.

What happened next, though, absolutely does not happen every day.

A friendly-faced fella pushes his way out of the crowd, and introduces himself as one Mitch Lagran, a Lead Designer at Relic Entertainment. While I unsuccessfully suppressed my fanboy reaction (because DAWN OF WAR OMFG), Mitch explains that he had attended my Engines of Play talk last year...

...and that Relic had actually implemented the methods I had laid out in that talk.

He claimed that he wanted to thank me for it because it had made a huge difference to their process and was great stuff. I stared at him and tried to think who had put him up to this.

I mean, no one actually implements that stuff. Come on! That’s not how the GDC works!

The GDC is supposed to be a place where you go and listen to people talking about lessons and techniques--ones that you desperately wish you could apply because wow it would make your dev life so much better--and then you go back to your studio and everyone tells you about how yeah maybe that stuff worked for those guys, but that it won’t work here, see, because our situation is different.

And then you sigh, and maybe you try again in three months. Eventually you just go about your business.

GDC is not where RELIC FREAKING ENTERTAINMENT goes to find whole new process for their game conception phases.

But, here’s this guy, and he’s shaking my hand, and he's expressing his gratitude and his appreciation, and I so I play it cool and say, “Really?! You… actually used my stuff?!?"

He nods.

I ask, "Uh… so, what happened?!”

He told me. Later, he sent me a more detailed description of what the results had been. And what he said blew my mind.

So, I asked him if I could write it up, and share it.

A More Proper Introduction

That’s the back story for what this post is about. Ladies and gentlemen, I would like to present something akin to an actual case study for what happens when you apply the Engines of Play (which includes these charts called Taste Maps, and the process of analysis that goes into them) to a real dev environment.

Hrm.

By “actual case study” what I really mean is “the guys at Relic were kind enough to describe in some detail what they did with the ideas, and what the results were”. That isn’t quite a full case study. It's more like a front-line report or something. BUT STILL. CLOSE ENOUGH.

I mean COME ON! How often does this kind of thing just happen?! Never. That's how often.

A quick reminder: The Engines of Play is a way to figure out what kind of player taste you are trying to target with your game, in a way that is quite a bit more specific than “achievers” or “shooter players”. The methods involved do require a little bit of coming-up-to-speed, but they benefit from being both fairly intuitive and being backed up by systems that have a metric-fuck-ton of academic white papers and research done on them.

Remember all that? No? Well, here's a couple of videos for you.

Good now? Great!

A Conversation With Relic

I mentioned earlier that Mitch Lagran was kind enough to send me a long description of how he and his team have used said Engines. For our purposes here, I think it’s best if I let Mitch speak for himself.

Likewise. You have a cool beard.

You da man.

Prepro: Good

I can tell you from experience that its use in production is likely to simply diminish. Once the key design targets have been set, we found that the model drifts into the “background lore” of the project. It doesn’t seem to be all that useful during the meat of production.

We did find that near the end of production we experienced a brief resurgence in interest in the work. As we prepared our communication plans, and as the game was starting to come together, there was a storm of new conversations around confirming whether or not we had built what we had intended to build--and Taste Maps are great for that.

At that point, too, there were a lot of new people coming onto the project who had not been exposed to the method, and both found it surprising that we had done all that work so far in advance and found it surprising that it seemed to work.

So: high use in preproduction. Low use during production. Brief flurry of use right as the launch plans are being discussed in earnest for the first time. That was our experience, anyway.

I look forward to learning whether or not your experience turns out to be similar!

Broad Appeal

I know, right?!?

That was the part about this approach that surprised me the most—that so many completely different groups of people involved in the production found it to be useful.

I originally designed the approach as a tool for designers, and expected that the sell would be a hard one with the marketing and business teams. But we found quite the opposite to be true! The biz people were enthusiastic, and (in my experience) already prepared to look at our game through this lens. Instant adopters.

I am psyched to hear that this might be a repeatable phenomenon.

Satisfaction Is Hard

I found the same thing. I think there are many complicating factors here.

Here's one: I found that discussing satisfaction is just harder than discussing taste. My theory is that because its effects are so much more remote than the immediate-gratification of taste that most people are simply under-prepared to think about the whole concept. I know that I was, and that it took long years of effort to really get the feeling for how satisfaction works. It’s still a work in progress for me, in fact.

That said: wow is long-term satisfaction important. I have come to understand that if you make a game that only offers short-term taste satisfaction, that people will play it for 30 minutes and then never come back. The core three satisfactions of Self-Determination Theory / PENS give us the reasons why people will come to believe that your game is worth spending some of their precious time on this planet on.

It is tricky to think about. But learn it: the success of your game depends on it.

(I agree with you about the part about the visual component for SDT kinda sucking. I think the way I laid out satisfaction maps was sort of a cop-out, and deserves a better approach than just “fill in these three boxes”. We’ll see if something better can be developed.)

Brand Analysis FTW

(FOR THE EMPEROR!!!!)

That’s... so... cooooooooooool!!

I am so impressed by this. I had some vague notion as we were working on this that you could maybe apply taste maps to genres, or something, but I never investigated it. What you describe here, with taste map overlays (overlays!!) frankly seems so obvious now that you’ve explained it that I am going to just adopt it into my design process.

I also adore the idea of re-evaluating the viability of your features through the lens of “are we still best-in-class?” during pre-production. That sounds to me like a process that literally everyone involved in production could get behind, understand, and participate in.

Good one, guys.

Brand Satisfaction Is Stable

It’s funny, right? Satisfaction theory (SDT, etc) is so damned important, but once the core pieces are in place and working (which, if you have made a successful game, must be true), you can then largely rely on them.

Building a game with a high opportunity for mastery, or with extensive customization and self-expression options, or with strong social systems that give the player a clear idea of where they stand in the community—these are things that players will always want, in some form or another. So, you’re right: if that part ain’t broke, don’t fix it.

That said, if you discover in your analysis that one of your three satisfaction pillars is a tad weak, then a new version is a perfect time to shore that up. It will always pay off, if you can execute on those features well.

It Brings Out Disagreements Early

I’m going to go ahead and state that I think you have hit on the #1 most valuable part of integrating this tool into a dev team’s process.

What happened for you is exactly what happened for us. And, resolving those differences and disagreements about what we were shooting for (years in advance of the game’s release!) produced several key things (some of which you mention above):

Having the why in place well ahead of ramping up for production meant that when we did go wide and started working on everything at once, our key leadership all were very clear about the vision and the goal, and in a way that was easy to remember.

It is difficult to measure how valuable this was. The effect of that knowledge would be that we would not need to have as many discussions on this topic, so how do we measure the impact?

Still, my experience on other projects tells me that it mattered quite a lot. Since we already understood the goals, we didn't improvise quite as much. I believe it was a huge part of our success.

Some Axes Are Unclear

We found similar problems, and sometimes around the same axes. I think those ones could use a naming update.

If I were to approach that problem today, I might do something like this: Crowd <—> Alone (NPCs don’t count, only real people), and Together <—> Against.

I’m not 100% sure that this would resolve the problem. But that’s how I see it today.

Would Be Great To Have Personas

[ Reader: The context for this is that there is one part of the whole mapping process that I didn’t find a good way to explain in my GDC talk (given the time constraints and the amount of information I was already downloading onto my audience): player personas.

What we did (in brief) was to take our taste maps and then generate four imaginary players that covered all of the most extreme tastes in our chart (by simply placing four dots on our map, one dot per Domain, in the furthest corner of the taste zone). We then generated some basic demographics about who they might be.

At that point, we could use those personas as a more accessible way of talking about what the maps meant in terms of real players.

So... I shared this info with Mitch on the sidewalk at GDC when he mentioned some of the challenges he had faced using the system. After I got done explaining the missing link, he looked at me...

...and for a minute I thought he was gonna punch me or something. Like, “DUDE. WHY DID YOU NOT MENTION THIS IN YOUR TALK.”

But then he smiled, and said something like “Yeah! I bet that would do it!” and moved on.

He didn't punch me at all! Nice guys, these Relic people! ]

Yup. I wish I had presented it in the first talk. Maybe the next one!

It Reduces Team Tension

Yes! Yes, yes, yes. And, furthermore, YES.

One of the hardest moments to get through smoothly in game development is the moment where a dev who is working on a feature says “well, I don’t even get why we’re making this. I mean, players want <the opposite of what the feature offers>, not <the thing the feature offers>.”

Awkward.

Because what do you do? At that moment, your team member is not asking to be educated about the broad variety in player tastes, and probably has been simmering on this gripe for quite a while! It’s a moment that is fraught with peril for a team culture…

…and having the taste map to refer to is an amazing method of short-cutting the assumption of unanimity among players that is the core problem there. The chart demonstrates in clear terms not only that variety exists on these spectra, but what the positive opposite of your personal taste actually is.

We found exactly what you have found: a team that understands the broad variety of their player’s tastes can work more smoothly, because then your personal taste doesn’t have to be treated as though it were right or wrong.

Seems Like It Works

Nothing beats learning that the work has actually mattered to someone else, man. Thank you.

Conclusion

What is so amazing to me about Mitch’s commentaryand his team’s experience of using the tool is how precisely it mirrors our own experience. It would be one thing if the tool simply worked as designed, right? But here, what I see is that the exact same follow-on effects have developed on his team.

The increase in clarity and commitment. The broad acceptance of the tool as valuable. The decrease in tension.

These appear to not only be effects local to the For Honor team. Once is a fluke, but twice is maybe a pattern.

If the deployment of the Engines of Play into a project can produce those kinds of effects even just more often than not, then that goes a long way towards demonstrating that maybe it isn’t just a pretty model.

I’m excited to be able to make the claim that maybe it’s actually a good idea, and to have some data to back it up.

Thanks, Mitch, for taking the time to share your team’s experience. Thanks, Relic people, for letting me write this piece. And thanks to all the amazing devs at Relic Entertainment: congratulations on a huge launch. I look forward to enjoying your games for many years to come.