The BEM way. An overview to our method. Part 1.

For those who know me, I have more the spirit of a researcher than the soul of a businessman. I love Google Scholar to get the knowledge to continue improving on my work and I'm constantly amazed with all the deep knowledge that comes for free, if you know where to find it. YouTube channels like SciShow, Veritasium, VSauce, Gamer's Toolkit, Extra Credits, all PBS Studios shows and so on are an incredible source of knowledge and have helped me form the idea of Gamification I want to vouch for. So, using the holidays as an excuse, I want to delve a little bit into my method of Gamification, so other people can build upon it and create even better stuff. Of course, this will take me a couple of articles, but each one will be self contained (but expect the cliffhanger, of course).

In my last article I wrote about my history with Gamification and what I think it should stand for. Gamification should be about learning through gameplay and exploration, not about following tasks to get carrots. So let's always keep this in mind. Now, BEM is an acronym, which stands for Behavioral-Experiential-Meaningful gamification. This comes from different types of gamification systems and its evolution, but it also became an internal metric to evaluate our gamification designs. And metrics create goals, and the goal is the game. So let's begin there.

To us, a great Gamification program must achieve three things:

Behavioral:

It doesn't stand for creating behaviors, in a skinner box way, but for creating the conditions so certain behaviors could emerge, avoiding nocive ones. It's about using subtle informational queues to lead the players' way, without holding their hands too much. I use the game master vs puppeteer metaphor to explain this: a game master nudges their players in the right direction so they can take advantage of everything she has design for them. The players want to gamble in the Inn instead of going to Mount Shar, where the goblin king is? The Game Master can create a dark figure in the corner of the inn, who turns out to be a goblin which robs the innkeeper and runs toward his lair (cliche? maybe, but effective nonetheless).

This could be enough to nudge behavior in the right way, but the players' actions are still their own. They want to go right away in their horses? Fine! They want to wait for the next day and rent a chariot? Perfect! Players usually don't like to feel lost in the campaign, but they don't love to be overly directed, by for example, creating a portal from thin air that engulfs them and sends them to the mouth of the mount against their will (the puppeteer way). Here is where Behavioral Economics can shine in game design. Using the players' biases in favor of their experience is a possible way to achieve this effect.

Experiential:

This is the basic goal of game design. But experience is much more than just "making the players feel good" or just "creating fun games". Experience is the complex emotional outcome of living not familiar designed structures. It's what makes people love or hate a movie or game, and it is not an easy formula. Have you ever noticed that the second to last episode in a Game of Thrones season is usually the harshest? That's designed to provide a climax and an epic resolution, which involves losing characters you love or finding the "bad guys" beat them. Now, if many series and movies fail to convey experience, think of what it means to create it on an interactive and systemic format like game design.

Experience can be completely modified by small details or wrong turns. Think of a theater with painful chairs. Think of "Lost" and how many people hated the series because of the cognitive dissonances built into the mysteries of the plot. At the end, the explanation of the weird phenomena was not convincing enough for many people, and seemed random, like a desperate way to make sense of everything that happened. And no master game designer can predict completely its game experience by just using theory: playtesting is fundamental to see if the game makes players feel what they should feel.

That's where much of the Game Design principles come from: designers analyzing awful or great design strategies that have killed game experience or made it amazing. Principles like avoiding player elimination if possible, creating game rooms, creating catch up mechanics, creating level design rules for teaching new mechanics, all comes from understanding that games are not just a collection of elements, and that playing with Mario Maker does not makes you a game designer. The elements are there, but getting them right is an awful lot of work.

Meaningful:

This was the game changer for me in its moment, and the idea came directly from a video by Scott Nicholson, a researcher on Gamification. I have a profound admiration for his work, as I started following him when he made board game reviews videos and saw how he build from his gaming background and his academic research into human motivation to propose new ways of understanding the field. And how he put it, if my memory serves me right, was: how can we make a gamification system, where the player exits the system a better person than he entered it. The system should be meaningful for the player, and not just in terms of creating a rewarding experience, but by actually creating learning platforms where players can explore, experiment, and draw conclusions for their own lives.

The focus was centered on well designed feedback (which should not always be immediate, as many people think, delayed feedback is great for creating expectation, for example), and casting away the engagement loop on favor of a learning loop, centered on how game designers teach their games, and how players learn to play and master them. In this sense many theories, like Flow, which were used to create engagement, should instead be thought of as theories to optimize learning. Information chunking, unfolding mechanics, meaningful challenges, a storytelling that could give sense of the whole system, became the center of the BEM framework.

The 3 metrics

These three concepts became metrics in the BEM framework. As I said, goals are created through some sort of measurable metric, and the metrics that define a design, define the outcome of that design. Specially in the corporate environment where metrics move many business decisions, these 3 key metrics should be incorporated to make counterweight for more "perverse" ones. And not because companies want to be perverse in a dystopian sense, but because competition and the fight for scarce resources (money, customer attention, influence in the market, etc.) convert the customers into products, pawns, resources, data. BEM's three metrics are built around giving back to the player, not in the form of material (or virtual) stuff, but giving back in terms of experience and knowledge.

So here is the first lens of BEM's methodology:

Design as if for measuring the amount of experience and knowledge your player acquires through the system. Teach through giving information and creating rules systems that nudge behaviors towards taking the most advantage of the system.

Start Backwards, begin by the "M"

In my next article I will go deeper into this part of the method, but I will leave the jist. The M in BEM is the north star of the project. Experience and behavioral design will come later, by aligning them with the core principles of the project. This means, asking the honest question, what will the company gain from this project? But, moreover, what will the player gain from it, in terms of meaningful outcomes? Remember: aim for learning and empowerment.

Here we start working with the 7 core drives of BEM (Hedonism, Efficiency, Mastery, Relatedness, Discovery, Empowerment and Epic Identity), but not as a way of just profiling the player, but to give a sense of why a human being, any human being, could find compelling reasons to engage with the design. The more we can give to the player back in terms of those 7 drivers, the greater the chance of engaging any one player on any of the mechanics. We actually do a bit of profiling for clustering results and to be able to better read the data the game captures, but we do not assume that any one particular human corresponds to one profile nor that this profile defines that human.

This may sound confusing, but the core idea is, motivation is not a static thing, it is contextual and relies on internal and external pressures. And both of them change overtime, the first by learning and creating new memories from experience, the second by the ever changing conditions of the environment and external information. So a synchronic snapshot of a motivational map is not the best way to define any one person (this is why we don't use Richard Bartle's player types for example, as a way of profiling players as individuals, which was never designed for that in the first place). So, if you work with BEM, you must always be conscious that you are dealing with archetypes, not real persons, and that you are stripping many variables out of the equation to make the design manageable. So, if in your game a player behaves as an explorer, don't expect him to act as one in your web page or your online store, that would be selling snake oil.

But you can say that in a particular system, some players may engage through satisfying a particular need, if you are providing meaningful gameplay with the right learning conditions. For example, you could use a set of challenges that taps into Discovery to teach your customers how to effectively use the filtering system of your online store, making them better shoppers and helping them find interesting gems. The mechanics come later, for now, focus on what you can teach and how that satisfies a particular driver.

Next on BEM...

Be careful, human motivation is a tricky business, and you can't design a good "game" if you only focus on satisfying human needs. Motivation has direction, which is one of the core concepts we use in BEM to work with the "M". We are dealing with something profoundly complicated, and that is, how humans are better at expending energy to avoid pain, than to achieve gains. So, if your system pains your players enough, there will be no amount of human need satisfaction to compensate for it. So, in my next post I will talk a bit on how we use the seven core drivers using the lens of avoidance, apathy and approach, to find pain points and convert then into gameplay opportunities (if possible).

And again, happy holidays!