Where to put a castle gate

Our Tower Defense game had just traded its placeholder drawing for proper castle art. Then we rendered all three levels and looked at them properly, and two problems showed up that nobody had seen in code. This is a short story about a small bug and the way we chose to fix it.

The problem

On level 2, the gate at the end of the road was clipped by the top edge of the map. On level 3, it sat in the middle of the spiral, next to a tower slot, and partly overlapped that slot’s ring.

Neither was a crash, and neither would show up in an automated check of whether the game runs. They are the kind of flaw a player notices without being able to name it. The scene looks slightly off, and a tower slot looks as if it is guarding something it isn’t. For a learning site where a game is a short break from study, that sort of polish is part of why people come back to it.

The decision

The quick route was to nudge each gate by hand, one level at a time. That fixes the three levels we have and does nothing for the fourth one we add later. So we wrote a rule instead: the gate sits on the road, as close to the road’s end as it can while staying fully inside the 800×600 field and clear of every tower slot’s ring.

The trade-off is that the gate is no longer guaranteed to sit exactly where the road stops. On level 1 nothing moved, because the end of the road already satisfied the rule and the gate stays at the right edge. On level 2 the gate moves just inside the top edge. On level 3 it steps back along the last segment of the road, off the ring of the first slot. We accepted a gate that sits a little short of the road’s end, because the alternatives were a clipped gate or an overlapping ring, and both read as mistakes to the person playing.

How we built it

The rule lives in one function. It takes the road and the tower slots and returns a position for the gate, so it works the same way on every level instead of carrying a hand-tuned number for each. That is also what makes it cheap to keep correct: when the map changes, the gate follows the geometry.

We then added a test for each of the three levels. Each one checks three things: the gate is inside the field, it is on the road, and it is clear of every slot. If someone moves a slot or redraws a road later, the test fails before a player sees an overlap.

The scenery and sprite code is shared in spirit with our mobile game, Brain Defense, so we copied it across with the placement fix included. That way the mobile version starts from the corrected rule instead of re-learning the same lesson. Browser games and phone games drift apart easily when each one keeps its own copy of the geometry, and copying the shared code is a small guard against that.

What we left out

We changed only the gate. The levels, the towers and the castle art are as they were, and level 1 looks exactly as before. We have also not yet recorded a check of the mobile version on a phone or emulator at phone size, so we are not claiming that part is finished.

Rendering every level and looking at it was the step that found the problem, and it is the one we would repeat. A test can tell you a gate is inside the field. Only looking at the screen tells you it looks right. You can play it from any Braineos deck, for example Logical fallacies, spotted.