How to distill a model that takes the next legal move

A new game feature often begins with a large model making every decision. The model writes an NPC reply, interprets a voice command, chooses an opponent’s turn, or converts a language order into moves.

This is a reasonable way to build the first version. A capable model can handle incomplete instructions and unusual game states before the team has enough examples to train anything more specific. The first working session can show whether the feature is worth pursuing.

The problems appear when the same setup reaches a live game. Each turn has a cost. Each request adds a delay that the player can feel. The request may also send game state to infrastructure outside the environment the studio controls.

This article explains how to move from that first version to a smaller model trained for the game. The main requirement is that the training data must come from actions accepted by the real engine.

The large model is useful for finding the behavior

During early development, the team is still defining what a valid action looks like.

Consider a language order such as, “Move the injured unit behind cover and keep the healer close.” The model has to inspect the current state, identify the relevant units, find legal destinations, and produce commands in the format the game accepts. If the first plan is illegal, the system may need to repair it.

A large model is useful here because the examples are sparse and the requests vary. It can also help the team discover missing rules in the connection to the engine. An action may sound reasonable in language while failing because a path is blocked, an ability is unavailable, or the target changed before execution.

This stage produces more than a demo. It defines the path from a model response to an action the game can execute. That path has to exist before training a smaller model.

The same rule applies to dialogue. An NPC response may need to respect character knowledge, quest state, safety rules, and the actions available at that moment. A voice reply may also trigger a game command. The system needs a clear output format and a way to decide whether the result is acceptable.

Calling a large model on every turn does not scale with play

A model request in a development session is easy to treat as a fixed technical cost. In a live game, it grows with use.

More players create more requests. Longer sessions create more requests. A feature that becomes popular can make its own operating cost harder to support. The studio is paying each time the game needs the next action.

Delay also changes meaning after launch. A developer may accept a long wait while testing a new behavior. A player experiences that wait inside the rhythm of the game. If an opponent pauses before every turn or a voice command takes too long to become an action, the delay can feel like the game has stopped responding.

There is also a data boundary to consider. The model may need unit positions, inventory, quest state, recent dialogue, player instructions, or hidden opponent information. Sending that state to an outside service on every turn creates a continuing dependency that must be reviewed for privacy, security, and availability.

Using a generic open model can change where the model runs and who receives payment. It can improve control over deployment. It does not by itself change the task. A general model may still require substantial computing resources, broad instructions, and a large description of the current game state for every decision.

Common cost fixes can weaken the feature

Teams often try to reduce requests before changing the model’s job.

A script can handle familiar cases cheaply, but it only covers states anticipated by its authors. As more exceptions appear, the script becomes another decision system that must be maintained alongside the model and the game rules.

Calling the large model only on “important” turns requires the system to decide which turns are important. That decision may depend on the same context the model was meant to understand. A routine movement command can become important when an unseen rule makes the expected path illegal.

Replacing the large model with a smaller general model lowers the work per request in some setups. It does not ensure that the result can enter the game. The smaller model still needs to understand the title’s action format, rules, current state, and failure conditions.

These approaches focus on reducing the bill. The harder requirement is preserving the ability to produce the next action that the real game accepts.

The engine must decide which examples are valid

Model distillation trains a smaller model to reproduce useful behavior demonstrated by a larger one. For a game feature, the larger model should create examples by acting through the same path used during play.

A useful record contains the state the model received, the request it interpreted, the action it proposed, and the result of engine validation. If the engine accepts and executes the action, that turn can become a training example.

Rejected actions should not enter the training set as successful outputs. A response that looks plausible in text may still refer to the wrong unit, use an unavailable ability, violate movement rules, or arrive in a format the engine cannot parse.

Silent backups also need to be removed. Suppose the model proposes an invalid move and the runtime quietly substitutes a scripted action. If the log records only that the turn completed, the training process may connect the original request with an action the model never produced. The smaller model then learns from a false example.

Every completed turn should therefore record where its accepted action came from. The record should distinguish a direct model action, a repaired proposal, a large-model handoff, a script, and an engine default. Only the sources chosen for training should become examples.

The training set should represent the real game

Accepted turns are the starting point, but acceptance alone does not make a complete training set.

If most examples come from early missions, common units, or one style of play, the smaller model may perform well in those states and fail elsewhere. The team needs examples from the parts of the game where the feature will operate.

For an opponent, that may include different maps, available units, match phases, and rule changes. For language control, it may include short commands, corrections, references to earlier instructions, and requests that cannot be completed exactly. Dialogue examples may need different quest states and character knowledge.

The large model remains useful for creating examples in difficult or rare states. Teams can direct it toward cases missing from the current data rather than paying for it on every ordinary live turn.

Changes to the game also affect the data. A patch can change which actions are legal or make older choices poor. Training records should identify the game version that accepted each action. The team can then remove outdated examples or test whether they remain valid in the new build.

The smaller model needs a defined handoff

A smaller model should not be expected to answer every request.

The runtime needs a way to detect uncertainty or failure. This may come from the model’s confidence, an invalid output, an engine rejection, or a state that falls outside the examples used for training. No single signal will cover every case, so the choice should be tested against failures in the real game.

When the smaller model is unsure, the system can hand the turn to the large model. That handoff must be visible in logs and operating reports. Otherwise, a feature can appear to run on the smaller model while a hidden backup handles a large share of difficult turns and carries much of the cost.

The player experience also needs to account for the handoff. If it adds a noticeable wait, the game should handle that state deliberately rather than appearing frozen. The appropriate treatment depends on the feature, but the system should not hide the delay from the team measuring it.

Handoffs also provide new examples. If the large model produces an action and the engine accepts it, that turn can be reviewed for later training. Over time, the smaller model can cover more of the states that previously required help.

Testing must use the complete path into the game

A model test that compares generated text with expected text is not enough. Several different outputs may represent good actions, and a fluent answer may still fail when executed.

Testing should run the model against the real action interface and let the engine validate each proposal. The team can then measure whether the action was accepted, whether it completed as intended, how long the full turn took, and which model or backup supplied the final action.

The test set should preserve difficult states and known failures. It should also be run again when the model, prompt, action format, or game rules change. A model can improve on average while becoming worse in a state that matters to players.

Cost should be measured across the whole system. This includes calls to the smaller model, handoffs to the large model, retries after invalid output, and any repair step between the model and the engine. An inexpensive first attempt does not reduce operating cost if it regularly causes several more requests.

Readiness depends on legal actions and sustainable use

The feature is ready for live use when it can take the next legal action in the real game with an operating cost the studio can support after launch.

That judgment should include the rate of accepted actions, response time as experienced by the player, the frequency and cause of large-model handoffs, and the amount of game state sent outside the chosen environment. Results should be separated by game state and feature type so that strong performance in common cases does not hide failures elsewhere.

The large model still has a role after this transition. It can handle hard cases, create accepted examples for missing states, and help the smaller model adapt as the title changes. The difference is that ordinary turns no longer depend on the broadest and most expensive path by default.

This setup begins with the engine interface, because that is where a proposed answer becomes a real game action. Accepted turns provide the training data, rejected and substituted turns stay out, and visible handoffs show where the smaller model still needs help.