568 Web Games Train a 9B Player: Fix the Environment First, Then Double the Model’s Progress

Game2Player has released the project page, code, and model links. It aims to solve a very concrete problem: visual agents lack enough game environments that are sufficiently numerous, sufficiently diverse, and automatically scorable. A visual agent can be understood as a model that can look at a screen and operate an interface.

Common approaches are to find a small set of games or collect human gameplay data. The former is limited in scale; the latter is costly. Game2Player turns web games into verifiable environments, with coding agents and VLMs together participating in environment maintenance and data production.

The pipeline is not complicated. Scout first filters games by source, engine, and whether game state can be obtained. Builder adapts games to be playable offline, exposes state through game_api.js, and then defines tasks. Tasks have start conditions, progress, and success checks; progress is computed from game state. Coding Player writes Python policies, reads state, and executes actions in the real-time environment. VLM Player only looks at screenshots and chooses actions by reasoning; the game pauses during reasoning. When a player encounters a key press with no response, or a policy needs a state variable that is not exposed, they send the issue back to Builder as Reports. Builder looks at the trajectory, fixes the environment or the task checks, and the player retries. When a key press does nothing, it is the environment that gets reworked, not the model that is forced to guess.

This loop produces two kinds of things. One is verified environments; the other is trajectory data. Trajectories record observations, actions, and task progress. The game collection covers 568 web games, converted into 3,436 verifiable tasks. Collected data comes from 396 games and 2,251 tasks, totaling 15,707 trajectories, 1,563,640 steps, and 307 hours. Coding Player contributed 12,856 trajectories, and VLM Player contributed 2,851. The data is still growing.

Training uses progress-weighted SFT, giving higher weight to steps that advance the task. The models are based on Qwen3.5-4B and Qwen3.5-9B. The 9B version plays only from pixels; on GameWorld its progress rises from 30.0 to 53.1, which the project team says exceeds Qwen3.8-Flash-Next; on PlayerBench it rises from 14.3 to 31.2. The 4B version rises from 26.9 to 49.5 on GameWorld and from 15.9 to 31.1 on PlayerBench. Both scales are close to doubling.

PlayerBench is a held-out set, with 50 games and 287 tasks, harder than GameWorld's 34 games and 170 tasks. In the comparison provided by the project team, GPT-6.1 Sol's progress on PlayerBench is only 62.6%. One detail shows the model learned controls: Qwen3.5-4B almost never sets key press duration, with only 1% of key presses having a hold time; Game2Player-4B raises that proportion to 47%.

How to use it. The project page has demos, a leaderboard, and trajectory examples; the GitHub repository has the complete pipeline. Installation requires Python 3.12 and Codex CLI or Claude Code. Fill in the game ID, title, and source URL in examples/campaign.yaml, then run tools.game_pipeline to generate environments, tasks, policies, and trajectories. To try playing directly, use play.py; to evaluate, use a rollout config. The models are on HuggingFace. PlayerBench also provides reconstruction instructions; third-party game builds and assets are not distributed with the repository.

Code, model weights, and benchmark task descriptions use the Apache-2.0 license. Gameplay data is still under copyright and redistribution review, and third-party game environments are not distributed directly due to licensing restrictions. What this kind of work truly leaves behind may be a pipeline that can continuously fix environments and produce data. Models will change; only if environments can be fixed can data continue to grow.

Links: Project page Code Model