Building a browser game is one thing.
Watching it remain stable through a real play session is another.
That is why testing became an important part of ALEXX SkyRider™.
I did not want to assume that because the first screen appeared correctly, the entire experience was ready. For Test Lab, a real test means going beyond the page load and actually playing long enough to see how the game behaves.
“TESTED WITH” MEANS ACTUALLY TESTED
I try to be careful with the words Tested With.
For ALEXX SkyRider™, that phrase is not intended to mean:
“Every device, browser or controller of this type will work perfectly.”
It means something more specific:
the configuration being discussed was actually used during project testing.
That distinction matters because hardware, browsers, settings and controller support can vary. A successful test documents a real result; it does not become a universal compatibility promise.
For that reason, specific device results belong mainly in their own Test Lab entries, where the exact setup and what happened during gameplay can be explained clearly.
WHAT WE CHECK DURING A TEST
A successful test is not simply seeing the first screen appear.
There are several things I want to observe during a real session:
- Does the experience load correctly and enter gameplay?
- Are the controls recognized, and does the ship respond the way it should?
- Can the player move, fire, accelerate and brake normally?
- Does fullscreen behave correctly in the tested environment?
- Do music and sound effects continue working during gameplay?
- Does the experience remain stable while enemies, obstacles and effects are active?
- Can the player pause and continue without breaking the session?
- When a playable demo is being tested, does RETURN TO GATE work correctly at the end?
A system can load the page and still reveal a problem later. That is why I do not treat a successful startup screen as the end of the test.
LOAD FIRST, THEN PLAY
The first step is confirming that the actual build opens correctly in the environment being tested.
But that only tells me that the session can begin.
The next step is entering gameplay and keeping the test moving. The ship has to respond, the route has to remain readable, and the project has to continue functioning while the screen becomes active.
That difference is important: opening the game is a check; playing it is the test.
CONTROLS HAVE TO WORK DURING REAL GAMEPLAY
Seeing that a controller is connected is not enough.
The useful question is whether the controls continue responding correctly while the player is actually using the game.
Movement has to feel consistent. Firing has to respond. Acceleration and braking have to work when the route becomes demanding.
The same principle applies to keyboard or any other control type being tested: I want to know how the input behaves inside the real arcade session, not only whether the device appears to be recognized.
FULLSCREEN AND AUDIO ARE PART OF THE EXPERIENCE
ALEXX SkyRider™ is not only movement on a screen.
Fullscreen, music and sound effects are part of the way the experience is presented, so they also belong in the test.
I check whether fullscreen behaves correctly in the tested setup and whether the audio continues working after gameplay begins.
A test is more useful when it observes the complete experience rather than treating graphics, controls and sound as unrelated pieces.
STABILITY NEEDS TIME
Some problems do not appear immediately.
That is why I value real play sessions instead of very short loading checks.
As the session continues, more enemies and obstacles appear, more sounds are triggered, the player changes position constantly, and the game has more opportunities to reveal a stability problem.
Testing means staying with the game long enough to see whether the experience continues behaving correctly under normal play.
PAUSE, CONTINUE AND RETURN
A real test also includes the moments around gameplay.
If the player pauses, the session should pause and continue correctly.
If the test route reaches its intended ending, that transition should work normally.
And when one of the playable demos is being checked, the return path matters too. RETURN TO GATE should take the player back correctly instead of leaving the experience in a broken state.
These details may happen outside the most intense part of the action, but they are still part of the player experience.
THE PLAYABLE DEMOS AS CONTROLLED TEST ROUTES
The two playable demos available now provide useful controlled routes for practical testing.
The Main Arcade Demo uses part of the Snow Face.
The Time Attack Demo uses part of the Night Face.
Both use infinite lives, allowing the player to continue through the demo route while the test focuses on the experience itself.
Within those routes I can observe movement, controls, Fuel, TNT, enemies, sound, browser behavior, stability and the final return to the Gate.
Because the demos are already playable, these are not theoretical test environments. They are real sections that can be opened, played and observed.
A SUCCESSFUL TEST IS STILL A SPECIFIC RESULT
When a configuration works during a real session, that result can be documented.
What it should not become is a promise that every similar device, browser or controller will behave identically.
That is why the wording stays precise: Tested With means actually tested.
SPECIFIC DEVICES BELONG IN SPECIFIC TEST STORIES
TEST LAB 01 establishes the method.
The detailed results belong in practical entries focused on one real setup at a time.
For example, the Steam Deck + Firefox test can explain exactly what was used and what happened during gameplay without turning this methodology article into a catalog of systems.
This approach is used only for experiences that have been documented through real testing.
That keeps Test Lab useful: the methodology stays here, while each device or control story can show its own evidence and context.
TEST LAB IS A RECORD OF WHAT REALLY HAPPENED
That is the purpose I want this section of the Blog to have.
Not a collection of compatibility claims.
Not a list created from specifications.
Not assumptions about hardware that has never been used.
Test Lab should document real experience.
When something works, we can explain what was tested.
When a browser or control changes the result, we can document that in the specific test.
And if a real test reveals a limitation, that information is useful too.
TEST. PLAY. VERIFY.
ALEXX SkyRider™ was inspired partly by the simplicity of getting ready and playing.
Modern browser technology makes a new version of that idea possible, but simplicity for the player requires careful testing behind the scenes.
So the method is straightforward:
Load the real build. Enter gameplay. Use the controls. Listen to the audio. Play long enough to observe stability. Pause and continue. Finish the test route. Verify the return path when it applies.
That is how I want Test Lab to work.
Not to promise that everything works everywhere.
To document how ALEXX SkyRider™ was actually tested.