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.