Jump to content
  • entries
    14
  • comments
    10
  • views
    1828

Reactance theory in games

FriendlyHobbit

1779 views

http://www.tinker-entertainment.com/sitavriend/psychology-and-games/reactance-theory/

You can make something more desirable by forbidding it. That something can be anything: an item, an action, an idea. Well this is possible and known as the reactance theory. Reactance is the feeling you get when someone limits your freedom or option. Basically when you’re not allowed to do something or when you are told you have to do something.

This feeling results in you:
1. Wanting forbidden option even more.
2. Trying to reclaim your lost option.
3. Experiencing aggressive and angry feelings towards the person (this person may be fictional as well, or and AI) who limited your options or freedom in the first place. (These feelings can be very subtle and barely noticeable but motivate you to do the opposite from what you have been told to do.)

The first scientist to talk about the idea reactance was Brehm in a theory of psychological reactance. He was the first to research the reactance theory and explains reactance as a motivational state people experience when their freedom is removed or threatened (1966). But you probably already know the reactance theory as reverse psychology. And that’s what reactance basically comes down to: Getting people to do something by telling them they are not allowed to do that something or the other way around. Unfortunately, it doesn’t always work. Some people are just not as sensitive to experience reactance as others and circumstances matter too. For instance: reactance breaks down when people can rationalize why they shouldn’t do something. If someone told you not to buy the bag you really wanted, you’d probably buy the bag anyway. But if that someone explained that he bought the same bag and it broke after 2 days, you’d probably think twice before buying the bag.

Portal 2 applies the idea of reactance brilliantly in their level design when the player enters Aperture’s dungeons. Along the way back up, the player encounters several warning messages as you can see in the picture below: “warning”, “do not enter”. Of course these warnings are not to discourage the player, they are meant to lore the player closer. Reactance helps the storyline feel less linear than it actually is. Player is more attracted to this option and goes on to explore it. It also guides the player through the level more naturally because they want to explore this forbidden option rather than going somewhere else.

portal2
You probably want to know what’s behind those walls

The Stanley parable applied the reactance theory to their gameplay using narrative. The player is encouraged to try all storylines since the end is never the end in the game. In fact, the game is all about discovering new endings and alternative storylines and that means you don’t want listen to the narrator most of the time. The blue door ending is a great example of this: The narrator tells Stanley to walk through the red door when the player approaches a room with a red and blue door. When you ignore the narrator and walk through the blue door, he’ll send the player back and tells Stanley to walk through the red door again. The blue door becomes a more attractive option now, so the player choices the blue door again. The player will be send back to choose the red door again but this time the blue door is moved behind the player and the narrator stresses Stanley he has to walk through the red door. The blue door has never been a more attractive option.

stanly
Such an attractive blue door! Look at those curves!

The reactance theory can easily be applied to your own games. It can help you design interesting levels or create interesting narrative for games that rely on (branching) narration. When you want to implement the idea of reactance into your own game you can make something more desirable by forbidding it or you can make something less attractive by forcing it. This something can be anything: an item, a choice you want the player to make, a path the player should walk, an action you want the player to perform. Be creative! Keep in mind that not everybody is equally sensitive to reactance and that the effect breaks down when the player can rationalize why they shouldn’t do something.

Here are some ideas for you.
Level design:
–  Use some art! Show something is dangerous or advise the player not to go there with signs or writing on the walls. Doesn’t have to be art-heavy, just tell them a certain area is closed off and that they are not allowed to enter.

Narration games:
–  Somewhere in the narrative you can tell the player they are not allowed to make a certain choice (remember: don’t explain why). You can also “force” players to make a certain decision like the red door in the Stanley parable.
–  Empower the player by telling them they aren’t good enough to do something, they will do it.
–  Tell the player that he/she has to do something a certain way, they will do the opposite.

Items:
–  Tell your player is a forbidden item and they shouldn’t take it.

Want to read more (scientific) stuff on the reactance theory?



1 Comment


Recommended Comments

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By OConquestGame
      Hello there!
      I’m the creator and producer of an upcoming visual novel / video game. 
      My team and I are looking for artists (character and background), writers (experienced in writing relatable characters and witty dialogue), and programmers (familiar with unity and creating mini games). 
      Our team is a group of close friends looking to break the mold of the traditional visual novel and create something new and positive. This game will be highly promoted and be a great portfolio piece. Rates are negotiable!
      If you are interested please contact/message us today! OConQuestGame@gmail.com
    • By Gas Lantern Games
      Hello!

      I have spent the last year and a half developing a game in my spare time in Unity! I am releasing it soon on Steam. Ant Empire is a strategic remake of some older games. It is influenced by games such as Ant Empire and Civilization.

      I am currently doing a kickstarter to help fund an AI before launch.

      I have attached some images (tried some gifs but they were too large) to show the current stage of Ant Empire, which is nearly completed.







    • By Shaarigan
      Hey,
      I'm currently starting next iteration on my engine project and have some points I'm completely fine with and some other points and/or code parts that need refactoring so this is a refactoring step before starting to add new features. As I want my code to be modular to have features optional installed for certain projects while others have to stay out of sight, I designed a framework that starting from a core component or module, spreads features to several project files that are merged together to a single project solution (in Visual Studio) by our tooling.
      This works great for some parts of the code, naming the Crypto or Input module for example but other parts seem to be at the wrong place and need to be moved. Some features are in the core component that may belong into an own module while I feel uncomfortable splitting those parts and determine what stays in core and what should get it's own module. An example is Math stuff. When using the framework to write a game (engine), I need access to algebra like Vector, Quaternion and Matrix objects but when writing some kind of match-making server, I wouldn't need it so put it into an own module with own directory, build script and package description or just stay in core and take the size and ammount of files as a treat in this case?
      What about naimng? When cleaning the folder structure I want to collect some files together that stay seperated currently. This files are foir example basic type definitions, utility macros and parts of my Reflection/RTTI/Meta system (which is intended to get ipartially t's own module as well because I just need it for editor code currently but supports conditional building to some kind of C# like attributes also).
      I already looked at several projects and they seem to don't care that much about that but growing the code means also grow breaking changes when refactoring in the future. So what are your suggestions/ oppinions to this topic? Do I overcomplicate things and overengeneer modularity or could it even be more modular? Where is the line between usefull and chaotic?
      Thanks in advance!
    • By PlanetExp
      I've been trying to organise a small-medium sized toy game project to supports macOS, iOS and Windows simultaneously in a clean way. But I always get stuck when I cross over to the target platform. I'll try to explain,
      I have organised my project in modules like so:
       
      1. core c++ engine, platform agnostic, has a public c++ api
      2. c api bindings for the c++ api, also platform agnostic, this is actually part of 1 because its such a small project
      3. target platform bindings, on iOS and macOS this is in swift. Basically wraps the c api
      4. target platform code. This part just calls the api. Also in swift.
       
      So in all I have 4 modules going simultaneously, all compiled into a separate static libraries and imported into the next phase/layer. Am I even remotely close to something functional? I seem to getting stuck somewhere between 2 and 3 when I cross over to the target platform. In theory I would just need to call the game loop, but I always end up writing some logic up there anyway.
       
    • By MarkNefedov
      So, initially I was planning to create a base class, and some inherited classes like weapon/armour/etc, and each class will have an enum that specifies its type, and everything was going ok until I hit "usable items".
      I ended up with creating UsableItem class, and tons of inherited classes, like Drink/Apple/SuperApple/MagickPotato/Potion/Landmine/(whatever that player can use) each with unique behaviour. I planned to store items in the SQLite database, but I discovered that there are not many ways of creating variables(pointers) with type determined at runtime (that preferably get their stats/model/icon/etc from DB). So, I think that I need to use some variation of the Factory pattern, but I have no idea how I should implement it for this particular case (giant switch/case 😂 ).
      It would be really nice if you guys can give me some advice on how I should manage this kind of problem or maybe how I should redesign the inventory.
      Inventory storage is an array of pointers. I'm working with CryEngine V, so RTTI can't be used.
      Example code:
      namespace Inventory { enum ItemType { Static, Building, Usable, Weapon, Armour }; class InventoryItem { public: virtual ~InventoryItem() = default; virtual ItemType GetType() = 0; virtual string GetName() = 0; virtual string GetIcon() = 0; virtual void Destroy() { //TODO: Notify inventory storage delete this; } }; class UsableItem : public InventoryItem { public: struct Usage { int Index; string Use_Name; }; virtual CryMT::vector<Usage> GetUsages() = 0; virtual void UseItem(int usage) = 0; }; class TestItem : public UsableItem { int Counter =0; ItemType GetType() override { return ItemType::Usable; } string GetName() override { return "TestItem"; } string GetIcon() override { return "NULL"; } CryMT::vector<Usage> GetUsages() override { CryMT::vector<Usage> Usages; Usages.push_back(Usage{1, "Dec"}); Usages.push_back(Usage{2,"Inc"}); Usages.push_back(Usage{3,"Show"}); return Usages; } void UseItem(int usage) override { CryMT::vector<Usage> uses = GetUsages(); switch (usage) { case 0: for (int i =0; i<uses.size(); i++) { CryLog(uses[i].Use_Name); } break; case 1: Counter--; CryLog("Dec"); CryLog("%d", Counter); break; case 2: Counter++; CryLog("Inc"); CryLog("%d", Counter); break; case 3: CryLog("%d", Counter); break; default: CryLog("WRONG INDEX"); break; } } }; }  
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!