A source build does not establish a working game-making session
OhMyGame's source build succeeded, but its test command failed. The supplied run does not show the studio generating a playable game. For a solo developer considering its shared canvas, that supports a supervised trial while leaving the wider workflow unverified.
OhMyGame is a beta game-making application. Its README describes an agent that designs a game, creates assets, writes code and plays the result. Design documents and media share a canvas and feed an Asset Library. These are upstream descriptions, rather than outcomes demonstrated by the recorded source checks.
The README also says a web game remains a normal web project that you can open in another editor. That makes the studio worth considering if you want an agent-led workspace while retaining access to the generated files.
What happened when we ran it
The supplied November 10, 2026 sandbox run used commit 74d392f. Dependencies installed in 18 seconds, and the source build succeeded in 54 seconds. The test command exited 1 after 303 seconds. Vitest recorded 4,856 passed, 1 failed and 45 skipped out of 4,902 tests.
The supplied tail shows MaxListenersExceededWarning messages about error listeners on a WriteStream. It also shows passing agent-runtime checks and skipped Blender-export and desktop-installer checks. It does not identify the failed assertion or its underlying exception. The excerpt cannot establish that the listener warnings caused the failure or that a particular product feature is broken.
Installation recorded 818 dependencies and 1,069 MB on disk. The checkout was 25.4 MB, with 1,469 files and approximately 278,518 source lines. The scan found three CI workflow files and a tests directory, with no Dockerfile. These figures describe the recorded checkout and source preparation, rather than an installed desktop release. No vulnerability audit result was supplied.
The sandbox configuration listed 3 CPUs, 8 GB RAM and image lab-node:22. Its label does not establish the actual runtime or operating-system version. The run provides no measured desktop installation, model connection, game-generation session or game-quality result. Inspecting the complete failed-test output is the next step before deciding what that failure blocks.
Model connections are part of setup
OhMyGame ships without a model. The README documents provider sign-in or an API key, an existing coding-agent CLI, and custom or local endpoints. A language-model connection covers design and code; generated media needs corresponding provider connections. Installing the application leaves those choices to the user.
The canvas is the reason to consider that setup effort. Documents, images and other media can sit together on a board, with results available through the shared Asset Library. A trial can establish whether that arrangement helps you review assets alongside the design. The supplied run does not establish time savings or better asset quality.
Engine plugins have another prerequisite: the README says they use each engine's own editor and tools, which must be installed first. Its recommended starting point is a Web Game. Keep the first brief small enough to inspect the generated project and play the result yourself.
Local files still involve provider requests
The README says prompts and generation requests go directly to the chosen model providers. Making games locally needs no OhMyGame account; publishing requires one and uploads the game's static build.
According to the README, release builds check for updates and send usage data and crash reports. Usage data is linked to the account after sign-in and can be turned off in Settings. Builds from source send no telemetry. These are upstream privacy statements, not findings from a network inspection.
The README describes Claude Code, Codex and OpenCode running the conversation with their own sign-in. It also documents access from external MCP clients, with an accompanying Skill explaining the workflow. The source checks did not exercise those integrations, their permissions or their media calls.
Platforms and release status
Documented installers target Apple-silicon macOS and Windows x64. The README says the Windows build is not code-signed. Intel Mac and Linux builds appear on its roadmap. Source development has separate requirements: Bun 1.4.2 or newer and Node.js 22.19 or newer for the daemon.
The supplied GitHub API snapshot, observed November 11, 2026, records 27 open issues and PRs. It also records a last push on November 11. The supplied release list includes prerelease v0.0.0-beta.5.5, published November 6, 2026. That listing does not establish that its downloadable artifacts were tested in the sandbox run at commit 74d392f.
Issue 764, opened November 11, reports slight chat-scrolling stutter while several model previews load and proposes stored cover images. The author explicitly says the stutter was observed by hand, not measured. This is a reported preview-loading problem and a proposal, rather than a shipped fix or an explanation for the unidentified test failure.
Choose an editing workflow before choosing the studio
Godot Engine provides a unified interface for creating 2D and 3D games. Consider Godot directly when you want to build and inspect scenes in the engine yourself. OhMyGame also documents a Godot plugin, so the workflows can coexist.
Godogen publishes a runtime manifest, an engine guide and an asset-generation skill into a game repository. Consider Godogen when you want Claude Code or Codex working inside that repository rather than using a studio canvas as the main interface. Neither alternative was benchmarked against OhMyGame in the supplied run.
For OhMyGame, first inspect the complete failed-test log. Then, if the provider setup and documented platforms fit your needs, try one small browser game, inspect its files and play it before relying on the wider studio workflow.