Skip to content

Selected-player test build

Test lists · Test stage · Controls

This is a private test candidate, not a release. Record the build date, operating system, keyboard or gamepad model, player count, steps, and what happened when reporting an issue.

Keep test data separate

  • On Linux, use the candidate's run-test.sh. It stores game data in the TestData folder beside the candidate. Do not delete that folder if a developer needs to inspect the test data.
  • On Windows, test with a separate Windows user or a disposable virtual machine. The normal Windows save location is under Documents, and this candidate has not been checked on Windows yet.
  • The test-stage keyword is tinytest. Its run uses temporary in-game progress; normal play in the candidate can still write to the candidate's save profile.
  • Steam and online features need a separate agreed test. A local developer steam_appid.txt is only for a private candidate and must not be included in a production Steam depot.

Suggested checks

  1. Open the test stage. Check the closed gate, ready text and lights, then start with keyboard or gamepad.
  2. Confirm the F1 panel starts on the right and can be moved. Try the enemy selector, manual and automatic spawning, and remove enemies.
  3. In settings, change and apply a keyboard binding. Try cancelling a change, using an already assigned key, resetting a profile, and restarting to check persistence.
  4. Repeat with a real gamepad. Disconnect and reconnect it, find it in settings, and verify that the correct player receives input.
  5. Try level and special rewards, including reroll with R and gamepad RB. In two-player mode, check both players can select their own valid cards.
  6. Check characters and abilities manually using the ability list. Record the character and the exact combination; a successful basic action does not prove every combination.
  7. Check pause, retry, game over, and returning to the menu. Test normal progression separately from the test stage.

Use disposable copies for save-migration tests. Do not move, overwrite, or delete real saves as part of testing. Crowd-control visuals are a separate planned improvement.

Windows developer build

Use Unity 6000.2.8f1 with Windows Build Support (IL2CPP) and the required Windows C++ tools. Open the exact candidate source on a Windows machine, select the existing Windows LZ4HC build profile, and build into a new empty folder. Do not change the scripting backend merely to build on Linux. See other-PC setup.

The project currently has uncommitted changes. A Git pull will not contain the candidate until those changes are deliberately transferred or committed; use the source snapshot supplied with the candidate or another verified transfer. Windows compilation, migration, Steam, and physical-device behavior remain to be checked on Windows.

Candidate check: 2026-11-03

  • The Linux candidate built successfully with Unity 6000.2.8f1. Unity reported a temporary build-helper startup error and an unavailable license access token; it recovered and completed the build.
  • An offline launch with a separate Linux profile created test saves and reached the main menu. This was a startup check, not a full play test. Steam was not running and was not tested.
  • Isolated Editor checks reported passes for stage unlocks, control capture and reassignment, and example save migration. Unity crashed during shutdown after these checks, so they did not exit cleanly.
  • A Windows developer source package was prepared from the uncommitted candidate. A Windows game build and actual Windows migration still need to be made and tested on Windows.