Version 1.0.3 Released

When Mosslight Manor first reached version 1.0, I thought the game was finished.

It compiled cleanly. The ROM booted correctly. The password system worked. Combat tests passed. The final boss worked. All 48 Moon Shards could be collected by the automated QA routines. The game even completed successfully in multiple Game Boy hardware configurations under emulation.

And then I actually tried to play it like a normal player.

That changed everything.

The problem with “green” tests

The original QA suite was very good at answering technical questions:

Does the ROM crash?
Does a projectile damage an enemy?
Does a gate open when its condition is fulfilled?
Can the ending be triggered?
Are passwords decoded correctly?

Unfortunately, those tests were not good enough at answering the most important question:

Can a normal person actually play the game from beginning to end?

The answer, at that point, was: not reliably.

The very first room exposed the problem immediately.

A crate had to be pushed into the first enemy. The next enemy could be shot, but the projectile interaction wasn’t intuitive enough. Worse, one of the ladders did not actually provide a usable route to the upper section of the room.

The game was technically alive, but parts of it were functionally trapped behind its own level design.

That meant the old definition of “PASS” had to go.

v1.0.1 – The Playability Pass

The first major repair focused on actual room traversal.

Instead of simply checking whether important objects existed, the new analyzer began simulating the real dimensions and movement rules of the player:

8×16 player collision, gravity, ladder detection, pipes, passages, solid tiles and gate conditions.

That immediately uncovered several inaccessible Moon Shards.

The affected rooms included:

Gatehouse, Root Passage, Moon Crypt and Observatory.

The Gatehouse received the most important early-game changes. The broken upper route was repaired, and the second enemy was changed so that the introductory projectile actually behaves the way a new player expects.

The opening room now teaches its mechanics instead of quietly punishing the player for not understanding hidden rules.

After the fixes, the new geometry test confirmed:

48/48 Moon Shards reachable.

But that still wasn’t enough.

A mathematical route does not necessarily equal a human-playable route.

So the next step became considerably more ambitious.

Building a HumanBot

For v1.0.2, I created an automated player designed to behave much more like a real person.

The HumanBot is not allowed to teleport around the level or directly alter game variables.

It plays through the emulator using normal Game Boy controls:

D-Pad, A, B, SELECT and START.

The bot can observe what is happening and plan routes, but the actual game is still responsible for movement, collisions, enemy behavior, pickups, damage, deaths and room transitions.

This turned out to be enormously useful.

The bot immediately discovered another real issue in the Observatory.

The Sentinel guarding the Elite Gate could wander away from the location where the puzzle expected it to remain. Under certain circumstances it could even become awkwardly positioned near a ladder.

That meant the player could perform the puzzle correctly and still end up with an unusable room state.

The Sentinel was redesigned as a proper stationary gatekeeper.

It can still be attacked, stunned and defeated. It simply no longer abandons the puzzle position it is supposed to guard.

The first real full-game AI playthrough

After several improvements to the tester itself, the HumanBot finally completed the entire game in one continuous run.

Not room-by-room test cartridges.

Not password warps.

Not a debug quickclear.

A real run:

Title screen → Gatehouse → all eight rooms → Heart Warden → Ending.

The successful run took 6,596 emulated frames.

During the run the bot took real damage, lost lives and even reached a genuine Game Over in Observatory.

It then performed the same recovery process available to a player:

START → Retry → Room Brief → START

It replayed the room and continued normally.

No Save State rewind was used for the final proof run.

No Moon Shards were moved to the player.

No gates were opened through debug code.

The game was finally being tested as a game rather than merely as a collection of working systems.

v1.0.3 – What happens when the player hesitates?

There was still one concern.

An automated player can become very consistent.

A human isn’t.

Players stop moving for a moment. They hesitate before approaching an enemy. They turn around. They enter a room at a slightly different moment.

Those tiny timing differences matter in a game with moving enemies.

So v1.0.3 introduced a Robustness Test.

The HumanBot was forced to wait random amounts of time during real gameplay. This intentionally shifted enemy positions and movement phases between runs.

Initial testing passed comfortably with small delays.

Then I pushed it much harder.

At up to 120 frames of random hesitation, one run exposed another legitimate problem in Root Passage.

After a respawn, enemies could move into the starting corridor while the player was still recovering. The existing 90-frame protection window could expire before a slower player had safely regained control.

This created a potential death spiral.

The solution was deliberately small.

Only Root Passage received a longer spawn/respawn protection period:

90 frames → 150 frames.

Roughly 2.5 seconds.

Enemy health was not reduced. Enemy speed was not reduced. Damage was not lowered. The room geometry remained unchanged.

The player simply receives enough time to regain control after spawning.

The final stress test

After the Root Passage fix, the final v1.0.3 ROM was subjected to another set of complete HumanBot runs.

This time every run included random delays of up to two seconds.

The result:

10/10 complete playthroughs reached the ending.

The shortest completed run took 6,824 frames.

The longest took 15,830 frames.

One particularly chaotic playthrough survived 27 separate hits/respawns and still completed the game normally.

No softlocks were encountered.

No impossible gate states appeared.

No room became permanently unsolvable.

That is the version now released as Mosslight Manor v1.0.3.

What I learned

This update became much larger than a normal bugfix because it exposed something important about game development.

A game can pass hundreds of automated checks and still not be fun, understandable or even properly playable.

Testing individual mechanics is useful.

Testing level geometry is better.

But eventually, someone has to actually play the thing.

In this case, that “someone” became a slightly stubborn automated Game Boy player that was perfectly willing to die dozens of times until it found the cracks.

And it found quite a few.

Mosslight Manor is in a much better place because of it.

Thanks to everyone testing the game, especially anyone who reports situations where something simply feels wrong. Those reports are often far more valuable than a clean compiler log.

Mosslight Manor v1.0.3 is available now.

The manor is finally ready to be explored.