Playgama Sandbox Creates a Faster Route From Prototype to Players

Getting a playable prototype in front of real people remains one of the most difficult parts of game development. Builds must be packaged and distributed, analytics need to be configured, and developers must attract enough players to produce meaningful feedback. Playgama believes browser games can substantially shorten that process because they require no installation, can be shared through a link, and can be updated almost immediately.

Through its new Playgama Sandbox workflow, developers can publish HTML5 projects, add the Playgama Bridge SDK, collect analytics, and begin receiving organic traffic from across the company’s network. Metrics including retention, playtime, performance, tutorial completion, and player drop-off can then help teams identify where a game is succeeding and which parts may require further iteration.

In the following interview, Playgama Founder Dmitry Kachmar discusses how the workflow operates, why human developers retain control over consequential decisions, how Sandbox separates open experimentation from moderated distribution, and why discoverability will become even more important as creating games becomes faster.

Why do you think HTML5 and web gaming have emerged as a popular environment for this sort of game development?

Dmitry Kachmar, Playgama Founder: HTML5 games will become the main laboratory for agentic game development: the place where approaches to using AI in game creation will flourish and come into their own. The technological reasons behind this are fairly clear, so let’s go through them one by one.

For now, the top models from OpenAI and Anthropic both treat HTML5 as their go-to format for building games. Ask GPT-6 Astra or Claude Opus 5.5 to build a game, and it will typically default to something that runs in the browser. Why? Because it’s the format AI models handle best. A web game is built entirely from plain code: HTML, JavaScript, CSS. It’s also accessible in every sense, which makes it easy to play, inspect, and keep refining the build.

Today, a developer can improve their game on Playgama Sandbox cycle after cycle, delegating all or almost all of the manual work to an AI agent. The agent looks at the analytics itself, sees how players interacted with the game, and comes up with improvements. The developer’s role shifts to making the final call: which of the agent’s suggestions to follow and which hypothesis to pursue. Sure, it’s early days, and a lot of things still need polishing on the technical side. But the capabilities themselves work.

HTML5 is the place where agents will master the craft: from game design to tracking player behavior to coming up with hypotheses and improvements based on it. After that, all of this will carry over to the rest of the games industry. But web will stay the most intense arena, because it’s the one place where agents can easily run the full cycle from start to finish.

Can you walk us through what a complete workflow looks like, from prompting an agent in Codex or Claude Code to publishing a playable game, gathering feedback, and releasing subsequent updates?

Dmitry Kachmar: It starts with a one-time setup. The developer adds the Playgama MCP server to Codex, Claude Code, Cursor, or another MCP-compatible client with a single command. From then on, the whole process runs in plain language.

To publish a game, the developer simply asks the agent to upload it to Playgama and return a shareable link. Our MCP gives the agent clear instructions for every step, so it knows exactly what to do. First, it checks that the Playgama Bridge SDK is integrated (it’s required for every game, and if it’s missing, the agent integrates it first), adds a basic set of analytics events, fills in the game’s details, uploads the covers and the build, and waits for our automatic build check. And voilà, the game is live in Sandbox.

Soon after, the game starts getting organic traffic, as it’s surfaced to players across the Playgama network. How far it goes is up to the audience: games that keep people engaged and coming back get recommended more often and more widely.

And it’s worth mentioning that this growing audience pays off from the start. Ad monetization is built in from day one, so the game earns from its very first session.

Once the game has collected enough sessions, the developer asks the agent to look at the stats, right inside Claude Code or Codex. Through MCP, the agent pulls aggregated analytics. That means standard metrics like retention, playtime, and performance, as well as custom events placed in the game by the developer or the agent, such as which upgrade players pick first or where they get stuck on level five.

Data like this shows the agent far more than raw numbers. With well-placed custom events, the agent gets a detailed view of the game: which design decisions are paying off and which aren’t, where players drop off, and what they enjoy doing most.

The developer can then turn that view into any instruction they like. A basic one might be: “Based on how players behaved in the game, suggest what should be improved and how.”

Some developers will review the suggestions and pick what to ship. Others can go further and let the agent apply the changes on its own and upload the new version back to Sandbox. Data from the updated version comes in, and the cycle starts again. Advanced AI users will see right away where this can go: sub-agents checking each other’s work and improvement loops that refine the game with no developer involved.

How can an agent interpret information like retention, playtime, tutorial completion, or player drop-off, and what kinds of game design changes might it be able to make based on that data?

Dmitry Kachmar: An agent works with player data much the way an analyst would, just a lot faster. Some data comes in automatically: as soon as the Bridge SDK is integrated, Playgama records sessions, playtime, retention, ad events, purchases, and performance. And as I mentioned, the developer or the agent itself can add custom events anywhere in the game: tutorial steps, level starts, wins and losses along with the reason, shop visits, currency earned and spent.

Instead of raw event logs, the agent gets data through MCP that we’ve already processed into a form it can read at a glance: the game’s overall performance, detailed breakdowns of individual events, and trends over time. We don’t hand the agent a ready-made recommendation. It gets the evidence and has to reason about it, including checking the sample size and how fresh the data is before drawing conclusions.

Here’s what that can look like in practice. If a large share of players quit at the third tutorial step, the agent can simplify that step, shorten it, or let players skip it. If most failures on level 4 happen because players run out of time, it can rebalance the timer or the difficulty curve. If players open the shop but rarely buy anything, it can rework the prices or the item lineup, and it can edit the in-game catalog directly through MCP. If FPS drops on lower-end devices, it can cut back on effects or optimize rendering. Then it ships the new build, and the next round of data shows whether the hypothesis held.

How do you envision developers collaborating with agents throughout this iteration process, and what decisions should remain in human hands?

Dmitry Kachmar: Nobody knows exactly where this is heading, but we can already see how the roles are splitting: the agent proposes, and the developer decides. The agent comes back with several ways to improve the game, each backed by a hypothesis. Players drop off here, so try A. The economy is too generous, so try B. This level is a difficulty spike, so try C. The developer picks the ones worth shipping.

For now, it seems that everything that defines the game and everything that’s hard to undo should stay in human hands, though I’d stress again that nobody knows what kind of world we’ll be living in six months. The creative vision, what the game is about and who it’s for, belongs to the developer. So do decisions with real consequences, like choosing new platforms to distribute the game to or spending money on user acquisition. We built Playgama MCP around that principle. An agent can upload builds and publish to Playgama Sandbox, but it can’t roll back to a previous version or request payouts. Those remain actions a person takes in the developer console.

But pretty soon, we expect many developers to take themselves out of the loop almost entirely, trusting their agents with day-to-day iteration and checking in periodically to make sure the game keeps growing. However that plays out, the effect on the market is easy to predict. Games will become a much more competitive industry. There will be more of them, and they will get better at a pace we’ve never seen before.

Are there considerations for any potential risks involved with fewer restrictions around agents and how they interact with projects? Will developers be able to tune and customize these sorts of things?

Dmitry Kachmar: Yes, and honestly, a lot of the product design went exactly into that. Our starting point was simple: an agent should only be able to do what the developer has explicitly allowed. When you connect an agent, it goes through OAuth, so before you approve anything, you can see which account, organization, and agent is asking for access. Once it’s connected, the agent shows up in the developer console, where you can revoke its access at any moment. And if it goes unused for 30 days, it simply expires.

Then there’s the question of what an agent is allowed to touch at all. Anything high-stakes or hard to reverse stays with a human. Agents can’t choose new distribution platforms, roll back versions, or do anything related to payouts, and they can’t buy paid traffic in the Sandbox. Those are decisions we think a person should make.

As for customization, we believe developers should decide for themselves how independent and autonomous their agent is. By default, the client asks for confirmation before any action that changes something, since every such action is flagged. But developers can easily change that setting right inside Codex or Claude Code.

All of this will evolve along with the tools themselves. We’ll keep adjusting these guardrails as we see how developers actually work with their agents

How does this approach help solve the discoverability problem for developers, especially as the number of games being created continues to increase?

Dmitry Kachmar: Discoverability is the toughest challenge developers face today, and AI only raises the stakes: the easier games are to build, the harder they are to find. And players are what turn a finished game into a business and a source of insight. Without them, you have neither revenue nor data. Our approach is to give every game a fair first test with real players, and then let player interest, not marketing budgets, decide what grows.

Games that keep players engaged in Sandbox get recommended to a wider audience across the Playgama network and can eventually move to our main catalog. From there, a game can get full external distribution to a potential audience of 450M+ monthly players across 15+ instant-play platforms, including YouTube Playables.

Another thing we’re building is a system in the Sandbox developer dashboard that will suggest what to change in a game to grow its audience and lift its metrics. But realistically, making a game that becomes a hit will get harder, simply because of how many projects are coming out. We’ll most likely see a fundamental shift in recommendation systems: they’ll learn to reason and build far more personalized entertainment feeds.

What technical or creative limitations still need to be overcome?

Dmitry Kachmar: First, AI agents will take on a growing share of the work of analyzing, refining, and improving games. We’re working on tools that let agents measure the impact of each new build and run A/B tests, so instead of comparing this week with last week, an agent can test two versions of a level or a tutorial side by side.

Second is the interface itself, the place where you work with agents while making a game. Neither Codex nor Claude Code was built for making games day to day, and a dedicated environment could offer a much better experience. That’s a direction we’re exploring.

Third, there are the challenges of building a system where many agents and sub-agents work on a game in a continuous loop, with no human developer involved. The technology already makes it possible to build a system that improves a game cycle after cycle and checks its own work: coming up with new hypotheses and picking the best ones. And it doesn’t take many agents and sub-agents, just a few.

So imagine setting up a system like that, leaving it to run, and coming back a week later to open the black box. What will you find: a working product that real people play and love, or another experiment? That’s where much of the work ahead lies.

And that work will move fast, because each model release raises the bar. Within two years, we expect to see an endless, TikTok-style feed of games that are created and refined on the fly, based on how people actually play them. Or perhaps they’ll be games created specifically for you. The future of mass entertainment is an abundance that’s hard to even imagine.

Dmitry Kachmar, Founder of Playgama