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!

Errata

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

Conditions

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.

#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

Conditions

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.

#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

Conditions:

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.

#03: Quick-Time Events AKA Panflash

About the Mechanic

Quick-Time Events are reflex-challenges for the player that simulate the character making some sort of highly time-sensitive reaction to an event.  

This mechanic can be considered a sub-mechanic of Beating a Timer, and shares many similarities to that mechanic as a result.  The difference is that QTEs typically experience different dynamics than a high-level Timer challenge - the internal margin, or time that the player has to succeed, is typically very small.  Additionally, the external margin, or time between QTE challenges is usually reasonably small as well.  There is a deeper implication, though - typically a single QTE is not a challenge, but a progression of QTEs, possibly interspersed with other challenges, is what the player encounters.

The skill players are taught is to rapidly and accurately respond to a stimulus.  QTEs are nearly always presented with a visual cue that informs the player that a QTE is occurring.  There's usually some sort of feedback on how long the player has to take the very simple action to satisfy the QTE, usually pressing a button.  Success and failure to satisfy the QTE is usually always presented as soon as one of those conditions occur.

QTEs can be stand-alone events, which represents the character reacting to something sudden occurring in the game world.  I'll be referring to this sort of QTE as a "Snap QTE."  This is the standard for which this mechanics analysis occurred in terms of both internal and external margin.

It's also possible that a QTE can consist of more than one event, that needs to be accomplished a number of times before the QTE expires.  I'll call this a "Machine-Gun QTE" as it requires rapid execution before the QTE time limit expires.  These QTEs generally have a slightly more generous internal margin for the player.

Concurrent QTEs represent a snap decision for the character.  The player can often only accomplish one QTE at a time; the QTE that 'succeeds' is the choice the player is going with, while there is no penalty for failing the other QTEs.  In this entry, I'll be referring to this sort of QTE as a "Branching QTE."  Because Branching QTEs represent a choice that must be considered, typically the internal and external margins for error are larger than other QTE types.

Finally, subsequent QTEs can provide a simplifed way of presenting that the character is doing a complex, technical task if presented in succession.  I'll refer to these QTEs as a "QTE Sequence."  Typically, the internal and external margins of error for the player are smaller than other QTE types in a QTE sequence.

Referee Information / Data Structure:

Start Time

Lifetime

Trigger Time

Successful = Trigger Time < (Start Time + Lifetime)

Player Information / Feedback:

Lifetime

Successful

Designer Information:

Internal Margin = Lifetime

External Margin = Start of QTE 2 - Conclusion of QTE 1

Conditions:

Victory = (IsSuccess)

Failure = NOT(IsSuccessful)

When Is This Mechanic Engaging:

1. QTEs work best when used in a time-sensitive situatoin.  This is because QTEs simulate the character making a snap reaction or snap decision.
2. When a technical challenge for the player is required, judicious use of QTEs can be an effective way of making a challenge require more attention and skill from the player.
3. QTE consequences work best when the severity for failure is low, as these are reflex-critical challenges.  As with Beating a Timer, typically a longer margin set allows for harsher consequences for failure and slightly lower rewards; a shorter margin set allows for softer consequences and slightly better rewards.

When Is This Mechanic Distracting:

1. When a situation isn't time-sensitive or otherwise has low tension, and thus little need for a player to express their reaction times.
2. When a task for the player is already highly-technical, the additional reflexes that a QTE requires can make the task unfairly weighted against the player, and as a result alienate the player in that part of your game.

Game References:

1. The Guitar Hero series, and most rhythm games, are actually entire games built with QTEs - specifically, QTE sequences - as the primary mechanic.  The QTEs are sequenced based on the rhythm of the audio track, which helps the player have better insight to when they need to trigger the QTEs.
2. The Legend of Dragoon is an example of how QTEs can make an otherwise non-technical challenge - a turn-based RPG battle - more technical with the "Addition" system.  Attacks require a QTE Sequence to strike for their optimum power.  Additionally, attack item effects can be boosted with a Machine-Gun QTE in this work.
3. Final Fantasy XIII-2 is a perfect example of the Snap QTE, Branching QTE, and Machine-Gun QTE in the "Cinematic Action" sequences.  These occur during cutscenes that the player can influence the outcome of, by either completing a single QTE, making a choice of concurrent QTEs, or spamming a button to accomplish a QTE.
4. In Call of Duty: Advanced Warfare, the infamous "Press X to Pay Respects" is a critical example of how not to use QTEs.  The situation in question is a funeral for a fallen comrade.  This is a somber event that is entirely story-driven.  There is simply no need for a reflexes challenge in this situation.
5. In the Super Mario World ROM hack, Kaizo Mario World, an anti-usage of this mechanic comes into play: immediately when the game starts, a Thwomp comes crashing onto the player with nowhere for the player to go to dodge it.  If you jump, you will die in the introduction to the game.  This is usually known by the trope, Press X To Die.
6. In Metroid Prime 3: Corruption, a counter-use to the "Press X To Die" situation - in this case, Press X To Not Die - is presented: early in the story, Samus Aran is corrupted by a mutagenic element called Phazon.  She's given a special suit to compensate, but periodically her Phazon corruption will spiral out of control.  In a great example of a Machine-Gun QTE, she will have to spam her weapons to rid herself of the excess Phazon, otherwise you will get a non-standard Game Over where she will become a carbon copy of her nemesis, Dark Samus.

#02: Leveling Up AKA Experithar

About the Mechanic:

Within the context of a work, the levelup mechanic simulates the player character practicing something; the character's ability as a result is represented as a level (Lv. for short), while steps towards advancing the level are noted as experience points (XP for short.)  More usefully, the numeric parts of this mechanic often operate as feedback unto itself; typically an entity that is Lv.3 is less effective than one that is Lv.15.  If you have 80% of your XP bar full, you know you have a short way until your next reward (the next levelup.)

The 'skill' players are taught is to prioritize learning where or how to more efficiently gain XP.  Levelup mechanics work against the mechanics they are keyed to, and instead train players to be more efficient in their execution of high-level concepts.

The most consequential aspect of levelups is that this mechanic implements concepts of a psychological construct known as a Skinner Box.  Levelups produce a habit due to an irregular reward schedule for actions that the mechanic is keyed to give XP for.  Presenting the player with XP information 'weakens' the Skinner box, but interestingly does not remove the effect from the construct.

Further, it's very rare in works for a player to be penalized XP for failing a challenge.  As a result, most implementations of levelup mechanics result in quick iterations that aren't repetitive.  If a task is failed, the mechanic requires you to take the player character and practice somewhere else, barring the effects of other mechanics.

Last note: Leveling Up is well-discussed on TVTropes as well!

Referee Information / Data Structure:

XP
XP to next level
Character level

Player Information / Feedback:

XP
XP to next level
Character level

Designer Information:

XPRate = Action XP / Action Time Investment
LvRate = XP To Next Lv / XP Rate

Conditions:

Victory: XP >= XP To Next Level
This mechanic has no common failure condition.

When Is This Mechanic Engaging?

1. It doesn't make sense for the player to be an 'instant expert' at something - The levelup mechanic simulates the character practicing that skill over the course of the work.
2. Player skill renders a work, or a section of a work, solvable in a trivial amount of time - be warned that it will require attention to game balance, as well as modification or addition of content, to increase the time to solve the game.  Levelups will only provide the player with a mechanical view and justification of this process unfolding.
3. You want to mechanically show the player character growing over the course of a work.

When Is This Mechanic Distracting?

1. The challenges of the work are explained as the player already being an expert - they have no need to practice them, as they know them.
2. Some high-level mechanic is a trivial action - trivial actions are presumably already mastered by the player character.
3. Too much time is spent 'grinding' - All uses of Levelups require the player finding and learning to find more efficient fonts of XP.  In playtesting, if players can't reach their levelup goals in a time that they find reasonable, it will lead to disengagement.
4. Similarly, the amount of time to gain a new level increases too sharply - The "Skinner Box" aspect of levelups works best when it eases the player into creating a habit; major changes in the numeric progression of the system can lead to serious disengagement.

Game References:

1. Dragon Warrior I is one of the prototypical JRPGs.  This game is built nearly entirely around grinding as the Dragon Warrior tries to save the continent of Alefgard from the Dragonlord, bent on conquering it.  The character is practicing fighting in general.  That being said, one of the primary complaints of the game is that it is "too grind-ey", particularly at late levels when the Dragon Warrior has conquered most challenges of the game.
2. Dissidia: Final Fantasy is a fighting game that uses levelup mechanics to impose a skill cap.  For instance, if you're great with one character, but are a low level, you will lack access to certain moves.  Additionally because of the stat-dependence of the game, your attacks will deal less damage, and your defenses less effective.  That being said, an extreme skill disparity can still result in a low-level character beating a significantly higher one, as the level/stat mechanics don't fully negate the role of player skill.
3. The Elder Scrolls V: Skyrim features levelups for high-level skills like schools of magic, speech, and sneaking, but does not present XP information; you merely get rewarded for practicing a skill.  "Skill-ups" are frequent at first, but get infrequent quite quickly; the game tries to mitigate this by including skill trainers that you can speak with to purchase instant skill-ups with in-game currency.
4. Planetside 2 features levelups under different names for your character.  Levelups don't affect your play ability in this case; PS2 is a MMOFPS that is nearly entirely-skill driven.  Rewards are often in-game currency that can be used to buy upgrades.  This is a great example of using Levelups to cultivate a habit, in this case of playing a character.
5. WarCraft III has Hero Units that can be 'built' at a special building for each faction.  These are powerful units with powerful abilities, but to be effective they need to be involved in combat.  This serves to shift the metagame away from the standard 'RTS' vision of having more, stronger units than the opponent, to instead prioritizing training heroes and having a unit composition that complements the hero's abilities and weaknesses.

Non-Mechanic: Information & Conventions

First things first - welcome to the Game Mechanics Pokedex!  This blog is my attempt to pool information about game mechanics that I either encounter or invent.

A Problem of Scholarship

One interesting thing about being involved in Game Development, is the lack of solid scholarship in the subject.  In some ways, games defy academic research, which means any particular concept probably has at least two names - which name you use, depends on who you're talking to.

Sadly, it's a problem I can't solve.  It's not my objective, either - I'm merely categorizing game mechanics in a (hopefully) useful and entertaining way.

Words, Words

First, my posts all have a common format.  This is to make sure that information is efficiently conveyed.  Usually a post will look like this:

About The Mechanic: A broad overview of what the mechanic is, what it does, and what it should do for the player.

Referee Information / Data Structure: A detail of data fields that compose the mechanic.

Player Information / Feedback: A detail of things the player needs to know to play with the mechanic.

Designer Information: Mathematical details about a mechanic that help a designer balance it in the context of their game.

Conditions: Under what mathematical circumstances do we change game state?  Commonly Victory and Failure are the two states I notate.

When Is The Mechanic Engaging?: When does it work?  Note that I don't use 'fun' - sometimes, anti-fun is helpful to a game, too.  The point is to make the experience worth the player's time, regardless of the emotion they experience.

When Is The Mechanic Distracting?: Games are built around the concept of Flow, an altered psychological state.  Distractions break flow; you could say, distractions are the anti-pattern to well-designed games.  When a mechanic is misused, it breaks Flow.  This section details ways I've observed for a mechanic to be misused.

More Words...

With the format out of the way, let's talk specific terms.

Mechanics are rules of a game - specifically, they're parts of a game state that are used to determine what happens next.  Mechanics consist of the state segment, but also some logic - typically mechanics provide criteria for failure, but can also change state on success as well.

Dynamics are how rules interact.  I try to meld dynamics into this Mechanics Pokedex as a matter of course - I find it useless to talk about a mechanic, without talking about the force it exerts on other mechanics that it may be paired with.

Conditions should be obvious, but games are always contingent upon the player's ability and agency.  This is what sets games apart from novels, or art, or T.V., or whatever.  In games, you can choose.  You can choose correctly, or incorrectly.  If you succeed, it's a Victory.  Less successful choices are Failures.  When a result has no effect, it's merely a State Change.  As my study of mechanics continues, this might get changed - if it does, I'll modify this, and add a blog post being honest about what's going on.

Feedback is how we communicate things to the player.  Games are fundamentally feedback loops.  If you're not communicating game state to your player, chances are good there's a flaw.  This Mechanics Pokedex should help you figure out what that missing feedback is!  How you choose to present it, though, is up to you.

Engagement/Distraction is another common set of words I work with.  Many designers talk about "Fun", but one has to ask - how do you measure "Fun?"  Some have tried, but it's ultimately subjective - there are shades of fun and non-fun.  Engagement/Distraction are more measurable - is the player processing our work?  If so, we can say they're engaged.  If they're complaining, if they put down the game and walk away, it's safe to say they're not.  While there are shades of engagement and distraction, it's easier to observe and talk about.  Further, to only talk about fun makes negative emotions 'invalid.'  Games are much more than agents of joy - they're how we practice life itself.

"The Work" is how I talk about an individual game, after introducing whatever work it is.  I try to avoid attacking, say, Skyrim or whatever - even though something has flaws, I'm talking about the work, not the idea.  I got this from an old, much more political job of mine.  I do this because no one, no matter how hardened of a professional you are, likes your baby to be called ugly.  In researching these mechanics, I'm not looking for the successes - those are obvious and well-known.  The failures of how mechanics are used are far more telling about the boundaries that a mechanic covers.

"Last" Word

This Mechanics Pokedex is a labor of love.  In the next eleven weeks, I want to add eleven more mechanics breakdowns.  This helps my community, and it's also helping me find a new game concept to work on.  More importantly, though, this blog is a living blog.  While my objective is not to discover a games vocabulary, to communicate effectively, I will have to have one.  The vocabulary I've chosen may not stick; it may morph.  If it does, I'll communicate it in a non-mechanic entry, like this, and update this.

Thanks for reading all of this, and I hope I see you and your comments around!