OhMyGame: a local-first agent studio for making browser games

The problem: one game lives in six tools

Making a game means design documents, 2D art, 3D models, video, code, and somewhere to put the finished thing, and today those live in five or six different tools. The seams between them are where the time goes. A sketch made in one program has to be exported and re-imported; a design doc written in a text file has to be summarised for whoever writes the code; the only way to know whether the game works is to build it and play it by hand. OhMyGame's answer is to put all of it in one app: you describe your game, and the agent designs it, makes the assets, builds it, plays it to check it works, and publishes it to a link you can share. The framing in the project documentation is a one-person game studio, and the audience is solo developers and small teams who would otherwise be the person doing every role.

Two ideas: everything on a canvas, the agent does the work

Two core design ideas shape the app. The first is that everything lives on a canvas. Design docs, concept art, 3D models, and video sit side by side on one board, and one character sketch can grow into more art, a video, or a rigged 3D model, with everything ready to use in your game. Nodes can reference each other, so a character design can lead to more images, a video, or a rigged and animated 3D model, and the results land in a shared Asset Library that your games can use. The second idea is that the agent does the work: it drives the canvas the way you would, drafting the design doc, laying out boards, generating assets on them, then reading the design doc, writing the code, and running the game in a live preview. It then opens the game in a window you can watch and plays it, including real-time canvas and WebGL games, and when it finds a problem it tries a fix and plays again. Along the way it can generate images, video, and 3D models, search the web, and use MCP servers or the Codex and Claude Code plugins you already have.

Your own keys, forty-plus providers, no per-run credits

The commercial model is deliberately conventional. The project works with 40+ model providers through Pi, from Anthropic and OpenAI to DeepSeek and Qwen, and it is bring your own key. Your keys stay on your machine, there are no per-run credits, and what you make is yours. The package description calls it an open-source local-first agent for creating and publishing games, and the local-first part is architectural rather than marketing: the app ships as a desktop build, the build scripts target a host process, a renderer, and a player, and the desktop entry point is a bootstrap script. For teams that already have a relationship with a model vendor, this removes the two objections that usually block an AI tool in a studio: per-seat metering and vendor lock-in on the model layer.

Playtesting is open loop, and the README says so

There is one limitation stated plainly in the source, in a comment kept in the project documentation: playtesting is open loop for now. The agent plans a batch of inputs, runs them, and then looks at the result. It has no real-time reflexes yet. That is a meaningful distinction for anyone evaluating this for action games, because an agent that cannot react during a play session will not discover problems that require mid-game correction. The demo video attached to the documentation shows the agent playtesting a new item feature on desktop and mobile and then reporting what it found, sped up four times. Read that as a demonstration of the report-back loop rather than as evidence of an interactive play session. The agent also writes the code and runs it, which means the code it produces is ordinary project code you can open in any editor.

Web games, interactive stories, and a general mode

The project supports three kinds of output. Web games are described as the best place to start: 2D and 3D games for the browser, built with Three.js, React Three Fiber, or Phaser, following a complete workflow of design doc, key-screen mockups, production art, a playable core loop, and playtesting in the live preview. Games fit any window size, support touch, publish to a shareable link, and the result is a normal web project you can open in any editor. Interactive stories cover interactive films, visual novels, and story games, where each screen is a free web page with its own images, video, and code, connected on a graph, and the runtime handles state, saves, music, and navigation. The runtime is part of the project rather than external, so the agent can change how it plays, and the architecture is documented in the Playable Nodes document under docs. The third mode, General Game, does not assume an engine or stack: you can start from an idea, bring a project in any engine, or make tools and content, with a Game Studio plugin coordinating design, production art, implementation, and verification.

Publishing to a link, and the community list

Distribution is the part that makes the loop feel complete. You sign in and publish, and OhMyGame builds your game and gives it a link anyone can play in the browser. Republishing updates the same link rather than minting a new one, which keeps shared links stable through iteration. Published games are listed in an in-app Community where you can play what others have made, so the same app doubles as a distribution channel and a gallery. The community is worth watching as a signal about the project's direction, because a published-to-link model with a public gallery is a different product shape from a local editor that exports to a folder. The showcase in the documentation shows three games the team made with the tool, an interactive film, an island builder, and a deckbuilding roguelike, which are a reasonable sample of the range.

Running it locally: Bun, Vite, Electron, and optional services

The desktop app is packaged with electron-builder and the repository carries bun.lock and bunfig.toml, so the runtime of choice is Bun. The build splits into three targets, host, renderer, and player, each with its own vite configuration, and the scripts read:

"build": "bun run build:host && bun run build:renderer && bun run build:player",

The desktop build is a longer chain that cleans previous output, generates release notes, prepares preinstalled plugins and examples, and then runs the three builds. The dev script runs the player build and then starts a daemon and a renderer together with concurrently, so a local run is two processes rather than one. Configuration comes from an .env.example file, and reading it tells you what a local run does and does not need:

VITE_SUPABASE_URL=
VITE_SUPABASE_PUBLISHABLE_KEY=

The comment above those lines says they are optional for local development, and that if either value is absent, bun run dev and dev:desktop enable local debug sign-in and publishing, while production builds never enable that fallback. The same file shows the optional pieces: PostHog analytics keys, a Sentry DSN, an optional local Cloud API at http://127.0.0.1:43130 for real account and publishing integration, and a desktop update feed URL. So a first local run needs no accounts, and the sign-in path is explicitly a debug fallback rather than a shipped feature.

Beta status, release cadence, and the licence

The project documentation states plainly that OhMyGame is in beta and to expect rough edges. The version numbers agree: the recent releases are v0.0.0-beta.4.10 on 2026-10-19, v0.0.0-beta.4.9 on 2026-10-16, and v0.0.0-beta.4.8 on 2026-10-14, so the project ships numbered betas roughly every couple of days and the numbering restarts within each beta cycle. The last push was on 2026-10-19, so the work is current. The package manifest marks the package as private, which means it is not published to a public registry from this manifest even though tagged releases exist on GitHub, and the distribution route the badges point to is the download pages for macOS on Apple silicon and Windows x64. Licensing is Apache 2.0, with the LICENSE file in the repository root, so the code can be used and modified commercially provided the notice and licence text are kept. The repository also carries AGENTS.md, CONTRIBUTING.md, SECURITY.md, a CHANGELOG.md, patches, plugins, and a player directory, which tells you this is a real codebase rather than a demo, and the beta label tells you to expect the interfaces to move.

Editorial conclusion

OhMyGame suits solo developers and small teams who want browser games built end to end by an agent while keeping their own model keys on their own machine, and who are comfortable working in the generated project outside the app. It is the wrong tool if you need a native, console, or Unreal project, if you need the agent to react in real time during playtesting, or if you need production reliability from a beta. Before adopting it, check that your target is a browser game, since the web game path with Three.js, React Three Fiber, or Phaser is the documented route, and read the .env.example file to see which optional services a local run expects, because local debug sign-in and publishing work without them.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. WhiteTowerAI/ohmygame on GitHub