Category: Design

[NOTE: This was originally published on Medium, and has been reposted on this blog for posterity.]

In this two-part article I will try to identify some player motivations in games, and how catering to those can lead to increased player engagement and enjoyment. I’ll have some examples of this being done in existing games, and provide my thoughts on how you can incorporate support for such motivations in your own.

I won’t be going too much into some of the “usual suspects”, like Bartle’s taxonomy of player types, self determination theory, etc. Rather, this is my own subjective understanding of what motivates players.

If you agree or disagree with any of the observations and suggestions I provide here, or if you have other examples of player motivations that go beyond what is listed, let me know in the comments below. With that said, let’s dive straight in and have a look at the first four player motivations on my list (in no particular order) — narrative, mastery, self-expression and ownership, collection and completion!

---

Core Player Motivations

Narrative

Some games grab the player’s attention through narrative, which become the primary drive for the player to progress in the game. Old-school adventure games by LucasArts (Monkey Island, Full Throttle, Grim Fandango) or Telltale’s episodic series (The Walking Dead, The Wolf Among Us) are prime examples of this. They use puzzle-solving to drive the story forward, but the actual puzzles are less important to players than the resulting story that unfolds.

The use of narrative as the primary driver for player progression can also be found in many “modern-day” mobile games. Take games in the merge/match-genres, like Merge Mansion, Love & Pies and Homescapes. These games rely on story for the initial hook to catch the player’s interest, and to give players mid-to-long-term motivation beyond the core gameplay, the mechanics of which tend to get repetitive once the player has fully grasped them.

The addition of a narrative layer can give players more context for what they’re doing, breaks up repetitive actions to make them less tedious and provides extra motivation for the player to continue playing, beyond “reaching the next level” or “finishing the next merge-chain”. Yet, the effect of the initial narrative hook will eventually fade away in such games, and requires that the narrative re-engages the player on a regular basis, or is supplemented by other elements like live events.

Not all games need a narrative hook — Tetris does fine without one! — but especially in combination with simple, repetitive mechanics that don’t give the player a clear sense of mastery, a strong narrative hook can have a positive impact on player retention.

Guiding thoughts:

• A layer of narrative on top of otherwise repetitive game mechanics can act as a retention hook, and provides players with additional motivation to keep playing and coming back for more.
• If including a narrative, introduce it early, to give context for the game mechanics and to showcase mid-to long-term goals.
• Narrative hooks can be framed as calls to action: “Rebuild the Mansion! Uncover the sinister plot! Solve the mystery! Save the cheerleader, save the world!” (Maybe ignore that last one, I’ve been rewatching the first season of Heroes recently… so good!)
• The effect of the narrative hook diminishes over time, and the narrative must re-engage the player on a regular basis to be effective.

Key concepts to read up on:

• narrative, retention hooks, calls to action, hero’s journey, player agency

Mastery

Mid-to-long term motivation

When a game allows a player to learn, adapt and optimise their strategies while playing, or when it lets them improve the skill and/or muscle-memory required to overcome challenges, the player can develop a sense of mastery of the game.

This can provide strong intrinsic motivation for continued play, as players generally enjoy learning and improving! Yet, this is only true if the challenges presented to the player can keep up with the pace of the player’s own mastery improvements.

This balancing act between challenge and mastery level is a concept known as “flow” or “flow state”. The basic gist is that when a player’s mind is at the ideal point between “aroused” and “in control” based on their level of mastery versus the difficulty of the challenge presented, they’ll be in a state of “flow” where they are immersed in what they’re doing.

This provides an optimal state of intrinsic motivation, where the player is engaged with the game not because of extrinsic rewards, but because they are fully immersed and engaged with the game for its own sake.

However, as soon as the player has achieved full and complete mastery of the game mechanics, and no more challenges can be found, that intrinsic motivation fades away. Instead, boredom and relaxation take over. The game might offer other compelling reasons to stay (social bonds, ownership, collection, etc.), but the player’s mastery of the game will no longer be the driving factor.

Making use of the theory behind the Virtuous Circle Effect can also help players stay in this zone of mastery. If the player succeeds at something, make it easier for them to succeed again in the next few successive attempts. Then bring it up a notch by suddenly providing them with a bigger challenge to keep things interesting. Such a “string of successes” combined with bumps in difficulty level can help enforce the player’s feeling of mastering the game.

Guiding thoughts:

• For a player to get a sense of mastery of the mechanics in your game, they need to be able to make meaningful decisions along the way, and really feel like those decisions matter.
• The choices they make could be twitch-based (mastery of dexterity, reaction time, quick thinking) or be based on player knowledge (mastery of learning the game mechanics, applying the lessons learned, adapting to variants of known mechanics)
• Aim to keep the player in a balanced state of “flow”, as opposed to bored with lack of challenge or anxious about too difficult challenges.
• Don’t aim for a linearly-increasing difficulty throughout your game. Give the player some more difficult challenges every now and then, while also remembering to let them breathe after those challenges!

Key concepts to read up on:

• mastery, flow, being in the zone, difficulty levels, virtuous circle effect

Self-Expression and Ownership

Long-term motivation

Self-expression and ownership are two sides of the same coin. One leads to the other, and are among the strongest binding agents that keep players coming back to games.

Being able to express oneself or explore one’s identity in a game can be a strong motivator to keep coming back. Some examples:

• Customising the appearance of an avatar (any MMO ever)
• Designing and building a unique-looking base (Clash of Clans)
• Decorating a personal space (virtual homes)
• Leaving messages that other players can read (Splatoon, Dark Souls).

When such self-expressions persist beyond a player’s current session, and allows the player to leave a mark on the game for other players to see (customised house, area conquered and controlled by player’s guild), this also provides the player with a strong sense of ownership. It’s as if they own a small part of the game world!

Neither is exclusive to online games, though. Self-expression and ownership can also be found in single-player RPGs that allow the player to customise the look and functionality of their avatar(s), in “renovate and improve”-style merge games that let players choose which decorations to place out, or in action RPGs that encourage players to come up with their own novel and fun builds and playstyles.

Guiding thoughts:

• Both self-expression and ownership can lead to long-lasting player retention
• Fostering self-expression, in whatever form that fits your particular style of game, can also increase a player’s sense of ownership
• If you let the player leave a persistent mark on your game world (if it has a world), they will keep returning to your game, sometimes just to check if the mark they left is still there!

Key concepts to read up on:

• self-expression, ownership, persistence, long-term retention

Collection and Completion

Mid-to long-term motivation

This type of motivation can keep players playing a particular game far beyond the point where one would expect them to drop off. The more the player collects, the harder they’ll find it to leave the game. There’s always another collection to complete, another achievement to chase, and another mystery lootbox to open. This also feeds into the “ownership” type of motivation.

Games of all types and genres rely on this type of motivation to keep players engaged. From single-player games like Assassin’s Creed to social simulations like Animal Crossing to MMOs like World of Warcraft. From “gotta catch ’em all” games like Pokemon to “waifu/husbando” collection games like Genshin Impact or Epic Seven. They all tie in to the same primal drive in human/gamer nature — the desire to collect — or catch — them all, and then show them off to other players!

While these collection mechanics are super strong retention tools, they also raise ethical (and legal) questions. 🔗Governments and regulatory bodies around the world increasingly scrutinising games over concerns about things like lootboxes, gaming addiction and gambling.

Depending on the game and the specific mechanics involved (gacha mechanics being a notorious example), some players motivated by collection/completion might even veer off into addiction-territory. They might feel compelled to keep playing (and paying) even after they no longer find the game itself fun, often because they feel they’ve invested too much time, effort and money into the game to stop playing (see Sunk Cost Fallacy).

Guiding thoughts:

• Collection mechanics and systems can keep players engaged for a really long time if done right
• Achievement systems tend to be most effective when they don’t force the players to drastically change their playstyle to unlock achievements, nor require them to “grind out” the achievements through hundreds (or thousands) of iterations of un-fun activities.
• Think about ways for players to show off their collections to other players, and how your game can support this
• Stay up to date on how lawmakers and regulatory bodies around the world react to the inclusion of systems and mechanics that could be tied to gaming addiction and/or gambling, and where the lines in the sand are drawn (if anywhere)

Key concepts to read up on:

• collecting games, achievement systems, gacha mechanics, lootboxes, sunk cost fallacy

Conclusion — Part 1

Whelp, that’s all for now. Let me know your thoughts in the comments below, and be on the lookout for the second part of this article, which will takcle player motivations around community and sociability, cooperation, competition and money!

Adapting your design doc for different readers

[NOTE: This was originally published on Medium, and has been reposted on this blog for posterity]

One major challenge that Game Designers face when working on design documents for new games, or for new features, is writing them with a particular audience in mind. I’m not talking about the target audience for the game itself, but about other stakeholders who will be reading the document: Artists, Engineers, Producers and publishers — not always in that order of priority.

In fact, it’s not unthinkable that you’ll find yourself writing the same design document over and over again multiple times: first, you might write something high-level aimed at informing or getting feedback or approval from a publisher, then elaborate on the details for the benefit of your Producer, and finally flesh out the design to make it implementation-ready for Engineers, Artists, and Designers.

Being able to write for each of these kinds of audience is a skill that can be learned over time, from document to document, based on the feedback and questions asked about the designs, guidance from more experienced Designers, and… well… a lot of practice.

That doesn’t mean you can’t get a head start, though. Read on for some tips and general best practices for writing with these different audiences in mind! Does this align with your own experience? Let me know in the comments!

---

Writing for Publishers

When the primary audience for your design document is a publisher, or the equivalent of a publisher — like a third party with a lot of influence on how your game is made/shared with the world — you need to approach the task a bit differently to writing for other members of your development team.

Generally speaking, you should be writing high-level designs that highlight the important points of the game as a whole. The writing should be to the point and concise, laid out in bullet-point form and with few (or no!) distractions, side-notes, or anything else that might hamper you in getting your concept across.

While your Designer brain (or heart) might want to pile on the details to make everything super clear and leave no room for any misunderstandings, in this case you should reign yourself in! The publisher normally doesn’t need to know about the ten potential edge cases for a particular mechanic and their every possible solution. They normally don’t want to read page after page of plot details, background lore, and detailed descriptions of every single object in the game.

Instead, their focus is directed at the overall, big-picture stuff:

• Does your design align with the interests of your game’s intended audience?
• (If platform owner) Does it cover the platform’s default requirements for feature X, Y, Z?

They’ll also want to know the risk factors of the design, especially when it comes to…

• Anything that touches on real-life cultures and groups
• Conforming to the privacy laws and regulations of every region where the game will be published
• How it could affect the game’s age rating: You don’t want a game targeted at young kids to be unexpectedly rated 12+ because you included too graphic violence or explicit language.

By thinking about and covering these aspects in the design document from the start, we can help ease the game’s approval process and reduce the chances of friction in the working relationship between the development studio and the publisher.

Depending on the publisher — and the project — they might want more detail or less detail, but that’s something you’ll learn based on the feedback they provide, the questions they ask, and any potential requests they make for additional information.

However, working with external partners on third-party IPs can drastically change the picture here, as there’s a high chance they’ll want a say in anything that directly relates to their IP, requiring more elaborate approval processes, more iterating on designs (and art!), more meetings, and more reviews.

Writing for Producers

To some extent, Producers tend to think along the same lines as Game Designers when it comes to reading and interpreting design documents. (Chances are, a given Producer was also a Game Designer at some point in their career!)

They will compare the design to other games with similar implementations; they’ll attempt to poke holes in the design to see where improvements can be made, and they will pull at loose threads to see if the design unravels.

However, their primary focus will be on the product side, and with, y’know… producing:

• How long will this design take to implement? Does it fit into the allotted time in the production schedule, or does the design need to be adjusted/cut down to fit? Will there be enough time for QA testing?
• What kinds of resources need to be allocated to make it happen? How many Engineers can be spared, how much is on the Art team’s plate already?
• How complex is the implementation? Is this something the team has had experience doing before, or is it something completely new, with unknown factors that could affect implementation time?
• What potential impact does the feature/mechanic have when it comes to player retention, player ratings, player’s willingness to spend money on the game, etc.?
• What are the risks involved in this design, and how can those risks potentially be mitigated/avoided? Can the design be simplified to eliminate some of these?

As Game Designers, we can also make the lives of Producers slightly easier by keeping the below considerations in mind while writing our design documents:

• We can divide the design into logical sections/versions that can be considered (and implemented) independently of one another. Version 1 of the design includes X, version 2 includes Y, and version 3 expands on X and Y to provide Z.
• We can offer several levels of granularity so the design can be read both from a high-level perspective and from a more in-depth one. Depending on the tools used for writing the designs, this can be achieved by: colour-coding different sections of the text; using spoilers or toggles that hide extreme details for someone just wanting to skim over the document; using sub-pages; or by having dedicated sections that summarise the most important parts of the design.
• We can consult Engineers/Artists up front about the feasibility of certain aspects of the design, including what kind of effort would likely be required to realise them, and either include these estimates in the design or adjust the design accordingly.
• We can think about the potential risks of the design up front and provide our own initial thoughts on how to mitigate them.

Writing for Engineers

When the time comes to prepare your design documents for implementation, you’ll be writing with Engineers as your target audience. That means you need to think like an Engineer, seeking more detail, more thought put into edge cases, and more specificity about the needs of the design:

• What kinds of support tools are needed for the design, if any?
• What kind of format should be used to store data for use by Designers?
• What are the potential edge cases of the design, and how should they be handled?
• If the design of a multiplayer game says a shop timer should reset once every day, should it reset at the same time for all players globally or regionally, or should each player have their own individual timer, independent of others?
• What happens if a player has reached max level and gains additional XP? Should the game cap the additional XP, or let the player hoard it for later?
• If a player claims a reward but then closes the game or restarts before the reward animation/FX are over, what should happen the next time the player starts the game?

Don’t be shy: Engineers are detail-oriented by nature, and not being clear enough about how something should work will prompt them to ask more questions anyway, potentially even delaying the implementation if an answer cannot be provided straight away.

Don’t rely on them to figure it all out on their own, however. If details aren’t treated in enough depth, Engineers might implement the design based on assumptions made off the back of your vague design, in a manner you didn’t intend, and you’ll either be stuck with that implementation (if there’s no time to redo), or you’ll have wasted precious Engineer time that could have been put to better use — not to mention the time it’ll then take to redo the work in the “correct” manner instead.

Writing for Artists

It’s perhaps rare that you’d write a design document aimed at Artists alone, but invariably there will be sections of your document that are more important to your Art team than others. In order to allow them to accurately scope the work needed to support the design, you need to be specific about what you ask for:

• Instead of saying “The player will be able to choose from various different cosmetic options”, you might be better of going a bit more in depth: “The player will be able to choose between 10–15 different types of hats to wear. The hats will all be animated, and the player’s choice will be on display both in the main menu lobby and in-game, visible to both themselves and other players.”

The Art team can then scope out how much time and effort it would take to prepare the assets, which they can then adjust for when planning other work. Maybe they’ll get back to you and say “Sorry, in the given time frame we’ll only be able to provide X hats, and only Y animated ones — the rest will be static.” Then you can update your design accordingly, or negotiate with Art team/producer on how to get the most out of their time.

If a character ability requires a special effect to convey to the player what the ability does, the Artists might need to know details such as:

• Should the ability button itself have an effect, or should there only be an effect on the character?
• Does the ability have an activation time, and if so does should effect play from the start, only kick in once he activation time is over, or be separated into multiple stages, e.g. build-up -> activation -> lingering effect?

Being specific is also important when it comes to UI: For example, the UI/UX designer will need to know that the design requires buttons X, Y and Z, that button X brings up a popup with a confirmation dialogue, that button Y should be disabled under certain circumstances, and that button Z should cause an explosion of confetti on the player’s screen.

• The design doesn’t need to state where all these buttons are down to the exact coordinates of each pixel, but creating a simple mock-up on your own (Designer art is the best art!) can help get the general idea across and ensure that what the Artists deliver is aligned with what’s in your head.

Since the Artists will find information about these things more helpful than, say, the handling of edge cases surrounding match-making or detailed rules for how leaderboard resets affect player points, it can be a good idea to separate out art-specific details of the design document into their own sub-sections so that all relevant information can be found in one place.

But… What about writing for Designers?

You may have noticed I didn’t mention anything up above about writing for other Designers. The reason for that is quite simple: As a Game Designer, you should not be writing design documents targeted specifically at other Designers! Like yourself, those other Designers should already be capable of reading and grokking the essence of a design regardless of whether it’s written for an external third-party publisher or the Engineering team.

Even if your design is still in its very early exploration stages, when you’re still writing the outline of the design and you find yourself in need of some input from fellow designers on how to proceed with the design — you’ll still not be writing the design with those other Designers in mind.

At that point, you’ll effectively be writing the document for yourself so that you can fully get to grips with the design, and while this might make it easy for likeminded Designers to grasp its essence, they should still not be thought of as the intended audience.

You should already at this point start to think about who is going to read the design document, and about how you can ensure that the message you want to convey comes across as clearly as possible.

---

Well, that’s all from me. If you found any of the above tips helpful or insightful in any way, or if you have your own thoughts or best practices for how to write game design documents targeted at specific audiences, feel free to leave a comment below!