The same agents through the life of a game

A game is thought up, built, balanced, shipped, and then balanced again. At every one of those stages, the people making it need the same thing, and they never have enough of it: the real game, played in enough different ways that they can trust what they think they saw.

Most AI tools do not follow that path. They are built for one room. One tool helps with early concepts. Another is a bot that follows a fixed script during a QA pass. Another is a dashboard after launch. When the game moves to the next stage, the team starts over, and whatever the last tool learned does not come with them.

This post explains a different setup. You design agents that can play your game, inside the real rules, the way people play. You use those agents for design and QA from the first version you can actually play through the years after launch. Later, if you want players to give orders in language, play a lighter mode from a phone, or face AI opponents in matchmaking, you are using the same agents with people, not only on tests.

We built Playthrough and Playthrough Console for the design and QA half of that path, and Playable for the player-facing half. They are two uses of one system.

Why design needs play at every stage

Early on, a designer is trying to find out how people might use a new system before there are players. A paper design and a few internal games are not enough when the game has many rules that interact. The interesting cases are combinations nobody sat down to write: two items, a map, a disconnect, a skill level that uses the new system in an unexpected way.

During production, QA asks whether the build works, and design asks whether a change in the rules is acceptable. Those are different jobs. A short pass with scripted bots can tell you the shop takes money and the player's game stays in agreement with the server. It cannot tell you whether a new unit changed how people should play, or whether that change is one you want. That question only gets answered by playing under the real rules.

After launch, the same question comes back every time you ship a patch. You have clips, charts, and forum posts within hours. You usually cannot open the matches that produced them. You also cannot wait a week for the people already playing to teach you what the patch did.

Human playtests matter at all of these stages. People notice whether the game is satisfying to play, they catch obvious bugs, and they try things a designer did not plan for. They are also few, slow, and they tend to play the intended way. Five people in a room will not cover a game with many interacting systems. Bots that follow a fixed script add volume on the paths you already knew. Live data can tell you something moved, and it does not give you the match.

What is missing is more games in the real build, played in different ways, that someone on the team can open again. That need does not change from the first version you can play to year three after launch. Only the schedule changes.

Agents that play the real game

The agents we build with a studio are designed for that game. They are not a generic bot dropped on top of it. They take moves the real game allows. They play the way people play, which means they do not do the same thing twice.

If an agent only repeats a script, you will keep rediscovering the paths you already knew. If it can start differently, miss a move, and run into a combination that plays badly, the set of matches looks more like a group of real players than a short run of scripted bots. You can get that set before anyone is in matchmaking, and you can get it again the morning a patch is live.

Because the agents act inside the real game, a designer can open a match and see a sequence the game actually allowed. A chat demo that looks smart is easy to confuse with a build that lets the agent take the move. Playing in the real game is how you avoid that confusion.

As the game changes, the agents have to change with it. New content, and a way of playing that did not exist last season, will make last month's agent a poor stand-in for this week's players. You update the agents so they know those patterns and keep producing useful matches as the game grows.

Working with the matches

A set of matches is only useful if the team can work with it. Playthrough Console is the place that happens.

You ask a question the way you would ask any capable AI tool. What are people likely to do with this new unit. Did this change actually move the fight. Where did last night's patch break. Is this item showing up in winning games more than it should. The console can pull the relevant games, look at the set, mark what stands out, and raise the next question. If a number looks sure, you open the games behind it. If the worst games look broken, you are looking at a replay.

The same habit works before the game is finished and the morning after a patch. The questions change. The method stays the same. You ask, look at the matches, open the ones that matter, and decide.

This is how agents help QA and balancing in ordinary studio work. QA spends more time on failures that already showed up in the matches, and less time rediscovering the same crash. Design spends more time deciding whether the game is satisfying to play, and on the cases a number cannot decide, and less time arguing from a clip they cannot reopen. Human play still happens. It starts after you already know which claims are real.

After the game launches

Once the game is live, the job is the same and the clock is worse. New content ships more often than it used to. The old habit assumed you had time for a long playtest before a change reached players. That is often no longer true.

Agents that already know the game can play the new rules before the patch is public, and again the morning it is live. The questions in the console become the ones a live team actually asks: take the change back, ship a fast fix, or wait. You still read the community and watch the dashboards. The difference is that when someone asks whether to take the change back, you have matches you can open.

The same agents for players

Once agents can take moves the real game allows, they can do work that is not a test.

They can sit in matchmaking as AI players. That is useful when a new game needs opponents, when a mode needs partners, or when you want players at more than one skill level without hiring a room full of people.

They can also take a plan a person says in language and turn it into those same allowed moves. The player says what they want to do, and the agent carries it out inside the rules. The game keeps its depth, and the way you give orders changes.

The same idea works as a language-only mode on a phone for a game that has historically only worked on a computer or a console. A player can do the repetitive parts, follow the current strategies, or play a lighter mode by speaking or typing, then come back to the full controls when they want them. We reached a polished version of this on Arena Tactics in about four weeks, on a game with a lot of on-screen controls, because language was standing in for the parts of the interface that do not fit a phone.

We call this player-facing side Playable. It is the same agents, used with a person instead of only on a test plan. A studio can start with Playthrough because that is the job they have today: more real play for design and QA, from first ideas through the years after launch. When they are ready to open the game to people who would not sit down at the original interface, they are not starting over.

How this usually starts

The cheapest place to begin is the game you already have, not a new mode.

Sit with the people who own design and QA. Build agents that can play that game. Run them in the real engine. Put the matches in front of the team in a console they can query. Use that loop on the next balance change and the next patch. If the agents cannot play the game, the later uses will not work either. If they can, you have play you can trust at every stage you already run.

Language modes, phone companions, and AI in matchmaking come later. They become possible because the agents already know the rules, not because you started a separate AI project for players.