miHoYo and Universities Open-Source GameScaling: Game AI Moves From Generating Content to Real-Time Decisions#

Hello everyone, I’m Wubian. On October 22, one message took over the domestic game-AI circle: miHoYo’s Honkai AI R&D team, together with Tsinghua University, Peking University, the University of Chinese Academy of Sciences, the University of Hong Kong, and the National University of Singapore, formally released and open-sourced the GameScaling family of game models. This is not another “AI that generates art assets for you” tool, nor an “AI writes the story” pipeline — it is a model that watches the game screen and then presses the keyboard and mouse for you.

As someone who has long followed game AI applications, my first reaction to any “behavior decision” model is to check three things: the parameter-size tiers, the deployment barrier, and the open-source license. Those three decide whether it is a “paper demo” or “something others can genuinely pick up and use”. Having checked all three, I decided this breakdown was worth writing seriously, because at first glance it passes all three gates: tiers from 0.8B to 27B, small tiers deployable on a single card, and both code and weights released under the Apache 2.0 license.

First, the factual boundaries: every specific fact in this article (parameter sizes, latency figures, training configuration, license terms) is based on this round’s verified fact card, sourced from multiple outlets’ cross-reporting of the official paper and repository; all performance figures are paper-reported, with no independent third-party retest available yet, and flagged one by one below. Also, the companion paper, Scaling in Games: Continued Pre-Training for Embodied Agents in Diverse Virtual Worlds, went up on the preprint platform arXiv on October 20 under number 2610.28698; readers who want the original wording can look it up.

1. Event Snapshot: Who, What Was Open-Sourced, and Where It Lives#

First, the skeleton of the event. The lineup is “one company plus five universities”: miHoYo’s Honkai AI R&D team led, joined by Tsinghua University, Peking University, the University of Chinese Academy of Sciences, the University of Hong Kong, and the National University of Singapore. The deliverable is the GameScaling family of game models; the companion paper went up on arXiv on October 20, and the open-source news was widely reported by domestic tech media on October 22.

A few details worth noting. First, the GitHub repository sits under the THUSI-Lab organization, Hugging Face hosts under the same THUSI-Lab name, and the project homepage is gamescaling.github.io — three entry points, none hard to find. Second, the news broke in a cluster on October 22, two days after the paper went up; this “paper first, coverage later” rhythm is common in academia-industry collaborations. Third, the “Honkai AI R&D team” byline indicates it comes from miHoYo’s internal AI team that directly serves the product line, not an external brand research division — though the team’s specific lead and size have not been disclosed.

2. The Model Family: 8 Checkpoints, One Complete Scaling Experiment#

GameScaling is not a single model but a family: four parameter sizes — 0.8B, 2B, 9B, 27B — each with two versions, S1 and S3, for 8 open-source checkpoints in total. All versions were trained on 1,600 hours of gameplay data.

The naming needs unpacking. The only difference between S1 and S3 is the training-data recipe: S1 is trained on Minecraft data alone, S3 on a multi-game mix in which Minecraft accounts for 27%. In other words, at any parameter size, S1 and S3 form a natural control pair — the former answers “what happens when you train to the limit in a single world”, the latter answers “what happens when you mix in diverse data”. All versions use the same 1,600 hours of training data, pinning the data-quantity variable in place; the remaining differences come entirely from the data recipe and parameter size.

Digging deeper into the experimental tray, the numbers get wilder: there are 5 mix recipes, and behind those recipes lies a data universe of 80 games; the project ran 120 training configurations in total, with data budgets tiered in 6 steps from 50 to 1,600 hours, for a total training compute of 2.2×10^22 FLOPs. That is no longer the scale of “training a model” but of “systematically sweeping the scaling curve” — the Scaling in the paper’s title refers precisely to fitting “data quantity, data diversity, and model size” as experimental variables, tier by tier. This point returns in the scaling-law conclusions in Section 6.

For readers who want to reproduce the experiments, this “tier × recipe” matrix also provides a ready-made experimental design: any question about “does diverse data help” can be tested directly between 9B-S1 and 9B-S3; any question about “does scale help” can be tested between same-recipe versions from 0.8B to 27B. Variables isolated, checkpoints all in place, every version on the same 1,600 hours of data — this open-source matrix is itself the experimental material that accompanies the paper’s scaling experiments. That is why I think it is more worth writing about than “yet another open-source large model”: what it open-sources is an entire, already-assembled experimental bench.

3. The Technical Route: From “Describing the Picture” to “Pressing the Keys”#

GameScaling’s technical route can be compressed into one sentence: on a base that can see images, teach it to act using “gameplay footage with the inputs attached”. Unpacked, there are three layers.

The base: continued pre-training on the Qwen3.5 vision-language model. Choosing a vision-language model as the base is no accident — such models already convert images into semantic understanding, and what GameScaling adds is wiring “understanding the picture” to “outputting actions”.

The data form: training data is gameplay footage annotated with keyboard/mouse actions. Each data point contains not only “what the screen looked like” but also “what the human hand was pressing at that moment”. This is the most consequential trade-off in the whole route: instead of the game engine’s internal interfaces (reading coordinates directly, issuing movement commands directly), the model learns what a human hand actually does — which key to press, where to nudge the mouse, when to scroll the wheel.

Inputs and outputs: each step’s input is the current frame, some prior frames, and the record of prior actions; the output is directly the next keyboard-and-mouse action commands used to control the character. There is no intermediate “plan first, then translate into commands” module — what it outputs is the action itself.

The action granularity is the design most worth singling out. Each model invocation generates an action sequence of about 200 milliseconds, containing 6 action steps of 33 milliseconds each, plus mouse-movement and scroll-wheel commands. What does this granularity mean? Micro-actions at 33-millisecond beats already cover things like “pulling the mouse down slightly to control recoil” or “tapping the dodge-roll key inside the dodge window” — whereas most large-model agents operate at the granularity of semantic commands like “click here” and “go there”, with an entire dimension of “game feel” between the two. By compressing granularity to the millisecond level, GameScaling is, in essence, approaching the action bandwidth of a real player.

3.1 The Full Chain of One Inference Loop#

Stringing the figures above together in time order gives what GameScaling looks like running on one machine. The closed loop has five steps:

1. Observe: the game renders a frame, which — together with some prior frames — goes into the model as visual input; the record of prior actions goes in too, since the model needs to know what it pressed last beat to decide how to follow up this beat.
2. Decide: drawing on the Qwen3.5 base’s visual understanding, the model judges the current situation. The paper-reported single-step latency is 0.13-0.69 seconds; this latency is the entire cost of step 2.
3. Output: the model produces, in one shot, an action sequence of about 200 milliseconds — 6 keyboard/mouse action steps of 33 milliseconds each, plus mouse-movement and scroll-wheel commands.
4. Execute: action-parsing code translates this string of commands into real keyboard and mouse events injected into the game. The character moves, attacks, crafts, and rolls accordingly.
5. Loop: the screen changes because of the actions, and the new frame plus the new action record enter the next round of inference. Round after round, the model “lives” inside the game.

Comparing the time ledgers of steps 2 and 3 makes the picture clearer: the fastest single-step latency is 0.13 seconds, while each output sequence covers about 200 milliseconds of game time — inference speed and action consumption roughly mesh, and only then can this pipeline keep turning without interruption. This is also why Section 4 stresses that “single-card deployability is this route’s survival condition”: any step that slows down produces idle time where the game waits on the model, and real-timeness collapses.

4. The Deployment Barrier: If a Single Card Can Run It, Real-Time Is Possible#

This section is the part hardware readers care about most. The official deployment figures: the 0.8B, 2B, and 9B versions can all be deployed on a single GPU, with the 9B weights at 18.8GB; the 27B version needs two GPUs for tensor parallelism, with weights at 54.7GB. The models can also be served via vLLM.

How to read these numbers? First, everything from 0.8B to 9B runs on one card, meaning a researcher or developer who wants to experiment does not need to request datacenter quota — a card that fits 18.8GB of weights, plus vLLM’s serving path, is a working inference starting point. vLLM is a very mature inference framework in the community, which effectively bypasses the engineering problem of “how to turn a model into a service”.

Second, the repo gives more than weights. The official notes say the repository provides an inference client, system-prompt templates, action-parsing code, and example programs. Those four items together are all the glue between “download the weights” and “the model actually starts pressing keys on your machine” — especially the action-parsing code, which translates the model’s output commands into real keyboard and mouse events. That code looks unremarkable, but writing it yourself reveals how many traps there are. For an open-source project, shipping the glue says more about open-source sincerity than the weights themselves.

Third, and most important to me as an AI researcher: real-timeness is the downstream payoff of single-card deployment. The model must produce actions every 200 milliseconds, which means its inference latency must stay on the same order as the game’s rhythm — this naturally excludes heavyweight “four cards minimum” deployments. In other words, the 0.8B-to-9B tier design is not just about saving money; it is this technical route’s own survival condition.

5. The Most Dramatic Numbers: The Score Reversal Between Paused and Real-Time Modes#

If I could show only one set of numbers to convey why this model matters, I would pick the paper’s comparison between the “paused mode” and the “real-time mode”. First the latency: GameScaling’s single-step latency is 0.13-0.69 seconds, while frontier models need 4-24 seconds per step. More than an order of magnitude apart.

Then the scores under the two modes (paper figures):

Reading these numbers matters more than the numbers themselves. Under the paused mode, the frontier models’ 54-88.7 points clearly beat GameScaling-9B-S3’s 44.7 — unsurprising: frontier models are smarter, and given time to think, they think up better strategies. But the moment the mode flips to real-time — no pausing, only a fraction of a second per step — the frontier models collapse to 5.3-8.7 points while GameScaling still scores 36.7. The ranking completely reverses.

This is what I mean by “can do exam problems” and “can press keys in real time” being two different abilities. Frontier models are like contestants who ace the written test but cannot keep up at the controls; GameScaling concedes some on paper intelligence, but its architecture and granularity are designed for the real-time loop of “watch the screen, output actions”. Games are precisely real-time environments — the game will not pause while you finish inferring. This score reversal is the paper’s most persuasive argument for the industry.

To be scrupulous: all scores above are paper-reported, with no independent third-party retest yet; the complete per-benchmark score tables for the 2B tier and for other benchmarks were not obtained this round, and nothing is filled in or extrapolated here.

6. The Evaluation Matrix and Scaling Law: Four Conclusions All Point to “Diversity”#

The evaluations cover four benchmarks: MCU (30 Minecraft tasks), ViZDoom (Doom-themed combat and pathfinding), OmniGameArena (7 unseen 3D worlds), and GameWorld (mostly 2D/2.5D games). Specific tasks range from Minecraft’s mining, item crafting, and fighting zombies to escape-room puzzles and escapes — coverage running from survival-and-gathering all the way to action combat.

One of the paper’s core contributions is fitting “data quantity, data diversity, and model size” into a scaling law whose validation-loss R² reaches 0.98-0.996 — a remarkably clean fit. The conclusions read off this curve are, I think, each worth every practitioner remembering:

1. More data, better performance in similar worlds. The most intuitive conclusion, and the foundation that makes the scaling experiment valid.
2. Diversity lifts “similar worlds” but offers limited gains for very different ones. In other words, mixed data buys “neighborhood transfer”, not “universal generalization” — gathering logic learned in Minecraft might help the model pick up another sandbox game faster, but it will not help it play a fighting game.
3. Bigger models are more data-efficient; but when trained on a single world only, bigger transfers worse. This is a caution against naive “just scale up” optimism: a large model overfit to one world performs worse in unfamiliar worlds.
4. Test-time scaling works too. Raising the inference-time step cap from 600 to 3,000 lifted the 9B version’s score from 50.9% to 69.3% and the 0.8B version from 42.3% to 59.3% — no retraining, just more decision steps, and scores rise significantly.

And the single most striking number in the whole comparison: the Qwen3.5-9B base without continued pre-training crawled only from 2% to 4% on the same evaluations. A base model that can see images cannot play games at all; what pulls scores from single digits into the fifties and sixties is precisely those 1,600 hours of input-annotated footage. This contrast nails down the value of the “continued pre-training” step.

Putting the four conclusions back into Section 2’s experimental design reveals one more layer of implication: since “single-world-only training transfers worse”, scenarios that demand generalization should prefer S3 among the 8 checkpoints; and since “diversity’s transfer radius is limited”, the 27% Minecraft share in S3’s mix against the remaining 73% multi-game ratio is, in essence, transfer fuel reserved for “similar worlds”. Naming the checkpoints S1 and S3 separately is itself a reminder to users: these two versions are not answering the same question.

One more engineering detail deserves a look: the system-prompt template in the repo. A behavior-decision model’s output form differs from a chat model’s — it must produce not a paragraph but a string of structured action commands. The system-prompt template dictates the format in which the model emits actions, and the action-parsing code consumes exactly that format. Together, the two files amount to open-sourcing the “model output protocol” as well; third parties integrating it do not have to guess the format from output samples — one more sign that the inference-side engineering is complete.

7. Open-Source Scope: What Was Given, What Was Not#

On licensing: both code and model weights are under the Apache 2.0 license — among the most permissive of mainstream open-source licenses. Researchers doing follow-up research and developers doing integration validation face no licensing obstacles.

But the open-source scope has clear edges: the training code and training corpus were not released with the model. What you get is “the finished trained artifact” plus “the full toolkit for using it” (inference client, system-prompt template, action-parsing code, example programs), not “the process of training it from scratch”. In the community’s idiom: you can reproduce the result, not the process. For researchers who want to build on it, this means two things — fine-tuning, evaluating, and building applications on the existing weights are all open; but rebuilding the training pipeline, or trying to verify one particular curve among the 5 recipes and 120 configurations, hits a wall without the original data.

Another notable statement comes from the project page: the project notes it is “a pure research project with no commercial activity of any kind”, that match footage is used only to present research results, and that game footage copyright belongs to the respective publishers. Read alongside Apache 2.0’s permissiveness, the boundary is actually quite clear: the model itself is open under a permissive license, but the game content it “saw” during training does not belong to the project, and the project does no commercialization itself. What these constraints mean for downstream users touches the rights boundaries of each game publisher, and this article makes no assertion — interested readers should judge for themselves against the license text and the project-page statement.

8. The Fork in the Road: Behavior-Decision Models vs World Models#

Having come this far, GameScaling needs locating on the larger map of game AI. The excitement in game AI over the past two years has concentrated on two mutually independent routes, and GameScaling happens to be a key specimen of one of them.

Route one: content generation. Models on this route take over “where game content comes from” — generating images, generating levels, even rendering an entire game world in real time. The previously dissected Kunlun Tech Matrix-Game 4.0 is a representative of this route: the model itself generates playable game footage, and the player plays inside that frame-by-frame generated picture; interested readers can turn to that world-model breakdown for comparison.

Route two: real-time behavior decisions. Models on this route do not touch the game engine and generate no imagery — the game remains the original game, and the model plays the “player position”: watch the screen, think of a move, output the action. GameScaling is a textbook specimen of route two: its input is frames and action history, its output is keyboard/mouse commands, and it does not change a single frame of the game world itself.

The two routes are not competitors but a division of labor: one answers “who makes the game’s content”, the other answers “who plays the behaviors inside the game”. In player experience, the former decides “where the game world comes from”, the latter decides “whether the agent fighting beside or against you feels human”. Interestingly, both routes have made “runs on consumer hardware” the focus of the second-half 2026 arms race — GameScaling making its small tiers single-card deployable is exactly the same direction. As for the two routes converging in one product someday (say, a behavior-decision model playing the opponent while generated content lays out the world), neither party has disclosed anything; that is my outlook, not a fact.

9. For Players and the Industry: What Is Certain and What Is Not#

Finally, separating “what we can be sure of” from “what we cannot” — my standing rule for AI topics.

What we can be sure of: the 8 checkpoints are downloadable; 0.8B to 9B deploy on a single card; the repo ships a full inference toolchain; the license is permissive. For researchers, this is one of the lowest-barrier game behavior-decision models in years for “pick up and reproduce” — previous similar efforts mostly stalled at papers and demo videos, with weights either unopened or opened without a deployment path. For developers, “a model that can press keys in real time” is, for the first time, this close to consumer hardware; for engineering directions like automated game testing and agent-versus-agent drills, the technical preconditions just shrank by two more items compared with a month ago.

What we cannot be sure of: neither the officials nor the project page says whether, or how, the model is applied to miHoYo’s own game products — any claim that “it will appear in miHoYo’s next game” is speculation; beyond the “pure research project, no commercial activity” statement there is no further commercialization information; apart from the paper’s figures there is no independent third-party retest, so all scores should be treated as officially self-reported; and the specific lead and size of miHoYo’s Honkai AI team are also undisclosed. I will not fill these gaps with conjecture.

One more observation worth writing down separately: in the joint-university lineup, five universities — Tsinghua, Peking University, the University of Chinese Academy of Sciences, the University of Hong Kong, and the National University of Singapore — stand alongside the corporate R&D team, and the paper’s main title uses Scaling, the word the machine-learning community prizes most. Industry brings the data and engineering; academia brings the experimental method and the paper; the two completed a clearly divided co-authorship on the topic of “embodied intelligence in virtual worlds” — this “company-led, university-co-built” form may well become a common configuration in game AI over the next few years.

Closing#

Before wrapping up, here is a quick-reference card condensing the article’s key numbers for future citation:

• 8 open-source checkpoints: 0.8B / 2B / 9B / 27B × S1 / S3
• All versions trained on the same 1,600 hours of data; Minecraft 27% of S3’s mix, from an 80-game data universe
• Per invocation, outputs an action sequence of about 200 milliseconds (6 steps × 33 milliseconds + mouse movement and scroll wheel)
• Single-step latency of 0.13-0.69 seconds, versus 4-24 seconds per step for frontier models
• Deployment: 9B weights 18.8GB on a single card; 27B weights 54.7GB on two cards with tensor parallelism; vLLM supported
• License: Apache 2.0 for both code and weights; training code and corpus not released
• Paper: arXiv 2610.28698, posted 2026-10-20

Between “AI generates content for games” and “AI makes real-time decisions inside games”, the gap is not one of model scale but of the nature of the capability: one must be fast, precise, and steady-handed; the other must be beautiful, rich, and playable. With its 0.13-0.69-second single-step latency and its score reversal under real-time rules, GameScaling has demonstrated the first route’s viability; and with single-card deployability and Apache 2.0, it has pressed the barrier to entry down to the height of one graphics card.

For players, it is, for now, a laboratory object; for researchers, a complete experimental platform ready to reproduce out of the box; for the industry, the first systematic piece of the “behavior decision” route on game AI’s 2026 map. Whether this “model that can press keyboard and mouse” lands first in test pipelines or beside players is a question we leave to the coming months.

— Wubian, NTGame Editorial