Friday, October 16, 2015

Non-mechanic: Tweaks and Changes

A Time For Changes

It's that time, friends and readers!  I mentioned way back in the other boring stuff entry that when stuff changed, I would be above-board about things that had changed.  Well, some of those changes have come to pass, and this post has just been published immediately after those edits.

Some of this has happened because I stopped posting Game Mechanics Pokedex entries to the corresponding topic on the Unity Forums.  The user interaction was so thin when I was prompting for it, that it simply wasn't doing any good.  I stopped prompting for feedback from my colleagues, and almost immediately after, got tons of feedback.

Counter-intuitive...but I'll go with it.  The point, as said before, is to provide a helpful overview of common game mechanics so that designers can create better games.

Anyways, to the changes!


  1. Quick-Time Events - In "What Makes the Mechanic Distracting?", added a bullet-point for a criticism of QTEs in general, failing to the beginning of a sequence.  My thanks to BoredMormon from the Unity community for that suggestion.
  2. Also in Quick-Time Events - I missed a Designer Consideration, the "mean margin" across a QTE Sequence.  It's a useful datapoint, because it correlates directly to the difficulty of a sequence; if you don't have enough time to make the next action, it affects how the player performs the sequence.
  3. In Leveling Up - I added a reference to the TVTropes page for 'Character Level', as there are additional cases of how the mechanic is used there.  Of note - TVTropes is primary a writer-based resource, approach it as a game design resource with caution.  Also, TVTropes will ruin your life.

#06: Event Flags AKA Gatekeepster

About the Mechanic

Unlike many other game mechanics, Event Flags are less about teaching the player some real-world skill, and instead serve to keep track of the state of the world in a work.

Event flags are simple things; if something has happened, a 'flag' is set from false to true, signaling that the event that correlates to the flag has in fact occurred.  Usually, a single work that takes place in a contiguous world has a number of event flags.  Typically, the world state itself responds to the state of the flags; a location may have one set of NPCs when all event flags are false; at a later state, the NPC dialogue will have changed, some NPCs may be missing, and others may be present.  This results in what appears to the player to be a qualitative feedback that reinforces their in-work actions.

Event flags are important, because while they don't teach a player a new skill like most other mechanics covered in the Game Mechanics Pokedex, they solve a problem for the player - the "Paradox of Choice."  The human mind can comfortably handle less than four things in short-term 'working memory' at once; any more tasks than that, and the cognitive load becomes too much to bear, leading to wanting to do something simpler, thus disengagement from your work.

In terms of designing a work, Event Flags are usually a go-to tool when trying to tell a linear story.  Event Flags are most often employed to enforce causality, as discussed above.  I call such structures, Event Threads - individual flags denote a series of causally-linked events.  

In other works, it's fully possible that sequences exist concurrently - for the sake of having a convenient name to talk about this, I call Event Threads with multiple, concurrently active Events, Event Deltas, due to how real-world rivers diffuse through deltas.

Finally, a common high-level pattern in Game Design is something called a 'convexity'.  A single choice leads to more choices, which expand to a certain point...then begin to contract, back to a single choice that counts as the beginning of the next convexity.  This is a valid structure for Event Flags, and as a result I call this setup an Event Convexity.  Any time an Event Delta is discussed, you could substitute an Event Convexity for the same effect.

For the designer, Event Flags, Sequences, and Deltas are a tool with which to think of the flow of the work.  Most mechanics focus on what exists between events, specifically on how the player is accomplishing a goal.  Bearing in mind that Time is the fundamental currency of game design, it is a worthwhile concept to consider that individual events require an amount of time to trigger.  All of the challenges of a segment of the game coalesce at that endpoint, when the flag gets triggered.

That being said, a word of caution: Event Flags, Sequences, and Deltas focus on the endpoints of an activity; when we design a game, most of care does, and should, go to everything between endpoints.  "What is the player doing?" should be our primary question!  It can be tempting to spend a lot of time on Event Flags, but don't.

Last note: Event Flags are well-discussed on TVTropes.

Referee Information / Data Structure

Event Name
Event State (True/False)

Thread Name
Event List
Thread State = Event 1 & Event 2 & ... Event N (& refers to AND operations)

Designer Information

Event Duration - How long does it take to complete this individual event?
Thread Time = Event Duration 1 + Event Duration 2 + ... + Event Duration N


Event Complete = Event State is True
Thread State = Terminal Event is Complete

When Is This Mechanic Engaging?

  1. As noted above, when you need some way to imply causality of events that extend beyond the player.
  2. Additionally, when to the player's perspective, the world meaningfully reflects the state of the event flag.  The player has to be aware that the world has changed for some reason.

When Is This Mechanic Distracting?

  1. When a work has the action already well-divided in some non-contiguous paradigm; if you're designing a game with 'levels' as the unit of the player's action, you typically will not need an event flag.  Including event flags anyways results in backtracking, which if not well-executed, becomes off-putting to the player quickly.
  2. When an event flag is triggered with overly subtle feedback.  The end result of such a problem will be that the player doesn't even know something happened.
  3. When an event flag is triggered with disproportionate feedback in terms of game difficulty.  The player will interpret this as a 'Difficulty Spike out of nowhere', thus leading to disengagement.
  4. In an Event Sequence or Event Delta, when a consequence has tangible effect on the world during the sequence, but none when the Sequence or Delta is completed.  I call this the 'BioWare Problem', as it's typical in their more recent works, as noted in the Game References below.

Game References

  1. Dragon Quest I, one of the first installments in JRPG literature uses an Event Sequence in a simple form.  The sequence consists of if the Dragon+ guarding the princess has been killed, if the Dragon Warrior has picked up and carried the Princess, and if the Princess has been taken back to Tantegel castle.  The NPCs in the various towns remark on the state of this Event Sequence - a great, memorable nod to this, involves going to an Inn with the Princess in your arms.  Such a feat results in extra (funny!) dialogue.
  2. Pokemon from Nintendo has great applications of individual Event Flags as a gating feature.  You cannot pass Veridian City in the original Red/Yellow/Green/Blue versions of the game, until you have defeated Brock, the first Gym master.  Similar event gates can be found throughout the game, culminating at the entrance to Victory Road, a dungeon that immediately preceeds the Elite Four gauntlet.
  3. The Legend of Zelda franchise typicallly represents completed event flags to the player in their inventory as a collected MacGuffin of some kind, whether it's a medallion, a crystal containing a trapped maiden, or whatever.  Because the Zelda franchise is predicated on the key-and-lock mechanic, despite these not being usable items, it still retains conceptual consistency, this setup reinforces the work in the player's mind, despite being mechanically completely different.
  4. Star Wars: Knights of the Old Republic, a Western RPG from BioWare in 2004, uses Event Convexities often and well.  A notable case is on the ocean world of Manaan - the Sith Empire and Galactic Republic are both vying for political favor to secure a powerful healing agent called Kolto that can only be mined on that world.  Your actions will bring you into conflict with the Sith, and as a result the Selkath government will have you on trial multiple times on this world - even the shortest possible path through Manaan ensures you wind up in court twice.  There are other possibilities as well; if you go to Kashyyk first and meet Jolee Bindo, his personal sidequest involves being a lawyer who argues on behalf of an old war buddy of his from the Mandalorian Wars.  In all events, before you leave Manaan after having obtained the Star Map hidden there, your deeds will be recounted in the final court sequence, reinforcing that the world remembers your deeds.
  5. The Mass Effect franchise from BioWare has a particularly interesting and powerful application of Event Flags - they persist across games, and affect future games.  If a party member dies in Mass Effect 1, they cannot be interacted with in future Mass Effect games you play based on that original save.  This has a profound effect on the final entry of the Mass Effect trilogy, during the allied species war against the Reapers.

Wednesday, October 7, 2015

#05: Gathering Currency and Purchasing Upgrades AKA Merchanimal

About the Mechanic

Purchasing Upgrades encourages players to practice a basic life skill - knowing how many resources you have on-hand, so that you can determine how much you can spend, how much you need to keep back, and further teaches the player to make plans to buy something expensive that the player will want.

You can't discuss purchases, without discussing currency; they're two sides of the same coin, and that pun was very intentional.  Originally, the plan was for currency collection to be its own mechanic, but that's unrealistic, because the exact manner of collection is unimportant; the fact that you can obtain currency is what enables you to make a purchase in the first place.

This mechanic can be considered another sub-mechanic of Incrementing a Score - unlike Gaining Levels, where you don't actually lose any score, just have previously-used score hidden, you actually consume a score to buy in-game perks.

Purchases are a well-rounded mechanic because they define a number of things.  Purchases define a success condition - if the player can buy what they want, they have succeeded.  Purchases define a failure condition - if the player can't gain money in a reasonable amount of time, they need to re-assess their strategy, so that they are gratified in a time that they feel is reasonable.  Purchases define an implicit goal for the player; that expensive object would be really helpful!  Finally, purchases provide for feedback of both progress and success or failure, in the form of handy numbers.

This gets to why the currency is important - the purchase itself is the end result of the mechanic.  In order to afford the purchase that a player wants, the player has to find a means to accrue a suitable currency.  

A player who feels secure with Gathering Currency and Purchasing Upgrades feels like they've mastered the economy of the work in question.  Likely, the player has a gut feeling on what an adequate rate of gain 'should' feel like.  The game designer best-serves their audience by erring slightly towards the longer-end of that gut feeling, so that the player can feel like their goal is met in a satisfying, but challenging, way.

Referee Information / Data Structure

Current Currency Amount
Event Currency Amount
Item Cost

Designer Information

Currency Gain Rate = Event Currency Amount / Unit Time
Time to Purchase = Item Cost / Currency Gain Rate


Victory: Current Currency Amount >= Item Cost
Failure: Current Currency Amount < Item Cost

When Is This Mechanic Engaging?

  1. When the player character is interacting with NPCs or other players; this simulates real-life economies, which is a practical point of the mechanic
  2. When you need a way to give the player a more implicit goal - buying something you want isn't necessarily something that needs to be written in a quest log, and is something you can usually rely on a player to remember, because it suits their interests.
  3. When you need to add some play time to your game.  Time is the fundamental currency that players deal with, and in real life, what you are paid is proportional to the amount of time you invest into something.  As Currency/Purchase systems are a simulation of real-life economies, this is a fact that, if properly balanced, actually improves your player's suspension of disbelief, because it's real and interacted with daily.  It's provable and about as realistic as you can hope to get.

When Is This Mechanic Distracting?

  1. The player seldom encounters NPCs who are interested in trade.  This is distracting, because this feels 'tacked on'.  Economies are very much social interactions, even in the Internet age.  I call this the Lone-Wolf Buyer Problem.
  2. The vendors do not offer items that are useful to the player.  If the player has no reason to use a shop, purchasing items is a superfluous feature; they are better-served to simply get advantages in other ways that the work allows for.  I call this the Knock-Off Rolex Problem.
  3. Similarly, money is too hard to come by.  If players cannot accomplish their implicit goal in a reasonable amount of time, they will deem it a waste of time, and move on.  After all - Time is the fundamental currency that we deal with our players in!  I call this the Bare Coffers Problem.
  4. On a related note, money is too easy to get.  If players can easily obtain things they want, there is no challenge, which does not help the player to feel as though they've mastered the economy of the work in question.  I call this the Welfare Hero Problem.
Note: The reason I have names for each of the problems, is because many games use currencies and purchases as a mechanic; few use them effectively, including some very well-established games that are considered masterpieces.

Game References

  1. The Legend of Zelda: A Link to the Past is a prime example of the Knock-Off Rolex Problem.  The most useful and expensive purchase in the entire game occurs at the very beginning of the work, one of the four bottles used to store restorative items.  Beyond that point, there's not really much of a point in collecting Rupees or making purchases.
  2. Final Fantasy XIII is a prime example of the Lone-Wolf Buyer Problem.  Final Fantasy XIII is notorious for being barely recognizable as a JRPG in the first place.  Through the game, the player will encounter random consoles that allow the protagonists to contact various Cocoon shops to purchase consumables, equipment, and crafting materials.  It's fully possible to play through the game without using the shop feature of the terminals, at all.  The only thing that the shop system in FFXIII got correct, was that if you know what to do and buy, you can create powerful advantages relatively early on by using the shop system.
  3. The game Half-Minute Hero handles money quite effectively in the Hero 30 mode.  The main way the character progresses is by buying armors and weapons, sometimes that have special effects including insta-killing certain enemy types, map mobility options like swimming in water, and more.  Notably, HMH tackles the Bare Coffers Problem in a specific level by setting the problem up - no one in the level has any money, including random encounters - and the player must complete quests while rewinding time in order to gain money and level up enough to defeat the stage's Evil Lord.
  4. Final Fantasy VII succumbs to the Welfare Hero Problem.  The game goes out of its way to ensure that the party has ample access to money, which makes the purchases nearly useless for casual play; grinding Materia, and exploring for special, unbuyable items is more useful to the player to advance through the work.  This applies with a caveat, however - in that work, shops don't fulfill their 'usual' function, which is to create a goal.  Instead, shops serve player customizability.  Virtually all Materia is available throughout Gaia through shops, which means if you had to ditch some Materia along the way (you have ample carrying space too), you can easily re-buy what you need, to accomplish a build on a character.

Monday, October 5, 2015

#04: Incrementing a Score AKA Gumby

About the Mechanic:

Score systems are a feedback mechanism based on the idea that a bigger number is better.  Specifically, players who are better at a game typically have a higher score.

Scores can be incremented in any number of ways; it may be a good idea to read some other Game Mechanics Pokedex entries to gain ideas of how this can happen.  

This mechanic could be considered a super-mechanic of Gaining Experience.  Incrementing a Score is more abstract than an XP system - you gain score by doing something, which reflects your skill, and has no other effect on gameplay.  Compare this with Gaining Experience - you gain XP by doing something, which counts towards a character level; often, leveling up resets the amount of XP you have towards your next level, even though the total is often stored for reference.

For a time, Scores were useful as both a social component to games, and a way to encourage more monetization.  In Arcades - real-world places that hosted numerous game cabinets, where people would go to play video games - in addition to gaining a score, if you had one of the top 10 best scores on a cabinet, you could also add some initials to your score, thus inspiring other people to feed their precious pocket change to the cabinet in exchange for the ability to attempt to either get higher on the list than you, or take the #1 position.

In the modern day, Incrementing a Score is more rarely used, because it's less useful to most designers than it used to be; since we don't feed our consoles or PCs quarters, the social impact of getting on a top 10 scores list no longer exists, and it makes less sense for monetization.  The only thing a Score system provides now is feedback.  That being said, the feedback aspect of Incrementing a Score is deceptively powerful.

As a designer, you want to be mindful of Scores on two levels - in a 'sequence', and in the context of a complete play-through of the game.  In this mechanic, a 'sequence' refers to a series of related challenges, what in the old days we might call a 'level' (unrelated to character levels.)  Each sequence has a number of events; doing something that the player should do rewards some amount of points.  Ideally, a player has to do certain things to complete a sequence; when designing a level, the player will ideally have a certain amount of score.  Typically a player who fails before the end of a sequence has a lower score than where they should for that point in the level.  The target score for the game is therefore a sum of the target scores of each of the levels.

Referee Information / Data Structure:

Current Score
High Score (1...n)

Designer Information:

Sequence Score Target
Game Score Target
Event Score Rate = Score / Event
Sequence Score Rate = SUM(Event Score Rate in Sequence Events)
Game Score Rate = SUM(Sequence Score Rate in Game Sequences)
High Score Beaten = Current Score > Best High Score


Failure = Player Score < Target Score (Implicit) OR
Failure = Player Score < High Score
This mechanic has no hard 'success' condition.

When Is This Mechanic Engaging?

  1. You need a simple way to tell players how well they're doing - as above in the text analysis, bigger numbers mean the player is doing better.
  2. You need an overarching implicit goal - players can beat the game, but to keep them coming back or provide some other form of fun, beating the High Score lets them have a reason to keep trying.

When Is This Mechanic Distracting?

  1. The score does not matter (AKA The Whose Line Is It Anyways? Rule) - If the points do not matter, you are giving useless feedback.  This fact will not be lost on the player; the result will be the player ignoring the score.
  2. Event Scores are not reasonable and/or internally consistent.  Typically, more difficult tasks reward higher scores for the event.  Additionally, similarly difficult events should give the same contribution towards the player's score.

Game References:

  1. In Shovel Knight, players gain score for picking up various gems found through the course of the game.  They can be gained by digging up stone piles, defeating enemies, putting out camp fires, just lying out, and more.  In addition to being a practical measure of how good the player is at exploring the map and finding things to dig, they can be used to Purchase Upgrades (a future mechanic that will be analyzed.)
  2. Super Mario Bros. for the NES is perhaps the most well-known game that uses Scores as a primary way to communicate to the player.  The rewards for individual actions, such as defeating enemies, or picking up coins and powerups is lavish, but reasonable and internally consistent.  That being said, most levels have a very low target score - it's usually possible with careful play to complete levels without gaining any score at all.  As a result, the score can be safely ignored - Gaining Continues (another future mechanic) or picking up powerups is usually much more worthy of the player's attention.
  3. Guitar Hero does a good job of using Scores to communicate the player's mastery of a song.  As you more accurately hit notes, you will gain a score multiplier that increases the Score yield of individual events.  This is important not only for feedback, but for reinforcing that the player execute the song consistently - consistent execution means you can repeatedly get the best possible score for the song.
  4. The first Mega Man had a Score system; this was dropped in subsequent installments of the franchise.  Hard information is difficult to come by for why this decision was made, but this blog speculates that it was excised because it was a poor indicator of the player's progress.  Mega Man titles are known for their high difficulty; it's fully possible that the player fail through little to no fault of their own.  Thus, a Score would be deceptive feedback.  Instead, in each installment, Mega Man's ever-expanding toolkit of abilities gained from defeated Robot Masters proves to be a much better way to communicate the player's progress in metonymic terms.