Short, dated results from the project's engineering, testing and research work: what was tried, what was found and what was decided. Newest first.
Each note is the result of an experiment at the time it was written. It may be wrong, incomplete or superseded by a later note, and it says what was not tested. Each note carries one verdict:
- Adopted: part of how the project works now.
- Not for 1.0: judged worthwhile, but not before release 1.0.
- Roadmap: planned, with no date.
- Rejected: tried or assessed, and not pursued.
Testers can add feedback through the Field Kit (Report a problem, or /c bug in chat). For the current state of the
testing, see Testing status.
Notes: Many test players on one server | What the automated players found | From one long run to coverage | Can the real client be automated for testing? | Notes in progress
Many test players on one server (2026-10-26)
Verdict: Adopted for short runs; one full-length pack held, one early stall still unexplained. Several automated players can share one game server, at close to the memory cost of one.
What we tried. Until now every automated player ran in its own copy of the game server. Most of a server's memory goes to game data and terrain that are loaded once, not to the players. We added a pack mode: a group of test players plays in one server, each with its own character, its own report and its own record of problems.
What we found. One test player alone peaked at about 4.6 GB of memory on the test machine. Six players in one server peaked at about 5.0 GB, so each extra player cost roughly 80 MB. A pack of seven players ran for 24 minutes with a peak of 5.1 GB. The database connection they share was not a bottleneck: 18,305 queries took 3.9 seconds in total, and the longest wait for the connection was 63 milliseconds. Three problems had to be fixed first. The log of problems was shared, so each player now reads only its own lines. One player that failed took the whole run down, so each player now runs on its own and a failure ends only that player. Players that start in the same zone fight over the same creatures, so a pack mixes players from different starting zones and starts them 20 seconds apart. In the proof run a player that cannot exist (a class and race the game does not offer) failed alone at once, and a player stopped on purpose lost only itself and kept its level in its report.
What it costs. Memory per pack is about that of one ordinary run. The price is that a pack shares one server's clock and hardware, so a crash of the machine ends every player in it, and stopping one player stops the pack.
What happened over a long run. A pack of three (a Mordesh stalker, a Chua warrior and a human esper) ran for about 7 hours with no player stopping, and all three reached level 15: the warrior after 6 h 41 min, the esper after 6 h 55 min and the stalker after 6 h 59 min (34 deaths). A pack of one Granok medic also reached level 15. The first pack (2026-10-26) had one player stop updating after four minutes, which has not been explained; it is one sample and is still open. The Chua player that made no progress in that pack did level in the three-player pack.
What we did not test. A full 8 hour pack of four or more players, or more than one full-length pack. Whether a player in a pack levels as fast as the same player alone under identical conditions: the comparison used older runs and is only indicative. Packs of more than seven players. How often players in the same zone get in each other's way.
Next. Use packs for the extra confirmation runs, including races other than human, and measure larger packs.
What the automated players found (2026-10-25)
Verdict: Adopted. Sort every failure of an automated run into game, data or test player before counting it.
What we tried. Headless players, which play the game through the protocol without a graphical client, were run through the levelling quests.
What we found. The failures fall into three kinds: faults in the game, faults in the game data, and faults in the test player itself. Sorting each one matters more than counting them. Game and data faults found this way and fixed include a Support Training tanking dummy that players of one faction could not hit, a quest target that stayed hidden after a story scene (Pyrius Octavian in The Face of Justice), and a bag that could not be swapped for a smaller one. Test-player faults included marking a creature unkillable after a single fight in which no damage was dealt. Those are corrected in the player, not in the game.
What it costs. Each failure needs its evidence read before it is assigned.
What we did not test. Levels above 15.
Next. Keep the sorting in every round. The game fixes are listed in the release notes.
From one long run to coverage (2026-10-25)
Verdict: Adopted. The 1.0 bar for levelling is evidence of every level transition, not one uninterrupted run.
What we tried. A full run of levels 1 to 15 takes 5 to 8 hours, and restarting it after each fix wastes most of that time. The release bar now asks that every class and faction can level from the start level to 15, shown by evidence of every level transition, plus one confirming 8 h run per lane and a published bug budget. The day-one test supports a single-quest scenario: a character is levelled and placed at a quest, and only that quest runs.
What we found. A stuck quest can be run again in minutes. In the first release-bar round, six lanes (Exile engineer, esper, medic and stalker; Dominion medic and stalker) reached level 15 within the 8-hour budget. See Testing status for the current table.
What it costs. Evidence has to be recorded per level transition, class and faction, not as one pass or fail.
What we did not test. Group content.
Next. The drill command, checkpoints with rewind, and group content are still being built.
Can the real client be automated for testing? (2026-10-25)
Verdict: Not for 1.0. Medium effort; worth a small experiment after release.
What we tried. The real WildStar client was run headless under a virtual display (Xvfb) with software rendering, and given typed input. The Field Kit add-on can read the quest log, objectives and dialogs, and answer interaction windows. It cannot walk or start an interaction, so server-side teleport and simulated clicks cover those gaps.
What we found. The client rendered the login scene at 0.6 to 1.6 frames per second and used up to 8 CPU cores. It would show what the client itself sees, such as tracker text and Lua errors, which the headless protocol player cannot.
What it costs. About 6 to 8.5 engineering days for a repeatable one-client drill. Running several clients on test machines without a GPU is a larger effort and may reach a frame-rate dead end.
What we did not test. Login against a real server, the world scene, and the Field Kit under the headless display.
Next. A half-day experiment on a machine with a GPU after 1.0.
Notes in progress
Titles only; there are no results yet.
- Test-time respawn scaling for drills
- Checkpoints and rewind for test characters
- A coverage matrix of every quest by class and faction
- An offline check that every quest objective has a reachable target