Visualizing Loops
Game loops drive the core functionality of a game, ensuring that actions, responses, and updates occur in a structured manner. While game loops exist conceptually in every game, representing them visually can help designers and developers break down complex processes, identify potential issues, and refine mechanics.
Game Flowcharts
Flowcharts allow us to represent decision-making processes and sequential actions.
Flowchart Symbols
When developing a flowchart it is helpful to follow the standard symbol definition. These definitions make it easy for everyone on the team to understand the basic flow of the loop.
| Symbol | Name | Meaning |
|---|---|---|
 | Oval | Start/End of a process |
 | Rectangle | Action or process step |
 | Parallelogram | Input / Output (key press, console message) |
 | Semi-Oval Rectangle | Delayed Event, waiting for action (input) before the event is called |
 | Diamond | Decision point (Yes/No, True/False) |
 | Trapezoidal Top | Indicates the start of a loop, such as a for or while |
 | Trapezoidal Bottom | Indicates the end of a loop |
 | Arrow | Direction of flow |
Using these symbols, we can construct a flowchart representation of Park Cleanup's core game loop.
Example Game Flowcharts
Park Cleanup is a casual puzzle/exploration game where players collect trash and dispose of it in designated bins to restore a park. The game is designed to promote environmental awareness while providing a relaxing, goal-oriented experience.
Core Gameplay Overview:
- Players explore an area of the park to find trash.
- They collect trash and take it to designated trash bins.
- Once the required amount of trash is disposed of, they can progress through the park's locked gate to the next area.
- The game continues until all park areas are cleaned.
To break down the structure of this game, we'll visualize two key game loops:
- The Gameplay Loop: The high-level cycle that governs exploration, trash collection, and area progression.
- The Object Interaction Loop: The lower-level process of how the player interacts with individual objects (e.g., picking up and disposing of trash).
Main Game Loop
When planning the main game loop (core player experience), it is common to start with a high-level overview of the game loop, outlining the ideal sequence of events the player should take.
Additionally, details do not have to be fully defined at this stage. For example, instead of specifying "collecting trash bags" , the flowchart may simply indicate that the player interacts with collectibles. At this early stage, the game's name and theme may still evolve, so maintaining a broad overview helps keep the focus on game mechanics.
The following flowchart represents the main gameplay loop for the Park Game.
Detailed Game Loop
Once the main gameplay loop has been approved, a more detailed loop is developed. At this stage, we begin planning specific details, such as when values need to be stored or updated and whether a sub-process needs to be completed.
In this particular game, when the player interacts with trash bags, the count of collected bags must be updated, but the trash bags themselves will be deleted. When an object is deleted, all variables associated with it are also lost. Therefore, we should separate functionality: instead of the trash bag storing the collection count, it should notify the trash bin that a new bag has been collected. This ensures that data persists even after the trash bag is removed.
At this stage, we also identify where scripts should be placed, what behaviors they define, and which objects they control. The trash bags have their own functionality, while the trash bin handles the main tracking for mission completion. Similarly, the gate follows its own independent process.
The following flowchart provides a more detailed gameplay loop for the Park Game.
A key design principle at this stage is the Single Responsibility Principle (SRP) from the SOLID principles. While it may seem convenient to have the trash bin control how trash bags function, each object should be responsible for its own lifecycle (e.g., Awake, Start, Trigger, Destroy, etc.). By keeping responsibilities separate, we maintain cleaner, more modular, and maintainable code.
Object Loop
Applying SOLID principles, the gate object—much like the trash bags—should be responsible for its own behaviors. In this instance, the gate does not need to know anything about the trash bags or the trash bin; it only needs to determine whether it can open. This depends on whether the mission (or level) has been completed.
Furthermore, we may have multiple gates and missions, and we don’t want to duplicate the same code for each gate-mission combination (e.g., gate-01 checking mission-01 status). Instead, we will create a LevelManager to keep track of the mission list. Each gate will simply check for the completion status of the mission associated with its gate number. This gate number will be stored as an instance (object) variable, allowing each gate to have a unique reference.
The flowchart below details the interactions between the player and gate object.
The DRY (Don't Repeat Yourself) principle helps prevent redundancy in code, reducing errors and improving maintainability.
As mentioned above, instead of hardcoding gate numbers to specific mission statuses, we dynamically retrieve the gate number and use it to find the corresponding mission. This ensures a scalable and reusable approach.
Additionally, at the end of both OnTriggerEnter and OnTriggerExit, the same sound clip needs to play. Rather than having both methods call the sound clip separately, we can create a PlaySound method that handles loading and playing the clip. This eliminates redundant calls and centralizes sound management.
Game Managers
Since game objects are should be responsible for managing themselves, we often need to implement Game Managers to handle broader, global aspects of the game. These managers are not tied to any specific game object and are usually represented as empty objects (objects with no visual representation in the game).
While a typical Game Manager controls game states and handles saving, there may be multiple types of Game Managers in a game. For example, a Scene Manager handles loading and unloading scenes, while a UI Manager is responsible for updating all on-screen user interface (UI) elements.
In this case, we will implement a Level Manager, which will be responsible for tracking level completion (i.e., mission progress).
The following flowchart outlines the behaviours of the Level Manager for the park game.
UML Diagrams
While flowcharts help map out loops and decision-making processes, UML diagrams (Unified Modeling Language) provide a structured way to design game architecture. They illustrate the relationships between objects and how they interact with each other.
For Park Cleanup, a UML Class Diagram could define how the Player, Trash, TrashBin, and Gate objects interact. This helps plan out code structure and object behaviors before implementation.
Summary
Visualizing loops through flowcharts and UML diagrams helps game designers and developers understand core gameplay mechanics and interactions before development begins. In Park Cleanup, these diagrams illustrate how players progress, interact with objects, and complete goals, providing a clear structure for game logic and development.