Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Relic Entertainment has been using the Engines of Play, a method of identifying your audience's motivation described at GDC 2016. What they learned is very much the same as what Jason learned while using those methods at Ubisoft.
[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.]
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.
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!
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.
Mitch: Hey Jason, it was nice getting to meet you down at GDC. Hope you had a good one this year.
Likewise. You have a cool beard.
Mitch: Given that you seemed interested in feedback around our use of Engines of Play at Relic, I figured I’d give you a run-down of how we’ve used it and how it has worked out.
You da man.
Mitch: It’s worth keeping in mind that we are still early on in our production, so we haven’t started adapting your model with a production oriented mentality yet. I’m guessing that when we do, there may be some slight shifts on how we use it to communicate.
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!
Mitch: Overall we’ve found a fairly strong degree of success in using it both as a design lens and as a communication tool for the team.
It came along as part of a larger initiative pushing towards more intent driven design and as a part of a broader design structure shift, so it is a bit difficult to separate its effects from everything else, but it has been called out as a valuable part of the changes.
It has seen praise that extends from our executive level down to junior devs, which seems pretty damn impressive to me.
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.
Mitch: Generally, taste maps have had a stronger adoption than satisfaction maps.
I think that may be partly due to me not having pushed satisfaction maps quite as strongly, so it’s something I am planning on trying to work on (especially because I want to ensure that we have a strong connection to the PENS model on our team).
However, I also think that it is because Taste Maps include a more visual component, so team members find them easier to latch onto and express. Given that, I am hoping to explore some ways to present the satisfaction maps / PENS model in a way that will give people a stronger connection to it.
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.)
Mitch: As our team is not working on a new IP,
(FOR THE EMPEROR!!!!)
we might have had some different uses for it than you on For Honor. Specifically, we went through an early exercise analyzing past entries in our franchise using taste maps and satisfaction maps.
That’s... so... cooooooooooool!!
Mitch: This was part of a larger effort aimed at a reverse / hindsight engineering of the overall creative direction of the franchise. Engines of Play was a hugely valuable tool in this process.
It gave us a strong lens to view the successes of the franchise through. We then used that to base future development off of.
We basically took the franchise maps as a base that we should build on, and used the taste maps as a way to choose targeted areas we wanted to improve. Our output was ultimately an overlay of the two, showing the original franchise maps with our targeted improvements on top.
This also gave us a tool to discuss the scope of both improvements and maintenance (the latter being the amount of work required to maintain the same degree of success in any specific axis in a modern iteration of the franchise).
So basically, if we had rated the franchise has having best-in-class coop in the initial taste-map, we did an assessment of how changes in coop play in modern games would affect our ability to hit that mark.
From there, we would choose specific areas where the past franchise had scored lower and we felt would be strong candidates for ratcheting up the next iteration, based on how feasible it would be to fit into our scope and how closely the different axes aligned with existing creative direction.
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.
Mitch: In the process above, Satisfaction Maps were used in a similar way. We used them to establish where the sense of satisfaction has come from in the past, with the idea that we can use that as a required foundational base.
Basically, it gave us the parts of the game we should not disturb, but should instead aim to improve and build around.
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.
Mitch: Our process of creating our own taste maps saw initial discussions of franchise maps, followed by members of our senior leadership team each creating their own versions of what our taste maps should be. These were then used as discussion drivers in creative meetings aimed at establishing our direction.
We often found that one member of the team would have a significantly different take on where we should target on a specific axis.
This would tend to indicate a very different perspective, which was useful in driving discussion and debate. It also resulted in a large portion of our team having a deeper understanding of our direction and a sense of ownership over it that they hadn’t in past productions.
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):
We caught the disagreements ahead of time, before they could cause much damage (in the form of lost work or game incoherence).
Once the disagreement was resolved, we all had a clearer idea of where we were all going.
Collectively, we had more confidence in our direction, since we all understood why we were targeting that specific feature or experience.
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.
Mitch: Through the process of discussing our Taste Maps, we ran into several tension points where there was disagreement and uncertainty on what the different axes mean.
A lot of discussion, for instance, revolved around the differences and specific definitions of Multiplayer, Solo, Coop, and Combat.
This wasn’t necessarily a bad thing, as it gave our team a valuable tool to align our own definitions of these things. However, our experience was that there was a degree of uncertainty in the specific meanings of the axes, which could result in each team using the model with customized definitions, making cross-team communication a bit more difficult.
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.
Mitch: I have noticed a bit of an issue around the need for more memorable or chunky information from the maps, but I think this is basically solved by what you mentioned around building some player 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! ]
Mitch: I attempted to improve it a bit for our team by breaking out some broadly categorized player types based on our maps, but I think your idea of building more fleshed out characters would work better.
The main issue is just that people sometimes have troubles keeping the maps as a whole in their mind, whereas more chunked info like “George” or “Skilled Builders” is a bit easier for people to grok and use in discussion. So a tool like the personas you described seems like a pretty solid add-on to the existing model based on our experience.
Yup. I wish I had presented it in the first talk. Maybe the next one!
Mitch: A major benefit I’ve found has definitely been the ability for the design team to specify our focus and intent based on the taste maps to other team members.
This has actually relieved a lot of tension on our team related to past projects. I’d guess you may have seen similar things on For Honor, but because RTS games are a bit of a niche it’s helped us communicate much better why specific team members aren’t connecting with our current drives (eg: team members who may be more strongly attached to building and solo gameplay and don’t connect with the game while we worked on skilled multiplayer focused features are no longer uncomfortable with the situation).
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.
Mitch: The TL;DR is that your model is definitely working well for us. There’s some tweaks I’d like to make on our usage around satisfaction maps and getting more digestible player types, but overall it’s been great.
Thanks for going to all the work of putting together your model and process and sharing it by the way, it’s been super helpful for us.
Nothing beats learning that the work has actually mattered to someone else, man. Thank you.
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.
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
