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