Setting Up Flag Systems in Games
Most indie games don't actually need complex quest systems or dialogue trees. What they need is a clean flag system. A flag system is just a way to track whether something has happened in your game — a door is open, a boss is dead, a cutscene has been triggered, a collectible is gone. It sounds trivial until you've spent three weeks debugging why your NPC keeps giving you the same tutorial text for the tenth time. I'm going to walk through how I actually set these up in practice, not how textbooks describe them. The gap between theory and shipped code is where the real problems live.
What Is Flag In Game
Flag In Game refers to any mechanism that tracks a true/false or multi-state condition within a game's logic. It can be as simple as a single boolean, or as complex as a bitmask tracking dozens of interconnected states. The term comes from the early days of computing where flags were literally binary indicators in processor registers. Game developers kept the word because it's faster to type than "game state tracking variable" and everyone knows what it means. The implementation lives in your game's state manager, save system, or world object. Where you put it matters more than most people admit. I'll get to that.
How to Build It Right
Start by deciding whether your flags are persistent or session-only. This is the mistake that breaks 90% of first-pass implementations. If you don't separate them early, you'll end up with flags from a previous playthrough bleeding into a new one, or local combat flags saving to disk and corrupting your save file three hours later. Persistent flags go into your save data structure. These track story progression, character state, collectible completion. Session flags stay in memory and reset on reload. These handle combat states, temporary buffs, NPC awareness windows, triggered events that shouldn't replay. Here's a straightforward structure I've used across multiple projects:
Get the Full Details
Define a Flags class or namespace. Give it methods, not direct variable access. A pattern like SetFlag(string name, bool value) and GetFlag(string name) keeps your code clean. The string key approach is easy to prototype but costs you autocomplete and refactor safety. For small games it's fine. For anything over five thousand lines of gameplay code, switch to an enum-based system or a constants file. That leads to the bitmask approach, which is worth understanding even if you don't use it. Instead of storing each flag as a separate boolean, you pack multiple flags into a single integer where each bit represents one condition. One int can hold 32 flags. A long gives you 64. This was standard practice in older engines and still appears in mobile and console games where memory is constrained. The tradeoff is readability. A bit shifted left by five positions tells experienced developers what's happening, but it looks like noise to anyone else.
The Edge Case That Almost Broke a Release
On my last project we had a flag system tracking whether players had seen certain cutscenes. Everything worked in the editor. During external playtesting, someone reported that a two-minute cutscene would replay every time they exited to the main menu and re-entered the chapter. The flag was set correctly in the session — I verified it with debug logging. The problem was that the save system only persisted flags during scene transitions, not during full application reloads. So when the player hit main menu, the entire runtime state destroyed itself, and the flag reset to false on reload. The fix was to also save and restore the flag state during application lifecycle events, not just scene loads. We added a dedicated OnApplicationPause and OnApplicationFocus handler that wrote persistent flags to a separate lightweight file. It added maybe twenty minutes of dev time and saved us from what would have been a day-one patch. If you're building for platforms that support background app suspension — iOS, Android, some console stores — this distinction between scene-level persistence and process-level persistence is critical. Your flag system needs to survive both.
Counter-Intuitive Things Beginners Miss
First: don't over-abstract your flags early. A lot of developers build elaborate flag managers with inheritance hierarchies, event buses, and observer patterns before they have more than twelve flags in the game. Twelve flags does not need an event bus. It needs a dictionary or a struct. Complexity should be earned through actual pain, not anticipated pain. I've watched teams spend two weeks building a flag management framework that they then abandoned because the game design changed and the whole thing became irrelevant. Second: flags that gate content are dangerous. If a player can never re-access a region because you set a flag when they left it, you've created a softlock. Always implement a way to check which flags are set at any time, and always provide a debug or developer override to reset them. Even if you're sure your logic is perfect, it won't be. On my second project a single flag flip in a branching dialogue tree locked an entire quest line. We spent six hours in QA trying to reproduce it before realizing the issue path was reachable through an undocumented interaction. Third: consider your serialization format. Plain booleans serialize cleanly. Bitmasks require bitwise operations during read and write. If you choose JSON for saves, bitmasks become strings of numbers that are harder to inspect and debug. Binary serialization handles bitmasks efficiently but makes save corruption nearly impossible to diagnose without a custom editor tool. Pick based on what kind of bugs you'd rather deal with.
When Flags Are the Wrong Tool
Not every state problem is a flag problem. If you need to track ordered sequences — "player must collect A, then B, then C in that order" — a flag system with individual booleans for each item will work but quickly become unwieldy. A state machine or event queue is cleaner. If you need to track quantities or progress toward a threshold — "collect ten keys" — a counter is better than ten flags. Flags are for yes-or-no conditions, not for counting or sequencing. And if your game has multiplayer synchronization needs, flags travel a different path entirely. Each client needs to receive flag updates from the server, and you need to handle the case where two clients set conflicting flags simultaneously. This is where most multiplayer flag implementations fail. The server should be the single source of truth. Clients report intent; the server confirms or denies. Anything else creates race conditions that are nearly impossible to reproduce in testing and will absolutely appear on launch day.
Flag In Game: Practical Checklist
Before shipping, verify these items. Persistent flags save across full application reloads, not just scene transitions. Session-only flags reset cleanly when the game reloads. No content-gating flag exists without a corresponding unlock or skip path. Your flag state can be inspected through a debug menu or console command. Your save system handles the format you chose without data loss during migration. Multiplayer flags are server-authoritative. And you've tested the specific edge case where the player triggers a flag-conditioned event immediately before the game pauses or loses focus. Most of these issues don't show up until someone plays the game exactly wrong, which is the only way they ever do.
