Image

Player trust within the gameplay environment via @Gaohmee

Continuing to recompile interesting twitter threads that can be of value to our community, in this case Player trust within the gameplay environment via @Gaohmee

Original Twitter Thread: Player trust within the gameplay environment

Player trust within the gameplay- The trust Spectrum
Player trust within the gameplay- The trust Spectrum Source: gamedeveloper.com

Edited Twitter Thread: Player trust within the gameplay environment

Alright, it’s early and we’re pretty much alone in the office and I feel like writing a #gamedesign thread… Let’s talk about player trust within the gameplay environment, establishing rules and when/why you’d want to break them.

Player trust is a very interesting topic in game design theory that we rarely talk about, because often it seems like we just assume it or it seems logical. Experienced designers however approach the topic with lots of thought and purpose for storytelling.

Whenever you start a new game, even if you are an experienced player, you essentially have to start learning the rules of a game fresh: from intrinsic things such as environment rules (e.g. how does gravity effect things) to gameplay rules and rules of the story/world.

There is a lot to establish early on and many of these things are usually explored through incrementally exposing the player to these rules. If we explicitly say it or not: The player by default and automatically establishes a basis of trust that we won’t betray those rules.

Also Interesting:   Balance Games problems? four tricks to improve game balance in your game design

Have you ever watched a video of Unfair Mario? It’s essentially a subversion of this basic rule and making mistrust the main game element by constantly changing up the rules of the world. Here:

In Unfair Mario, the frustration is the point of the game, never being able to rely on the rules you have slowly learned and established. Obviously, this is exactly what we want to avoid in a game, unless there is a specific purpose for it. I’ll get to that later.

Now… If you are a developer and you have done early playtesting you have definitely come across one of the hardest lessons to learn: Almost always you will encounter that players don’t understand your world and rules the way you do and it feels INFURIATING.

To the person making the game and the rules, it is so obvious and crystal clear how they function. This is why we playtest early! Developers are the worst judges of the clarity of how we establish rules – because we literally made them up. You’ll get better with experience.

If you’ve ever played a game where you were stuck because you didn’t know what to do or why something happened – that’s bad game design and it will contribute to developing mistrust between you and the game. The same goes for when a game breaks its own rules.

A player’s success, empowerment and engagement is heavily reliant on knowing that the rules you have established with them will not be broken without a reason and players get into a game when they trust that this contract is not broken so they can learn and progress.

Also Interesting:   Game Design Document Example

Now, there are some instances where you would WANT to break this contract: When you are trying to deliberately throw a player off. That sounds a lot easier than it is because players need at least a hint as to why it is worth following you down that path.

You have betrayed their trust – you need a reason. And your players need to at least know that they will eventually find that reason. Horror games use this technique a lot to generate a feeling of uncertainty and not trusting your environment, character or even story.

·

Breaking trust can be a powerful tool for deliberate dis-empowerment within a game or help build towards a big twist – the ladder only works if you signpost enough to your player that there WILL be a resolution or an explanation – essentially another plea for trust 🙂

As you know, I’m a big fan of the magic of hidden game design, so I believe not every game needs to reveal all its systems to the player and the trick is to know what to expose and what to withhold and where it suits your audience type and genre.

As a side-note, exposing many complex game systems to your players and allowing players to participate in them requires a LOT of community work, e.g. World of Warcraft theorycrafting or competitive play games such as League of Legends.

Trust in competitive play is a very different kind of beast because people need to know so much about the systems to truly master competitive play that you owe them a lot of explanation for changes and balancing.

Also Interesting:   Twitter thread on Celeste game-feel via @MaddyThorson

In summary: Trust is a fundamental, assumed building block of the games we create and I advise you to make it a purposeful tool in your game design toolbelt, use it to build the stairway for player progression and know when to use it as a drama tool. That is all <3

Mh well. Yes and no. It’s just part of the craft and there have been many great comedic games.

Great discussion! In CCG design, I’ve called this “the contract.” It’s not just things you said you would or wouldn’t do, there are expectations forged by everything you’ve done so far. And as you said, when you break those rules, you’d better have a good reason.

A favourite article which you probably know: https://80.lv/articles/defining-environment-language-for-video-games/… In particular the section “Buffer your Metrics”. The player can always trust how the environment will function because ambiguously-sized pieces are avoided.

Interested in learning more, then check frequently our blog

Advertisements
1 Comments Text
  • skapa binance-konto says:
    Your comment is awaiting moderation. This is a preview; your comment will be visible after it has been approved.
    Your article helped me a lot, is there any more related content? Thanks! https://www.binance.com/sv/register?ref=RQUR4BEO
  • Leave a Comment

    Your email address will not be published. Required fields are marked *

    Index