The Quest Log: Gaming for Learning & Fun: November 2025

Circuit Breaker — Refining Safety Through Iterative Game Design

Play the prototype: Circuit Breaker on Itch.io

Over the last few months, I’ve been iterating on my digital learning game, Circuit Breaker, transforming it from a concept document into a working Construct 3 prototype. What started as a simple safety-themed puzzle has evolved into a multi-level experience about sequencing, decision-making, and procedural awareness in a lab environment.

🧩 Game Overview

In Circuit Breaker, players take the role of a lab technician responsible for fixing electrical hazards safely. Each level presents a small environment filled with broken outlets, sparking fixtures, and the occasional overloaded breaker.
The player must assess the situation, toggle breakers when needed, and repair hazards to restore safety points. The challenge lies not in speed, but in following the proper sequence — an approach directly inspired by instructional models of procedural learning.

Goal: Restore power safely to the digital media lab by repairing hazardous equipment, toggling breakers correctly, and following proper safety procedures.
Learning Objective:

Identify safe vs. unsafe electrical repair states.
Apply a correct sequence of actions (disable breaker → collect tools → repair).
Interpret environmental cues (sparks, lights, UI messages) as indicators of hazard.
Strengthen procedural reasoning through Observe → Decide → Act → Feedback loops

How to Play:

Move: Arrow Keys
Left Mouse Click: Menu Button Interaction
Interact / Repair: E Key
Breakers: Toggle OFF before repairing hazards
Toolbox: Must be collected before safe repair
Goal: Repair all hazards to complete the level
Unsafe actions reduce Safety Points and trigger penalty effects (sparks or smoke). On Level 2, there will be more hazards to fix. On Level 3, in addition to hazards, you have to reactivate the server in the correct sequence.
Hazards: You will find the following hazards across three levels:

Outlets: Red means it is not fixed. It turns green once it is fixed.
Light Fixtures: Same as outlets, will change color once it is fixed.

Server: The server needs to be reset on Level 3. The three server nodes must have power and be activated in the correct order.

Safe A.I.: If you are ever stuck, please consult your friendly A.I. on each floor.

🧠 Iterative Design & Development

The journey from Level 1 to the final prototype was full of small but meaningful adjustments:

Added a breaker dependency system so outlets can only be repaired if their breaker is off.
Designed three distinct labs — Beginner, Intermediate, and Expert — to scale complexity.
Implemented UI feedback for toasts, scores, and hazards repaired.
Built Level Complete and Game Over screens to clarify progress and reinforce learning.

Each iteration in Construct 3 revealed new insights about both design and development. For example, I quickly learned that even simple rule systems (like “turn off the breaker first”) require careful event logic and testing. That iterative cycle — design, test, adjust, repeat — mirrored the instructional design process I’ve studied throughout this course.

💡 Reflection

Building Circuit Breaker in Construct 3 changed how I think about game design and learning design alike. The visual logic system made me rethink clarity: how every rule, cue, and condition translates into player understanding. I also realized how much iteration matters; small usability tweaks often made a bigger difference than large-scale mechanical changes.

Ultimately, this project wasn’t just about getting a working game — it was about designing a playable lesson that teaches through interaction. In that way, Circuit Breaker became both a prototype and a metaphor for safe design thinking: turn off the noise, troubleshoot, and build smarter.

🧾 Attribution

Construct 3 (engine), free license pixel assets, and original sound design by Joseph Sabo.

🕹️ Related Quest Log Entries

To see the full journey behind Circuit Breaker and my learning process, check out these earlier posts:

⚡ Constructing Circuit Breaker: From Rules to Reactions

After weeks of designing Circuit Breaker on paper, I finally started translating those ideas into a working prototype inside Construct 3. This post documents my progress converting my written instructions and core loop logic into interactive mechanics. It’s been both challenging and incredibly rewarding to see how rules evolve when they need to function in real time.

🧩 From Written Rules to Functional Logic

My first step was identifying how each player instruction could be represented as a trigger or condition in Construct 3. In theory, the rule “If breaker off → success” seems simple, but building that into a functioning event system requires setting up variables, sprites, and collision conditions that all talk to each other correctly.

Construct 3’s event sheet system made this process feel like puzzle-solving: each rule became a line of logic, and each feedback loop had to trigger something visual or auditory to help the player understand success or failure.

📸 Screenshot 1: Event Sheet overview showing the “breaker success” and “failure” logic setup.

One big breakthrough came when I realized how powerful instance variables could be. By attaching custom values to each hazard or power source, I could control multiple components (like lights, outlets, or wires) through a single shared script rather than duplicating code.

🔁 Building the Core Loop

The core loop—observe → decide → act → feedback—is now fully functional. The player explores the lab, investigates broken components, and makes decisions about what to fix first.

Every correct repair restores a nearby light or powers up a console, while incorrect actions cause visual warnings like flickering lights or minor sparks. The feedback system doubles as both reinforcement and narrative immersion.

📸 Screenshot 2: Gameplay moment where the player successfully restores power to a workstation (light turns green).

📸 Screenshot 3: Incorrect fix attempt with red flash and warning symbol.

While these feedback cues look simple, they carry instructional weight — helping players link their decisions with outcomes. This is how I’m embedding learning directly into gameplay instead of relying on on-screen text.

🧠 Experimenting With Mechanics and Challenges

As I tested, I noticed how easy it was to overcomplicate things. Adding too many simultaneous hazards confused the pacing and made debugging a nightmare. To simplify, I focused each level on one or two primary mechanics:

Level 1: Teaches basic power flow — switch, outlet, light.
Level 2: Adding more hazards — fixing one problem triggers another.
Level 3: Combines time-based decisions with sequencing.

These levels gradually build both player skill and conceptual understanding, reflecting how real troubleshooting evolves from observation to pattern recognition.

📸 Screenshot 4: Simple Level 1 layout in Construct 3 editor, showing labeled objects (switch, outlet, lamp).

📸 Screenshot 5: Player view of the same level with tool icons visible.

🎨 Assets, AI Prompts, and Visual Direction

To keep the design lightweight but educational, I’ve been using a mix of hand-edited pixel assets and AI-assisted texture prompts to create backgrounds. My approach was to make the Digital Media Lab setting instantly recognizable but stylized enough to stay approachable.

Here’s one of the AI prompts I used to generate concept art references:

“2D pixel art laboratory interior, glowing monitors, loose cables, soft blue lighting, safe hazard icons.”

📸 Screenshot 6: Title screen or start menu (showing Circuit Breaker logo and player prompt).

📸 Screenshot 7: Background art or tileset used for lab interior.

The key was making sure everything—from lighting cues to UI icons—supported the safety awareness learning objective.

⚙️ Reflection: From Idea to Interaction

Construct 3 has been surprisingly intuitive once I learned its event-driven mindset. Instead of thinking like a filmmaker (where time and sequence are linear), I’ve had to think like a systems designer, ensuring that every action has a reaction and that each player decision communicates feedback clearly.

The debugging process has been as educational as the design itself—every broken event taught me something new about how to structure logic efficiently. Seeing my prototype light up (literally and figuratively) feels like connecting the final wire in a circuit.

Next, I’ll focus on refining player feedback, adding a few accessibility settings, and polishing transitions between levels. But overall, the foundation is solid, and the learning outcomes are already embedded in the mechanics.

📸 Screenshot 8: End-of-level summary screen or “Power Restored” message.

📚 References (APA 7)

Sabo, J. (2025, November 3). Writing rules that teach themselves [Blog post]. The Quest Log: Gaming for Learning & Fun. https://josephsabo-gamedesign.blogspot.com/2025/11/writing-rules-that-teach-themselves.html

Sabo, J. (2025, November 3). Learning Construct 3: Revisiting the basics [Blog post]. The Quest Log: Gaming for Learning & Fun. https://josephsabo-gamedesign.blogspot.com/2025/11/learning-construct-3-revisiting-basics.html

Learning Construct 3: Revisiting the Basics

🕹️ Getting Comfortable with Construct 3

Even though I had already started developing my Circuit Breaker prototype, I decided to go back and complete the Construct 3 beginner tutorials to strengthen my understanding of how the engine’s events, layers, and collisions work. I worked through the Platformer Tutorial and the Ghost Shooter Tutorial on the official Construct 3 site. Both provided clear examples of Construct’s logic-based workflow and how mechanics are built using events and behaviors rather than code.

The Platformer Tutorial helped me better understand how player movement, gravity, and jump conditions are managed through the Event Sheet system. I realized how much smoother my own game could feel if I used built-in behaviors like “Solid” and “Platform” instead of creating custom collisions from scratch. Similarly, the Ghost Shooter Tutorial gave me insight into enemy movement and projectile events—helpful concepts for adding feedback and animations in Circuit Breaker (like sparks or tool actions).

🧩 Applying the Lessons to Circuit Breaker

These tutorials helped me refine Circuit Breaker’s player interactions. Before doing them, I was manually writing long event chains for movement and interaction detection. Afterward, I streamlined them using groups and sub-events, which made debugging much easier. For example:

I learned to track the breaker’s on/off state with instance variables instead of multiple events.
I reorganized my layout using layers for background, UI, and hazards, improving clarity.
I used global variables to track score and player progress across levels.

What stood out to me most was how Construct 3 emphasizes visual logic—it’s about understanding cause and effect, not memorizing syntax. This reinforced the instructional design principle that clear feedback loops are the foundation of learning.

🔄 Reflection

Completing the beginner tutorials after starting Circuit Breaker actually made them more meaningful. I could connect every step directly to my project and see where I’d made things harder than necessary. It reminded me that even experienced creators benefit from revisiting fundamentals—especially when learning a new tool.

Going forward, I plan to explore more of Construct 3’s UI and animation systems to make my next level feel more alive. The tutorials gave me confidence in the tool’s flexibility, and I now understand how to better blend its visual logic with my educational game goals.

Writing Rules That Teach Themselves: Translating “Circuit Breaker” into Playable Instructions

🧠 From Design Document to Playable Rules

When I first designed Circuit Breaker, I had a clear idea of what I wanted players to do: restore power to a damaged media lab by safely fixing electrical hazards. Translating that idea into player-friendly instructions was trickier than it looked. My initial notes read more like a safety manual than a game.

So, I started with a simple text list of controls and goals:

Player Goals & Controls

Objective: Fix every hazard in the lab to restore power.
Move: Arrow keys.
Interact: Press E or Click to pick up or repair.
Safety Rule: Always turn off the breaker before fixing outlets.
Scoring: +10 for safe actions, –5 for unsafe ones.
Win: Fix all hazards → advance to the next lab.

After play-testing, I realized most players skip long instructions. Instead of forcing them to read, I redesigned the tutorial around learning by doing. For example, a player can’t fix an outlet until the toolbox is collected, and if they forget the breaker, the game sparks, flashes red, and subtracts points. Every reaction quietly teaches a rule.

🧩 Building the Rules in Construct 3

Implementing this system inside Construct 3 meant translating my written rules into event logic. I learned that rules aren’t just text—they’re conditional statements:


If Breaker = OFF → repair succeeds (+10)
Else → show spark animation, play error sound (–5)

I also added instance variables like isFixed and HasTools to track progress. This made it easier to script meaningful cause-and-effect chains.

Through experimentation, I found that visual feedback communicates rules far better than extra dialogue boxes. When the lab lights brighten or the “Safety Meter” fills up, players instantly recognize success. To reinforce learning, I gave the in-game AI assistant, S.A.F.E., a voice—offering contextual hints such as “Breaker first, then outlet.”

🔄 Iteration & Next Steps

Right now, the instructions exist both on the title screen (as a concise “How to Play” summary) and within gameplay through cues and reactions. My next iteration will add an animated mini-tutorial demonstrating a full repair sequence with captions for accessibility.

This process reminded me of an important design principle: in educational games, good instructions are invisible. When players understand what to do without reading a wall of text, the learning becomes authentic and memorable.

🧰 Reflection on the Process

Working through Construct 3’s beginner tutorials helped me appreciate how “recipes for instructions” can be broken into small, testable steps. Each rule I wrote had to be translated into a conditional event—if it didn’t make sense in code, it probably wasn’t clear enough for players either.

By treating instructions as an evolving conversation between the player and the system, I was able to make Circuit Breaker both teachable and playable.