v0.1
The idea
Cyber security is usually taught to kids as a list of don'ts. Don't share your password, don't click the link, don't talk to strangers. That's fine, but it doesn't build any real mental model of how networks actually work, and it definitely doesn't make anyone want to learn more.
So this term we flipped it into a game the whole school plays at once. Every class that comes through the room is split down the middle: left side is Red Team, right side is Blue Team. Each team has a castle in Minecraft and, more importantly, a real physical server sitting in the classroom that belongs to them. Sixteen classes, from Foundation right through to Year 6, are all contributing to the same two castles and defending the same two servers across the whole six weeks.
It builds on things the students have done before, including an earlier capture the flag competition, but the focus this time is squarely on cyber security and network fundamentals rather than the race.
v0.9
Before anyone touches Minecraft
Here's the twist that surprises every class: nobody is allowed into Minecraft on day one. Each team first has to draft a defence plan and lock down the credentials on their own server. If your team can't look after a password in the real world, you haven't earned the right to build a wall in the virtual one.
The servers are the real thing: two small machines running Umbrel, one per team, sitting on the classroom network. The students aren't protecting an imaginary asset. There's an actual box with an actual login, and the other team would love to get into it.
This phase does a lot of quiet work. Teams have to agree on who holds what, how a credential gets shared (or doesn't), and what their plan is if something leaks. That's threat modelling, even if nobody in the room calls it that.
v1.0
Build season: creative mode, versioned like software
Once the defence plan is approved, the building starts. Teams work in creative mode on their own castle, and every build is versioned exactly like software. Each lesson opens with a version bump: v1.0 becomes v1.1, v1.1 becomes v1.2, and so on through the term.
A new version doesn't just happen, though. It has to be earned:
- Each team runs its own meeting to review the defence plan and the quality of the build.
- A unanimous tick from the team approves the next version.
- No consensus means rolling back to the last good version and fixing what the team couldn't agree on.
That rollback rule is the secret curriculum. Kids learn very quickly that shipping something half the team hates is worse than shipping nothing, and that a saved known-good state is the most valuable thing you own. Version control, consensus and governance, taught by a castle.
Progress is tracked in a published spreadsheet where every class's Red and Blue teams tick off milestones, from Beta Test through each version, and a live scoreboard page reads that sheet so the whole school can see where every team stands. Both teams even have their own Nostr accounts for team identity.
v1.x
What's actually being learned
Because the castles sit on real infrastructure, the networking concepts aren't bolted on, they're load-bearing. Every real-world idea gets a mirror inside the game.
Ports & protocols
How services listen, how traffic finds them, and why an open door you forgot about is the first thing an attacker checks.
IP addresses
Every device on the network has one. Finding them, hiding them and reading them becomes second nature.
Credential hygiene
Who holds the keys, how they're stored, and what happens when a password walks out the door.
Defence in depth
Castle walls, moats and decoys in-game map directly onto layered security thinking in the real world.
Consensus
Unanimous version approval and rollbacks teach how groups agree on a shared state, one of the deepest ideas in computing.
The younger years get the big pictures: castles, treasure, keys and walls. The older years go deeper into the protocols and the why. Everyone is playing the same game at their own depth, which is what makes a whole-school program actually work.
v2.0
The final day: attack
After six weeks of defending, the modes flip. Each team stays in creative mode for their own castle but enters the enemy's world in adventure mode, where you can explore and interact but you can't just punch through walls. Your way in has to be earned through what the defenders missed.
The treasure isn't gold blocks. Hidden on the classroom network is a small KVM device, and its secret IP address is the prize. Protect yours all term. Hunt theirs on the final day. The team that captures the hidden IP wins.
It's the perfect end state: the game that started with "write a defence plan before you build anything" finishes with students performing reconnaissance on a real network, in a safe sandbox, using everything they learned about ports, addresses and human mistakes along the way.
next
Why it works
Minecraft is the Trojan horse. Students think they're building castles; they're actually running standups, managing credentials, reaching consensus, versioning their work and reasoning about attackers. The red/blue framing is borrowed straight from professional security practice, and it turns out seven-year-olds take to it faster than most adults.
The term isn't over yet, and the scoreboard is still moving. If you run a classroom, a makerspace or a security team and want to talk shop about any of this, the encrypted contact form below goes straight to me.
Follow the battle live
This is the live Castle Defence version board, mirroring the teams’ Google Sheet in real time: every class, every team, every approved version.
Discuss this on Stacker News
Join the conversation in the ~education territory, zaps welcome.
⚡ ~education
