Player experience and game pillars

Hello! In the little glossary I wrote (you can find it here, I might be updating it from time to time), I described many game design terms that are important for a game designer to know and use during game development. In this text, I aim to further elaborate on my understanding of a few terms, based on my experience and what I’ve read throughout my career. In this text, I’ll talk about the player experience and the game pillars.

Player experience

Quoting myself, it is

the experience that the player has and feels playing the game, when interacting with the mechanics, systems and world in general. It is good to have it in mind from the beginning of the development, and you can even start defining a game by answering the question “what experience do I want to cause?”

So the player experience is the intended experience the game designer wants the player to have for most part of the game. And I say “for most part of the game” because the intended player experience can vary throughout the game, but the main intended experience should work as a thread connecting all the pieces of the experience together.

The player experience is the feeling(s) the game should evoke in the player as it is played. This is achieved by color tones, types of music and visual elements that populate the scenario. However (and that is my focus here), it can also be communicated through the actions the player can do, how the world challenges them, the overall speed of the levels, in sum, through game and level design. Something as simple as having tiny or long platforms in a side scroller changes how the player interacts with the game, going from a very precision-based platform to a fast-paced agility platform, which may change the player experience. Creating the player experience ranges from the big picture to small details.

Player experience — Examples

A game experience can be a sense of progression from sadness to happiness, getting stronger, reaching the level of a mentor, being crafty, being a kid inventing games, being a magician, etc.

This list can really go on forever, as a game can be based on many things, it can be based on a general feeling or some real life experience the game development team wants to convey, and in this case, it can be more or less truthful (one is not better than the other, they are just different).

Player experience — When to define and why

As I wrote in my glossary, the intended player experience is something that should be defined from as early as possible, so that each and every decision can be checked in the light of the player experience, to see if the game design decisions help or go against the player experience. A mechanic, system or level design decision that goes against the intended experience can make it experience harder to achieve or to understand.

The player experience can also help you define where to invest more energy and add more complexity, and which areas of the game can be removed or simplified. A feature can sound great in theory, but have nothing to do with the intended player experience, so it has to be adapted to the good of the game in general

In a game with a player experience based on exploration, for example, having a very linear map, where the player can’t find secrets, can seem inconsistent. Letting the player explore only when you want them to can make the exploring aspect very shallow and might impair the game experience. It does not mean that the game is bad, it just doesn’t work as a very tight system.

At the same time, having a game focused on exploration and very little use to the resources the player finds can be problematic. It will discourage the player from exploring, as it gives them no reward.

Player experience — Coming up with one

Depending on the nature of the project (a project where you can define the game is different than a work for hire situation) you might need to define the player experience for the game you are working on.

It can be defined in many ways, for example, you can define it through what you think is fun, what kind of feeling you like to feel in games, or even outside them. Think of activities in real life that could be good player experiences in a game. The genre of the game or the platform can give you some hints. Metroidvania have a knack for exploring-related experiences, and mobile games can be useful to create a companion-like experience, as the player can play the game all day long in small sessions.

In a little more artistic perspective, you can go directly to human feelings or dramas like grief, envy, solitude, hope and try to materialize into a game, always remembering that the feeling will be better communicated if you use the mechanics, systems and small decisions to communicate the chosen player experience.

Try to avoid very broad terms like “having fun and a good time” because this can mean so many things and nothing at the same time. Having fun can be a start point, but keep on exploring what fun means in the game. Is it to fly with the wind? To be with friends around a fire? To acrobat through a building putting the guards down without being noticed?

Player experience — Smaller player experiences

At the same time that the game should have a main core player experience, the notion of a player experience can be used to help define smaller aspects of the game. It helps to cast some light in the objective of each and every aspect of the game. It is important to have an overall game experience, but in the beginning of each game design definition, it is useful to define what is the role of that mechanic, level or narrative bit in the overall experience.

For example, when defining the difficulty and complexity of combat or traversal mechanics in the game, the game designer may define what is the experience of this aspect of the game. It is important that it is consistent with the overall experience of the game, but it can vary significantly if the feature is a core mechanic, or a marginal mechanic. The experience might help you define how complex or easy it should be to do some task, how fast or how slow it should be, in order to support the experience you desire to communicate.

Pillars

Along with the game’s intended experience, they are the:

Main fundamentals of a specific game, the pillars on top of which other game design decisions should be made, in order to have a cohesive game that creates the intended experience. Elements and emotions can be used as pillars. It is useful to reference back to them when defining game design decisions and when facing design problems, as a guideline to create a cohesion in the game.

It is a different tool to design a game with a cohesive core. If the experience is about how the player will feel while playing, the pillars define how this is going to be achieved. Game pillars can be feelings you want to communicate as well, game modes, narrative and visual aspects, types of player interactions, or level of complexity and everything in between. It is advisable to keep the amount of pillars reduced for better grasping of the essentials of the game and limiting it for a few important things (when everything is important, nothing is, really). Should you have more pillars, have in mind what are the most essential ones and which are less vital.

Game pillars — example

In a game whose core experience is “to have simple and casual fun with other people”, many different games and pillars can come up. It can be a competitive party game, it can be a cooperative party game, it can be an online social game, and so many other options.

Assuming you decided to do a cooperative party game, the pillars will help you define main aspects of the game that should rule the rest of the development.

A few pillars could be:

Cooperative game to have simple and casual fun with others

• points are calculated together
• varied and simple tasks for each player to do
• casual difficulty
• customizable characters

You may even define some art pillars for the game with the art team, it could look like:

• charismatic characters
• cartoon scenarios
• minimalistic UI
• pastel colors

Game pillars — usage

The pillars should always be consulted when coming up with new mechanics or other game features. In the example above, the pillar “varied and simple tasks for each player to do” will help define the amount of mechanics within the game, their complexity, helping the game designer to keep in mind that anything outside that pillar may harm the intended experience. In a game like Overcooked, for example, having three very simple tasks (like the ones in the game) and one very hard, complex and significantly more prone to failure would be bad for the general experience. The players would not want to do it, or the one player doing it would not have as much fun as the others.

It is also a good decision-making tool. Assuming in a brainstorm, part of the team came up with great mechanics, or narrative turning points for the game (all in pre production, ideally) but they can’t decide between a few of these ideas, which all look great on their minds. The pillars can be consulted to decide if one or another mechanic fits best in this game in specific. Ideas are great, but they also have the power to turn the game into a very disjointed monster. The pillars are great to maintain cohesion, which is something I personally keep on a pedestal in matters of game development.

Player experience and game pillars as a communication tool

As the work of a game designer is also communicating the game’s vision and letting the team on the same page about it, the intended player experience and pillars are great tools to start this conversation. The worst way to start talking about a game to someone who has never seen it before is through specific mechanics and details. Even if they do understand the game they are working on, they might not be invested in it.

When you bring the player experience and pillars to the front of the presentation, it gives a broad view of what you intend to do with the game and guides them through a little of your design process, which is always beneficial to break the mist of magic between the team and a game designer.

Another benefit is to have more educated feedback, both in terms of whether they think some aspect of the game does not match the experience or the pillars or whether they have ideas to improve the conveyance of it, based on the player experience and pillars you proposed. Unhampered ideas can be great, but specially for less experienced designers it can be daunting to be bombarded with so many ideas that look great but might not fit in the game as they are. If the whole team understands the purpose of the game, they can help filter the ideas through the lenses of game pillars and player experience.

Finally, the player experience has to also be communicated by the art and the music, so it is pretty much necessary to have everyone aware of the intention of the game and working in that direction.

Ultimately, the pillars and game experience help to create a cohesive and more pleasant game.

Thanks for sticking around, in my next text, I intend to define game mechanics and game systems, and demonstrate how the player experience and pillars work along with them (and how they work with each other).