Jump to content
  • Advertisement
  • 07/31/17 12:34 PM

    Intrinsic and Extrinsic Motivation

    Game Design and Theory

    FriendlyHobbit

    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).

    It is important to keep intrinsic and extrinsic motivation in mind when you design your game because it can have an effect on your player’s behavior and how they like the game. Relying on extrinsic motivation too much can kill creativity and problem-solving. According to Glucksberg (1962), people can become distracted by (monetary) rewards when they are offered one. This distraction inhabits people to solve a problem which requires creative thinking. Extrinsic motivation can also kill motivation. Especially rewards can undermine the intrinsic motivation people have for an activity (Deci, 1999). People will enjoy the activity less and not do it as often anymore. And as we know from my previous article, people can ‘want’ to do something without actually liking the activity anymore. So how can you know that players are playing your game because they ‘like’ it from looking at your game’s analytics? How can you know whether your players are just mindlessly playing your game because they became addicted to it? Sure, if your goal is to just generate money and not caring whether or not your players acutely like playing your game, go ahead, it can be a conscious choice. But if you want your players to look forward to your game and actually liking to play it, consider relying more on your player’s intrinsic motivation.

    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.

    img_0268.jpg

    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.

    img_0269.png

     

    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 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
  • Game Developer Survey

    completed-task.png

    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!

    Take me to the survey!

  • Advertisement
  • Latest Featured Articles

  • Featured Blogs

  • Advertisement
  • Popular Now

  • 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?
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!