Monday, April 22, 2013

Advancement, Progression and Pacing (Part II)

In Part I of this article, game designer and educator Ian Schreiber explains the reasoning behind using advancement, progression and pacing in games. In Part II, he discusses challenge levels in PvE.

Two Types of Progression 

Progression tends to work differently in PvP games compared to PvE games. In PvP (this includes multi-player PvP like “deathmatch” and also single-player games played against AI opponents), you’re trying to win against another player, human or AI, so the meaning of your progression is relative to the progression of your opponents.

In PvE games (this includes both single-player games and multi-player co-op) you are progressing through the game to try to overcome a challenge and reach some kind of end state, so for most of these games your progress is seen in absolute terms.

Challenge Levels in PvE 

When you’re progressing through a bunch of challenges within a game, how do you track the level of challenge that the player is feeling, so you know if it’s increasing too quickly or too slowly, and whether the total challenge level is just right?

This is actually a tricky question to answer, because the “difficulty” felt by the player is not made up of just one thing here, it’s actually a combination of four things, but the player experiences it only as a single “am I being challenged?” feeling. If we’re trying to measure the player perception of how challenged they are, it’s like if the dashboard of your car took the gas, current speed, and engine RPMs and multiplied them all together to get a single “happiness” rating, and you only had this one number to look at to try to figure out what was causing it to go up or down.

The four components of perceived difficulty

First of all, there’s the level of the player’s skill at the game. The more skilled the player is at the game, the easier the challenges will seem, regardless of anything else.

Second, there’s the player’s power level in the game. Even if the player isn’t very good at the game, doubling their Hit Points will still keep them alive longer, increasing their Attack stat will let them kill things more effectively, giving them a Hook Shot lets them reach new places they couldn’t before, and so on.

Third and fourth, there’s the flip side of both of these, which are how the game creates challenges for the player. The game can create skill-based challenges which require the player to gain a greater amount of skill in the game, for example by introducing new enemies with better AI that make them harder to hit. Or it can provide power-based challenges, by increasing the hit points or attack power or other stats of the enemies in the game (or just adding more enemies in an area) without actually making the enemies any more skilled.

Skill and power are interchangeable

You can substitute skill and power, to an extent, either on the player side or the challenge side. We do this all the time on the challenge side, adding extra hit points or resource generation or otherwise just using the same AI but inflating the numbers, and expecting that the player will need to either get better stats themselves or show a higher level of skill in order to compensate. Or a player who finds a game too easy can challenge themselves by not finding all of the power-ups in a game, giving themselves less power and relying on their high level of skill to make up for it (I’m sure at least some of you have tried beating the original Zelda with just the wooden sword, to see if it could be done). Creating a stronger AI to challenge the player is a lot harder and more expensive, so very few games do that (although the results tend to be spectacular when they do – I’m thinking of Gunstar Heroes as the prototypical example).

At any rate, we can think of the challenge level as the sum of the player’s skill and power, subtracted from the game’s skill challenges and power challenges. This difference gives us the player’s perceived level of difficulty. So, when any one of these things changes, the player will feel the game get harder or easier.

Written mathematically, we have this equation:

PerceivedDifficulty = (SkillChallenge + PowerChallenge) – (PlayerSkill + PlayerPower)

Example: perceived challenge decreases naturally

How do we use this information? Let’s take the player’s skill, which generally increases over time. That’s significant, because it means that if everything else is equal, that is, if the player’s power level, and the overall challenge in the game stay the same, over time the player will feel like the game is getting easier, and eventually it’ll be too easy. To keep the player’s attention once they get better, every game must get harder in some way. (Or at least, every game where the player’s skill can increase. There are some games with no skill component at all, and those are exempted here.)

Measuring the components of perceived challenge

Player skill is hard to measure mathematically on its own, because as I said earlier, it is combined with player power in any game that includes both. For now, I can say that the best way to get a handle on this is to use playtesting and metrics: for example looking at how often players die or are otherwise set back, where these failures happen, how long it takes players to get through a level the first time they encounter it, and so on.

[This article was adapted from Ian Schreiber's course, Game Balance Concepts.]

Ian Schreiber has been in the game industry since the year 2000, first as a programmer and then as a game designer. Also an educator since 2006, Ian has taught game design and development courses at a variety of schools, and on his own without a school. He has co-authored two books, Challenges for Game Designers and Breaking Into the Game Industry.

Thursday, April 11, 2013

Advancement, Progression and Pacing (Part I)

In Part I of this article, game designer and educator Ian Schreiber explains the reasoning behind using advancement, progression and pacing in games.

A lot of games feature some kind of advancement and pacing, even multiplayer games. There’s multiplayer co-op games, like the tabletop RPG Dungeons & Dragons or the console action-RPG Baldur’s Gate: Dark Alliance or the PC game Left 4 Dead. Even within multiplayer competitive games, some of them have the players progressing and getting more powerful during play: players get more lands and cast more powerful spells as a game of Magic: the Gathering progresses, while players field more powerful units in the late game of Starcraft. Then there are MMOs like World of Warcraft that clearly have progression built in as a core mechanic of the game, even on PvP servers. So in addition to single-player experiences like your typical Final Fantasy game, we’ll be talking about these other things too: basically, how do you balance progression mechanics?

Wait, What’s Balance Again?

First, it’s worth a reminder of what “balance” even means in this context. In terms of progression, there are three things to consider:
  1.  Is the difficulty level appropriate for the audience, or is the game overall too hard or too easy?
  2. As the player progresses through the game, we expect the game to get harder to compensate for the player’s increasing skill level because they are getting better; does the difficulty increase at a good rate, or does it get too hard too fast (which leads to frustration), or does it get harder too slowly (leading to boredom while the player waits for the game to get challenging again)? 
  3. If your avatar increases in power, whether that be from finding new game objects like better weapons or tools or other toys, gaining new special abilities, or just getting a raw boost in stats like Hit Points or Damage, are you gaining these at a good rate relative to the increase in enemy power? Or do you gain too much power too fast (making the rest of the game trivial after a certain point), or do you gain power too slowly (requiring a lot of mindless grinding to compensate, which artificially lengthens the game at the cost of forcing the player to re-play content that they’ve already mastered)? 

Why Progression Mechanics? 

Let's consider what is the purpose behind progression. What is it useful for?

Ending the game 

In most cases, the purpose of progression is to bring the game to an end. For shorter games especially, the idea is that progression makes sure the game ends in a reasonable time frame. So whether you’re making a game that’s meant to last 3 minutes (like an early-80s arcade game) or 30-60 minutes (like a family board game) or 3 to 6 hours (like a strategic wargame) or 30 to 300 hours (like a console RPG), the idea is that some games have a desired game length, and if you know what that length is, forced progression keeps it moving along to guarantee that the game will actually end within the desired time range.

Reward and training for the elder game

In a few specialized cases, the game has no end (MMOs, Sims, tabletop RPGs, or progression-based Facebook games), so progression is used as a reward structure and a training simulator in the early game rather than a way to end the game. This has an obvious problem which can be seen with just about all of these games: at some point, more progression just isn’t meaningful. The player has seen all the content in the game that they need to, they’ve reached the level cap, they’ve unlocked all of their special abilities in their skill tree, they’ve maxed their stats, or whatever. In just about all cases, when the player reaches this point, they have to find something else to do, and there is a sharp transition into what’s sometimes called the “elder game” where the objective changes from progression to something else. For players who are used to progression as a goal, since that’s what the game has been training them for, this transition can be jarring. The people who enjoy the early-game progression may not enjoy the elder game activities as much since they’re so different (and likewise, some people who would love the elder game never reach it because they don’t have the patience to go through the progression treadmill).

What happens in the elder game?
 
In Sim games and FarmVille, the elder game is artistic expression: making your farm pretty or interesting for your friends to look at, or setting up custom stories or skits with your sims. In MMOs, the elder game is high-level raids that require careful coordination between a large group, or PvP areas where you’re fighting against other human players one-on-one or in teams, or exploring social aspects of the game like taking on a coordination or leadership role within a Guild.

In tabletop RPGs, the elder game is usually finding an elegant way to retire your characters and end the story in a way that’s sufficiently satisfying, which is interesting because in these games the “elder game” is actually a quest to end the game!

What happens with games that end?

In games where progression does end the game, there is also a problem: generally, if you’re gaining power throughout the game and this serves as a reward to the player, the game ends right when you’re reaching the peak of your power. This means you don’t really get to enjoy being on top of the world for very long. If you’re losing power throughout the game, which can happen in games like Chess, then at the end you just feel like you’ve been ground into the dirt for the entire experience, which isn’t much better.

Peter Molyneux has pointed out this flaw when talking about Fable 3, where he insists you’ll reach the peak of your power early on, succeed in ruling the world, and then have to spend the rest of the game making good on the promises you made to get there… which is a great tagline, but really all he’s saying is that he’s taking the standard Console RPG progression model, shortening it, and adding an elder game, which means that Fable 3 will either live or die on its ability to deliver a solid elder-game experience that still appeals to the same kinds of players who enjoyed reaching that point in the first place.

[This article was adapted from Ian Schreiber's course, Game Balance Concepts.]

Ian Schreiber has been in the game industry since the year 2000, first as a programmer and then as a game designer. Also an educator since 2006, Ian has taught game design and development courses at a variety of schools, and on his own without a school. He has co-authored two books, Challenges for Game Designers and Breaking Into the Game Industry.

Thursday, April 4, 2013

April 2013: Leveling

Hi!  While my group at the Games.com HackAThon were discussing our game, we had a discussion about levels...  about whether or not we needed levels in the game.  For me, I automatically think a game has levels but there are games, even RPGs, without levels.  I can remember arcade games that would go on infinitely until you messed up.

But usually, a game has levels that get progressively harder and harder.  This topic is related to last month's topic of Pacing.  In a puzzle game, the later levels are supposed to be harder than the early levels.  In a RPG, new content is level-locked.  You can't learn something or go somewhere until you reach the appropriate level.  The level indicates your dedication to the game.  It's a way of comparing yourself to others and the act of leveling up gives you a feeling of accomplishment.

I jumped into the beta of Age of Wushu, which has been reported to be a MMORPG without levels.  It's what you called "skill-based," which to me is kinda like levels in that you have to learn the first skill on the skill tree before mastering more advanced techniques.  What are the advantages?  I guess you're customizing your play experience.  If you want that skill, you can go down that path and you can do it at your own pace.

What do you think?  Which way works out better:  levels or no levels? 

Monday, March 18, 2013

Phases of Playtesting (Part II)

In Part I of this article, game design researcher Joe Mauriello describes the phases of playtesting as a way to hone the game system.  In Part II, he elaborates on the final stages of playtesting and how to learn from player feedback.

Early Development Test

Develop should progress with testing in mind. That means setting development goals in accordance with the playtesting questions you’ve uncovered from previous sprint playtests. Early in development, the designer should be focused on heart of the game’s system rather then trying to touch on every aspect of the game. An inexperienced game designer might be eager to get their ideas into code right away and see it come to life on the screen. Resist this impulse. Identify your most risky assumption and figure out a way to test it. For example: Perhaps you wish to build an open world RPG with an innovative battle mechanic. Rather than focus on what you know, for example on how the character moves around the open world, figure out the fastest way you can test that battle mechanic. You may just need some paper and a spreadsheet.

In the early phases of testing, it’s important to get to know your system’s dynamics. Dynamics are the result of your designed game mechanics interacting with one another.  In other words, it's your game system brought to life. Observe the players' decisions within the system. Are they in line with your expectations? Is your system breaking down because the player is doing unexpected things? If you are trying to capture a certain aesthetic, or the mood or feeling that arises from the dynamics of the system, but you don’t have much in the way of art, it might be helpful to give them a little flavor and context as to the role they are playing and the world the game is set in. It’s fine to do that, just avoid talking about the system’s dynamics. At this point, these will only be your assumptions. It’s more valuable to watch the dynamics arise through game play.

Test results during this phase will inform game mechanics and get you closer to your design goals. As early development progresses, you’ll be testing less on paper and more on the final system. Even if you have a substantial portion of your game implemented it may still be useful to conduct paper tests every now and again. Especially if something isn’t working and you need to pivot some aspect of the game.

Late Development test

As development progresses and decisions about the game system are being finalized, your focus will shift away from dynamics and towards the player’s comprehension of the game and it’s usability. At this point, playtests become more and more hands off and observation focused. Specifically on sources of confusion, unintended frustration, and the player’s overall feelings towards the game.

The game is further along in development at this point and you may be more heavily invested in it. As the designer, you’ll likely hope that they are enjoying themselves but don’t forget to be objective. Don’t be so eager to finish it. Pay attention to how players are feeling and reacting emotionally. Facial expressions and vocal utterances can tell a lot about how users are experiencing your game. If players aren’t enjoying themselves, be glad you caught it during testing. Playtest Participants can be brutal and silly. They can make suggestions that seem to have nothing to do with the game’s direction and fixate on aspects that you don't feel are important. It's crucial that you leave your preconceived notions and your ego out of the test. Don't try to defend the game and be an objective listener, it’s tougher than it sounds. Users are giving feedback based on their experience so patience is essential here. Focus on how their comments relate to your game. Moments of unintended frustration are issues that need to be addressed.

Test results during this phase should help you clarify the game’s interactions. Perhaps you need to add a bit more polish to the tutorial, maybe some of the interactions in the game require more visual feedback or larger rewards, balancing might need tweaking, etc. Tie up your loose ends before your game is released into the wild.

Making Feedback Useful

Playtesting is a vital part of the iterative process. Write down your findings and consider giving out a survey with scorable questions. Once you've completed a playtest, document the results in order to determine the best course of action. Categorize the feedback collected, identify the area that a player is commenting on and organize it into the different aspects of your game like art, sound, animation, gameplay, feedback, plot, theme, and whatever else might suite your game. Be sure to take note of everything said. Even if something seems ridiculous, it might help give an issue or game play a new perspective. You probably had an idea of what you planned to do next but once you compare that with your feedback you might decide to shift course. Try to have playtests build on one another and compare results from one playtest to the next.

 Joseph Mauriello is an award winning game designer, educator, and developer who's been working in the games industry since 2006. He's created games for Google as well as major motion pictures. Joe currently is helping to usher in the next generation of educational games as a game design researcher for Amplify Learning.




Wednesday, March 13, 2013

Phases of Playtesting (Part I)

In this article, game design researcher Joe Mauriello describes the phases of playtesting as a way to hone the game system.


Playtesting is a core component of my everyday work as a game design researcher at Amplify Learning.  We are attempting to build the next generation of educational games.  Our mission is to build games that are first and foremost fun, while also conveying learning content and critical thinking through the game system.  While a lot of work has been done in this area, there is no canon of educational games that do this successfully. This leads us to make a lot of assumptions while designing our games.  To help ensure success, we’ve integrated playtesting directly into our development process. We test every two weeks as a sort of capstone to our development sprints. This is the first time I’ve experienced such tight integration of playtesting and development and after seeing the results, I’ve become an advocate.  In the other places I’ve worked, testing has not been so tightly integrated. It wasn’t because people didn’t see value in the process, rather, there was a lack of understanding of how it fit into the development process.   I hope to help clarify that in this article.

Just to clarify, playtesting is not the same as QA testing. In fact, when conducting a test, I generally ignore the bugs unless it interfered in some critical way with what was being tested. The goal of playtesting is to hone the game system.

I find it helpful to break development into three phases each with it’s own testing goals.  It not always obvious when you are shifting from one phase to another. In fact different aspects of the game might be in different phases at the same time.  What’s important here is how to focus your attention and how your findings are valuable to the game’s development:  
  1. During pre-production we test our assumptions about concepts and subject matter.  This occurs even before we start the design process. We refer to tests during this phase as mental model tests.  During this phase of development we are selecting and building tools.
  2. Early development tests help us understand the dynamics our game system and help us find the fun within them. During this phase of development we are implementing the game system.
  3. Late development tests help us find sources of confusion and unintended frustration.  During this phase we tighten the screws and polish the game.

Mental Model Test

A mental model test addresses initial assumptions:  Does our target audience like “X” style of game?  What affordances do they bring to games of this type?  Since we are making educational games, we’ll also test what knowledge our target audience is bringing to the game.  This type of test is akin to market research. 

Don’t be put off from doing this type of test because you have what you think is an original idea. Talk to your peers about your idea.  This type of research can be done through conversation.  Focus on what the player expects from the genre or theme you are working in. Understanding a player’s assumptions will allow you to make informed decisions within the framework of your original idea.  Asking these questions is going to get you thinking about your idea in new dimensions.

Test results during this phase will help you narrow down your concept and find where you want to express yourself through the game’s design.

Joseph Mauriello is an award winning game designer, educator, and developer who's been working in the games industry since 2006. He's created games for Google as well as major motion pictures. Joe currently is helping to usher in the next generation of educational games as a game design researcher for Amplify Learning

Wednesday, March 6, 2013

March 2013: Pacing

Hello!  I was at a local IGDA meeting when the speaker remarked that great games are not always original ideas, but that the game designers had all the elements, right pacing, and balance to create a great game.  In fact, we have a long honored tradition of building on top of other games, in particular board games and other social games.

I remember loving a casual game called Fairies.  Yes, it was the same gameplay mechanic as Chuzzle. There was just something about the theme, the story, music, and pacing of Fairies that really appealed to me.  While I knew about Chuzzle, the whole fuzzy balls and chemistry beakers never appealed to me and I felt that the difficulty ramped up unevenly.  I have played other classic puzzle games like Puzzle Bobble and have experienced uneven levels.

In bigger games, one might think about pacing as lulls and highs, or variety in gameplay.
  • How would you define pacing in videogames?
  • How does pacing affect the player experience?
  • How do you control pacing in videogames?
  • What would you consider to be great pacing?
  • What games are good examples of great pacing?

Friday, March 1, 2013

Are Badges Really All That?

In this article, game designer Sande Chen discusses the importance of badges in games, gamification, and in real life.

While working as a game designer, I've had to come up with a lot of badges, titles, or achievements.  A badge or achievement can be a delightful surprise, especially for players who don't go out of their way to collect every badge.  And badges are a great addition for completists, who now get to go through the game again but with an entirely different aim.

Badges are cool if they make the player look at the game another way and encourage exploration.  Badges can track progress and indicate to others how many times a player did an awesome video game feat.  It's all part of our instant infographic world.  But badges are not so cool if they're for lots of repetitive actions (like clicking a button) or paying money into the game. Well, that just shows how much time you've wasted or how much money you've spent, possibly...

Gamification gurus extol the use of badges and sure, people will do things for bragging points.  While status is important, I'm not utterly convinced that badges would motivate someone to do something s/he doesn't want to do.  For instance, if a hotel placed me in a room the furthest away from the elevator and told me I would get the badge of "Hall Strider" for walking down a particular hallway 10 times, I don't think I would care too much about that badge...  unless of course it came with an economic incentive, like 10% off my hotel bill.

Most of the time, in real life, badges or titles are tied to economic or social motivators.  Getting "Employee of the Month" can translate into better performance reviews and a raise.  And with each move up the corporate ladder, you get a new, distinguished title.  If you get other badges or titles at work unrelated to economic incentive, it's probably all in fun, some kind of in-joke among co-workers.

If you're aiming to be Mayor of an establishment on Foursquare, it could be for the discounts the place gives to the Mayor,  like any business would give to a frequent customer.  Or it could be a social rivalry among friends.  If suppose a celebrity went on a talk show and declared it cool to get "Hall Strider," I bet the hotel wouldn't have any trouble getting people to accept that room now that the badge of "Hall Strider" has social status.  No doubt people would aim for "Hall Stalker" and further.

Yes, designers can successfully incorporate these social rivalries and instead of economic motivators, give gameplay motivators.  Badges can be fun elements, but badges in itself do not equal fun.  Just because there are badges doesn't mean people will want those badges.  If your gamification effort is based upon giving out badges, then take a look at the core activity and ask yourself, is this fun?  If you're giving out badges for something completely not fun like undergoing root canals, the simple act of giving out badges or smiley stickers is not going to drive up demand for root canals.  That's when it might be a good time to re-evaluate the project and see how gamification, not badges, can help you.

Sande Chen is a writer and game designer whose work has spanned 10 years in the industry. Her credits include 1999 IGF winner Terminus, 2007 PC RPG of the Year The Witcher, and Wizard 101. She is one of the founding members of the IGDA Game Design SIG.