I Stopped Trusting “Complete” and Replayed All Seven Levels

Seven levels existed. That did not mean they were tested, balanced or ready to ship.

// WHAT DID “COMPLETE” MEAN?

On 14 June, I published a devlog saying that Act 1 of Shadow Raid was complete. The seven levels existed. The story could move from an asteroid field, across the desert and into an enemy base. The boss, rewards, map and hangar had all been implemented.

That statement was not invented, but it used the wrong definition of complete. I was treating implemented as if it also meant verified. It did not tell me whether every level had been played from beginning to end, whether the balance still worked after the move from GameMaker to Godot, or whether the whole campaign was ready for an Android build.

After a short break, I moved my daily development environment to Fedora Linux. The first job on the new system was not adding another feature. It was rebuilding my confidence in the game that already existed.

// THE NEW RULE: EVIDENCE BEFORE STATUS

I use AI assistance as part of my solo development workflow. It helps me analyse code, compare systems and move through repetitive work that would otherwise be difficult for one person to manage. But an AI summary is not a test result, and a confident sentence in a devlog is not evidence that a mechanic works.

The problem was not using AI. The problem was allowing descriptions of the work to become a substitute for the work itself.

My new process has four separate stages:

Each stage answers a different question. Static code review can find a missing function call. A controlled test can confirm that saving and unlocking work. Only playing the level can tell me whether it is readable, fair and enjoyable.

// SEVEN LEVELS, ONE BY ONE

I started with a clean, isolated save and followed the normal route through the introduction, briefing and tutorial. I then audited every Act 1 level from A1L1 to A1L7 in Godot 4.7.2 on Fedora KDE.

The technical checks covered enemy phases, level endings, score thresholds, star awards, saved progress and the unlocking of the next mission. I then manually completed every level without using the temporary protections from those controlled tests.

The shape of the act now feels right. It begins with a simple asteroid run, introduces more dangerous enemy formations over the desert, pushes the player through a narrow base approach, and finishes with a boss that demands attention without becoming exhausting.

That full pass also found several problems that had survived implementation.

// THE SHIP WAS SMALLER THAN IT LOOKED

The player ship used a narrow collision capsule around the centre of the hull. Most of the visible wings were outside it. Depending on the ship tier, roughly 59% to 70% of the opaque sprite existed beyond that old shape.

I replaced it with collision geometry generated from the real alpha channel of each ship tier. The hull and wings now count, while the engine flame is deliberately excluded.

This is a more honest hitbox. It makes the ship slightly less forgiving, but what the player sees now matches what the game detects.

// CODE THAT EXISTED BUT NEVER RAN

One enemy missile already had a homing function. On paper, the feature looked finished. In the running game, the function was never called, so the missile simply continued along its starting path.

Calling the existing logic every frame fixed the guidance. A later test inside the base revealed a second issue: another homing missile changed direction correctly, but its sprite and long collision shape kept their original rotation. The missile reached for the player while appearing to fly sideways.

The movement, artwork and collision now rotate together. This is exactly the kind of problem that disappears in a checklist and becomes obvious the moment the game is played.

// WHEN THE WORLD MOVED FASTER THAN THE ENEMIES

In several desert and base levels, the background was scrolling faster than the heavier enemy ships. The maths worked, but visually the enemies appeared to slide backwards across the ground.

I compared the Godot values with the original GameMaker project and restored the slower environmental speed where it mattered. For the base entrance, I kept a separate faster value so the final approach still arrives on time.

Nothing about the enemies themselves had to become faster. The fix was to make the world around them move consistently.

// THE LEVEL THAT NEEDED LESS

A1L6 takes place inside a narrow base corridor. The Godot version had doubled the number of wall cannons and enemy ships from the original GameMaker design. In an open level that might have created useful pressure. Inside a restricted flight area it created noise and forced me to rely too heavily on fuel-powered bombs.

I restored the original enemy count, fixed the wall missiles and cut the long empty pauses between sections in half. The final version is still demanding, but now it combines careful movement with shooting instead of overwhelming both systems at once.

This was an important reminder that more enemies do not automatically create a better level. Sometimes the strongest improvement is removing what does not belong.

// THE BOSS HAD FOUR QUIET PROBLEMS

The Act 1 boss was functional, but the audit uncovered four inconsistencies around the fight. Plasma was configured for higher damage but was being processed like a normal bullet. The laser was consuming shield charges even though the design says it should bypass that protection. The base background used the wrong speed, and the two-star threshold did not match the intended value.

After correcting those systems, I played the full encounter with a Tier 1 ship and early upgrades. I defeated the boss with a score of 1,725 and one star.

The fight required concentration, but it was not unfair or excessively difficult. That is the result I wanted. I kept the boss at 250 HP and left the accepted attack cycle intact.

// EVEN THE ARMOUR WAS ROUNDING AWAY UPGRADES

The hangar audit exposed a quieter mathematical problem. Armour reduces incoming damage by 5% per level, but the remaining damage was rounded to a whole number after every hit. Against a common 10-damage bullet, the first 5% upgrade could still remove 10 HP. Some armour levels therefore produced no real improvement in normal play.

Player health is now stored internally with decimal precision. The HUD still displays a clean bar, but every purchased armour level delivers the reduction it promises.

I did not use the audit as an excuse to redesign every price and multiplier. Those values will be judged while building and playing later acts, when there is real evidence for changing them.

// WHAT IS ACTUALLY COMPLETE NOW?

All seven Act 1 levels have now been manually completed and accepted on PC. The tutorial, mission progression, boss rewards, tier advancement and hangar transactions have also been checked in controlled flows.

That is a meaningful milestone, but I am deliberately not calling the game release-ready.

The difference may sound small, but it changes how I run Alastis Dev. From now on, “implemented”, “tested on PC”, “tested on Android” and “ready to release” are separate statements.

// FEDORA, GODOT AND A LINUX BUILD

Moving the development setup to Fedora KDE was much smoother than I expected. Shadow Raid starts and runs correctly through Godot using my existing GTX 1650, and the new environment has already supported a complete Act 1 audit.

Because the project now develops natively on Linux, a Linux build has joined the plan. That is a plan, not a support promise. I will only describe Linux as officially supported after testing the export, input, saving, audio and performance in a build intended for players.

Android remains the main target, with the Pixel 7a as the primary test device.

// THE LESSON I AM KEEPING

The biggest result of this audit is not one fixed missile or one adjusted background speed. It is a better definition of progress.

As a solo developer, I need tools that help me cover disciplines I cannot handle alone. AI can be valuable in that role, but it must remain an assistant rather than an authority. The game, the code and the test result are the sources of truth.

I would rather have seven levels I can defend with evidence than seventy tasks marked complete in a document.

Next comes the clean-save run and the Pixel 7a test. After that, I can move into Act 2 with much more confidence in the foundation underneath it.