TinyGames · how it works
Get into the castle, find the keys, free the prisoners, get out. Guards patrol the corridors and will come for you if they see you down one.
Open index.html. No build step, no dependencies, no images.
eyrie/
index.html markup
style.css the frame around the canvas
js/engine.js copied unchanged from Overdrive - the seventeenth game on it
js/castle.js the floor plan, the locks, the prover and the guards
- no pixels, no engine, no DOM
js/eyrie.js the playable layer
test-castle.js node test-castle.js
That is the failure that matters in a game with locks, and it is not a crash. The player searches the whole castle, finds nothing, and concludes they have missed something — because from the inside, unfinishable and I am being stupid look identical.
So a floor plan is not merely drawn, it is proved: flood out from the entrance, pick up whatever keys that reaches, open the doors they fit, flood again, and repeat until nothing new opens. If the exit and every prisoner are not in the region that leaves, the plan does not ship.
$ node test-castle.js
proving every floor plan:
plan 1 15x11 1 prisoners keys A no dead doors completable
plan 2 17x13 1 prisoners keys AB no dead doors completable
plan 3 19x17 2 prisoners keys AB no dead doors completable
40 passed, 0 failed
Two of those three plans were impossible when I first drew them. The prover said so, and printed a map with the unreachable floor marked, which is how they got fixed. Nothing about walking around them would have told me — plan 2 was one wall away from having a sealed exit, and plan 3 had fragmented into pockets that shared no key.
And the prover is shown to reject: a key behind its own door, a walled-off prisoner, a chain of locks with the second key behind the second door, and a plan with no exit drawn at all — each caught, each with the reason.
The lock-chain test originally had a second open row beneath the corridor, which walked round both doors and made the whole thing meaningless. It is a single corridor now, so the locks really are in sequence.
Nothing but a person could walk the character. Keys and touch are both polled, so each frame overwrote the movement intent — a pathfinding bot set a direction and the very next tick cleared it. Four hundred simulated seconds produced zero movement and zero score. There is now a separate channel, and the game reads auto, then keys, then touch. This is the second game in the set to hit it; the lander had it too.
Walking into a guard was free. Contact was checked only after the guards moved, so a guard standing on the player stepped away first and the hit never registered. It is checked after anything moves now, by either side.
A guard reacts to a clear straight line, not to proximity. One on the other side of a wall must not know you are there, or the castle stops being a place with rooms in it and becomes a field with decorations. The tests hold it to that: down an open corridor yes, past a wall no, diagonally no, and beyond its range no.
Each guard shows which way it is looking, so being spotted is something you can see coming.
| ← ↑ ↓ → / WASD | walk |
| Space | shoot the way you are facing |
| R | new raid |
On a touch screen, drag to walk and tap to shoot. Shooting where you tap would be a different game — the tension here is that you can only fire along the corridor you are standing in.
Walking into a locked door with the right key opens it and costs you the step. Opening from a distance would mean never seeing which door your key was for, and the doors are the map.
250 a key, 500 a prisoner, 150 a guard, and 1000 + 5 × health for getting out. The
exit stays shut until every prisoner is free, and says so.
castle.js; anything you add is proved by the
suite before it ships, which is the point of having the prover in the module rather than in
the test.Advertisement