• # Intrinsic and Extrinsic Motivation

Game Design and Theory

As you might have guessed, intrinsic and extrinsic motivation is all about motivation. It tries to classify our reasons for being motivated to do something and explains why we are motivated. Although much research into motivation has been done and quite some theories have been proposed to explain motivation, extrinsic and intrinsic motivation is just one of those. Actually, I already wrote an article on another theory in motivation called: ‘wanting vs liking’. Here is a link if you haven’t read it already: The striking difference between liking and wanting.

Back to intrinsic and extrinsic motivation and what these actually are. Any reason that explains our motivation to do something can be classified as an intrinsic motivator or an extrinsic motivator. When you are intrinsically motivated it means that you do something simply because you enjoy doing it. In other words, we think it is fun to do (Schmitt & Lahroodi, 2008). Extrinsic motivation, on the other hand, is when you are being motivated to do something because of an incentive. The incentive can be a reward but also a punishment, anything that motivates us as long as it doesn’t come from within our self. So if you like drawing simply because you enjoy drawing it is intrinsic motivation. But when you draw for an art class so you can get a good grade, it is extrinsic motivation. The grade is the incentive. What intrinsically motivates you is very personal, it is different for everyone. What you find extrinsically motivating is also personal but also relies on something called incentive salience: how noticeable is the incentive? (Berridge, 2007). Emotion has a role in this as well: associating an incentive with a specific emotion can make the incentive be more salient and motivating (Robinson & Berridge, 2001).

Intrinsically motivation games are games without any form of reward or punishment. We often regard these kinds of games as ‘just play’. Because most forms of play are intrinsic motivation: it is a voluntary action, there is no pressure and there is no rewards or punishment for participating or not. Some other good intrinsic motivators are exploration and curiosity. Examples of games that (mostly) rely on intrinsic motivation are games such as the Stanley parable, Flow, Minecraft and Flower. None of these games have scores and you can’t lose or win, there are no incentives.

Games that rely on external motivation are games you play solely for the rewards. Gamification is a good example: it tries to make every day, boring tasks fun by rewarding the player. Duolingo uses gamification to make learning a new language more fun and gamey (though you might start learning a language because you’d like to learn the language, which is an intrinsic motivator). Most games, however, are a mix of extrinsic and intrinsic motivators. Some games might rely more on intrinsic motivators while others rely more on extrinsic motivators. You probably start playing a game out of curiosity, an intrinsic motivator. While failing a level or dying, for example, often is an extrinsic motivator. Especially if it makes you want to try again.

## Some ideas for your own games

Extrinsic motivators aren’t bad and are naturally present in games. Think of any form of punishment such as failing a level, losing a life or losing a battle. But also reward such as a score or stars you get for finishing a level. Time is also often used in games as an external motivator, to pressure players. Think about solving a puzzle within a certain time. Another extrinsic motivator is competition, especially because it is rewarding for the player(s) who won. It can also motivate the others to try harder next time. And then there are extrinsic motivators that are less part of a game like daily rewards you get if you log in to the game every day or notifications to remind you that you haven’t played yet today.

When designing more for intrinsic motivators keep this quote in mind: “The reward is the activity itself” (Ryan & Deci, 2002). People will play your game because they enjoy playing your game, it is that simple. Rely more on the natural curiosity people have. What if you design a match-3 game with power-ups. You can choose to create guided tutorials and explain to players how to create and use them. But what if you choose to leave those tutorials out and leave it up to the player to discover what is possible? Ask yourself if someone can play the game without understanding this mechanic or feature. In that case, maybe you should leave it to the player’s curiosity to discover the feature or mechanic. Of course, you might consider a tutorial if your game is not playable before the player understands the mechanic or feature. You can also try to make your game “easy to play, hard to master”. Mastery is one of those intrinsic motivators that will make people play a game or level over and over. You could even consider adding an extrinsic motivator in the form on competition to create some social pressure. I always find it important to ask questions during the design process. Some good questions to ask yourself if you are designing a mobile game where retention is important are:

• Why will player’s want to come back to my game?
• Are they given a reward for login every day?

Could it be they only play because they get a reward that is useful in your game? Maybe they don’t play your game because they like it anymore, but because of the rewards. But maybe you design a game that requires players to think creatively or to find a solution to the puzzle outside the box. It might not be a good idea to include too many rewards or punishments, player since people who are offered a reward become distracted by it and their creativity suffers (Glucksberg, 1962). Try to stay away from time limits, they can make it harder for players to come up with a solution.

## Some good reads and references

• http://www.spring.org.uk/2009/10/how-rewards-can-backfire-and-reduce-motivation.php
• Schmitt, F. F & Lahroodi, R. (2008). The epistemic value of curiosity. Educational Theory, 58(2), 125-149.
• Berridge, K. & Kringelbach, M. (2008). Affective neuroscience of pleasure: Rewards in humans and animals. Psychopharmacology, 199(3), 457-480.
• Robinson, T.E. & Berridge, K. C. (2001). Incentive-sensitization and addiction. Addiction (England), 96(1), 103-114.
• Berridge, K. C. (2007). The debate over dopamine’s role in reward: The case for incentive salience. Psychopharmacology, 191(3), 391-431.
• Glucksberg, S. (1962). The Influence of Strength of Drive on Functional Fixedness and Perceptual Recognition. Journal of Experimental Psychology, 36-44
• Ryan, R. M. & Deci, E. L. (2000). Intrinsic and Extrinsic Motivations: Classic definitions and new Directions. Contemporary Educational Psychology (25), 54-67

Note: This article was originally published on the author's blog, and is republished here with kind permission.  Visit to read lots more of Sita's fantastic posts on psychology in games.

Report Article

## User Feedback

There are no comments to display.

## Create an account

Register a new account

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 3
• 0
• 4
• 0
• 3

• 12
• 30
• 9
• 16
• 12
• ### Similar Content

• By mujina
What could be a way of avoiding using inheritance and virtual methods when designing components for an entity-component-system?
I'll be more specific about my design issue:
I currently have different classes for different kinds of colliders (let's say, CircleCollider and LineCollider).
My system that checks for collisions and updates the positions and/or velocities of my entities should be something like:
for entity_i in alive_entities { collider_i = get_collider_of_entity(entity_i) // components of same kind are stored contiguously in separate arrays transform_i = get_transform_of_entity(entity_i) for entity_j in alive_entities { collider_j = get_collider_of_entity(entity_j) transform_j = get_transform_of_entity(entity_j) if check_collision(collider_i, collider_j) { update(transform_i) update(transform_j) } } } my problem is that I don't have a generic get_collider_of_entity function, but rather a function get_circle_collider_of_entity and a separate one get_line_collider_of_entity, and so on. (This happens because under the hood I am keeping a mapping (entity_id -> [transform_id, sprite_id, circle_collider_id, line_collider_id, ...]) that tells me whether an entity is using certain kinds of components and which are the indices of those components in the arrays containing the actual components instances. As you can see, each component class is corresponding to a unique index, namely the index position of the array of the mapping described above. For example, transforms are 0, sprites are 1, circle colliders are 2, line colliders are 3, and so on.)
I am in need to write a system as the one in the snippet above. I can write several overloaded check_collision functions that implement the logic for collision detection between different kinds of geometric primitives, but my problem is that I am not sure how to obtain a generic get_collider_of_entity function. I would need something that would get me the collider of an entity, regardless of whether the entity has a circle collider, a line collider, a square collider, etc.
One solution could be to write a function that checks whether in my internal entity_id -> [components_ids] mapping a certain entity has a collider at any of the indices that correspond to colliders. For example, say that the indices related to the collider classes are indices 10 to 20, then my function would do
get_collider_of_entity (entity_id) { for comp_type_id in 10..20{ if mapping[entity_id][comp_type_id] not null { return components_arrays[comp_type_id][entity_id] } } return null } This could turn out to be pretty slow, since I have to do a small search for every collider of every entity. Also, it may not be straightforward to handle returned types here. (I'm working with C++, and the first solution - that is not involving inheritance in any way - would be returning a std::variant<CircleCollider, LineCollider, ... all kinds of components>, since I would need to return something that could be of different types).
Another solution could be having some inheritance among components, e.g. all specific component classes inherit from a base Collider, and overrride some virtual collide_with(const Collider& other) method. Then I would redesign my mapping to probably reserve just one index for colliders, and then I would actual colliders in a polymorphic array of pointers to colliders, instead of having a separate array for CircleColliders, another for LineColliders, and so on. But this would destroy any attempt to be cache-friendly in my design, wouldn't it? That's why I am looking for alternatives.
A third alternative would be to just have a single, only, Collider class. That would internally store the "actual type" ( aka what kind of collider it is ) with dynamic information (like an enum ColliderType). Then I would have all colliders have all members needed by any kind of colliders, and specific collision detection functions which I can dispatch dynamically that only use some of that data. (Practical example: a "Collider" would have a radius, and the coordinate for 2 points, and in case its type was "circle" it would only make use of the radius and of one of the 2 points - used as the center -, while if it was a "segment" it would only make use of the 2 points). My gut feeling is that this would bloat all colliders, and, even if the bloat could be reduced - using unions in some smart way for storing members? I wouldn't know how -, then still the design would be pretty brittle.
I'm clueless and open for ideas and advice! How do you handle in general situations in which you have components that can be naturally modeled as subclasses of a more generic component class? Inheritance? Smart hacks with variants, templates, macros, custom indexing? Dynamic "internal" type?
×