GB Studio: a drag-and-drop Game Boy game creator, and its CLI

What GB Studio is for, and who it is not for

GB Studio targets a specific gap: people who want to make a game that runs on Game Boy hardware but do not want to write C against GBDK. The README describes it as a "quick and easy to use retro game creator for Game Boy available for Mac, Linux and Windows", and the repository description calls it a drag and drop retro game creator. The audience is writers, pixel artists and hobbyists who can assemble scenes and events visually, not engine programmers.

The scope is deliberately narrow. It produces Game Boy ROMs and, per the CLI, Pocket files and web builds. It is not a general 2D engine with a Game Boy export bolted on; the whole application exists to emit a ROM that fits the console's constraints. If your target is a modern platform, a browser-first game, or anything with more than the Game Boy's memory and colour limits, this is the wrong tool and no amount of plugin work changes that.

One thing worth stating plainly: the GUI is the product. The README leads with downloads for Mac, Linux and Windows, and the source-build path exists mainly for contributors and for people who want the CLI. Treat the editor as the interface and the CLI as the automation surface.

Electron shell, GBVM engine, GBDK underneath

The README is explicit about the architecture: GB Studio consists of an Electron game builder application and GBVM, "a C-based game engine using GBDK". So there are three layers. The Electron app is the editor and the project format owner. GBVM is the runtime that the exported project compiles against. GBDK is the C toolchain that turns the generated C and assets into a ROM.

The data flow follows from that. A project is a .gbsproj file. The CLI's export command turns it into a GBDK project on disk, writing src/data and include/data when you pass -d. The make:rom command goes further and compiles that project into a .gb file. That means the editor is not required to produce a ROM, which is the single most consequential fact about the project for anyone automating builds.

Because GBVM and GBDK are fetched rather than vendored, the toolchain version is a moving part. The README warns that after checking out a new version you may need to fetch dependencies again "to ensure you have the latest version of GBVM + GBDK etc". That is a normal pattern for a project that tracks an external compiler, but it also means a build can change behaviour without any change to your .gbsproj.

Installing GB Studio and building a first ROM

For most users the README points at the downloads page: "Download a release for your operating system from the GB Studio Downloads page." That is the intended path and there are no build steps to describe for it.

Running from source is documented and is what you need for the CLI. The README requires NodeJS, with the required version given in .nvmrc. The package.json engines field pins it harder: node >=24.16.0 <25. The README states that GB Studio currently uses Node 24 LTS. Clone the repository and run:

cd gb-studio
corepack enable
yarn
npm run fetch-deps
npm start

corepack enable makes the Yarn version from .yarnrc.yml available, yarn installs dependencies, and npm run fetch-deps pulls GBVM and GBDK. npm start launches the Electron app. If you have NVM, the README offers nvm use inside the repository to switch to the supported Node version from .nvmrc.

The CLI is a separate build target. The README's steps are:

npm run make:cli
yarn link
$(yarn bin gb-studio-cli) -V
$(yarn bin gb-studio-cli) --help

yarn link is only needed the first time; after pulling new code, npm run make:cli is enough. Once linked, the interesting command is make:rom, which takes a project file and an output path:

$(yarn bin gb-studio-cli) make:rom path/to/project.gbsproj out/game.gb

You should end up with a .gb file at out/game.gb. Adding --usage prints a ROM usage report to stdout, which is the practical way to see how close a project is to the console's limits. The same CLI exposes make:web and make:pocket for browser and Pocket builds, and export for dumping the GBDK project without compiling it.

The ROM budget is the real constraint

The --usage flag exists because ROM space runs out. The Game Boy has a fixed cartridge budget and GB Studio projects grow quietly: tilesets, sprites, music and event data all consume it. A project that plays fine in the editor can fail to build or produce a ROM that misbehaves once assets push past what fits. The README does not describe a graceful degradation path here, so the usage report is the only signal the CLI gives you before you hit the wall.

There is a second, quieter failure mode around the toolchain. Because GBVM and GBDK are fetched by npm run fetch-deps rather than pinned inside the repository, a fresh checkout can pull a different compiler than the one a project was authored against. The README treats re-fetching as routine maintenance. For a solo project that is fine. For a team building the same .gbsproj on two machines, it is a reproducibility question the documentation does not answer.

The third is the project format itself. A .gbsproj is owned by the editor version that wrote it. The README does not document rollback, and no migration guide is published. If you open and save a project in a newer GB Studio, you should assume you cannot go back to the older editor, so keep the project under version control and tag the editor release alongside it.

Where GB Studio sits against writing GBDK directly

The obvious alternative is GBDK itself, the C toolchain GB Studio compiles against. The difference is who owns the structure. With GBDK you write C, manage your own scene and sprite systems, and control memory layout by hand. With GB Studio you assemble scenes and events in the editor, and GBVM generates the C for you. The trade is control for speed: GBDK lets you do things GBVM has no event for, at the cost of writing and debugging all the glue yourself.

There is a middle path the CLI makes available, and it is the most underrated part of the project. `export -d` writes only src/data and include/data from a .gbsproj. That gives you the generated data as a starting point for a hand-written GBDK project, so you can prototype the level layout and event logic visually and then take the output into C. The README documents this command but does not describe a workflow around it, which is a gap: it is the natural escape hatch for projects that outgrow the editor, and nothing in the documentation tells you how the exported data is meant to be consumed.

A second alternative is a general-purpose engine with a retro aesthetic. That gets you a modern target and modern tooling, and it does not get you a .gb file. The two are not substitutes.

Licence, maintenance and the cost of upgrading

GB Studio is released under the MIT license, copyright 2019-2026 Chris Maltby per the README. MIT is permissive: you can use, modify and redistribute the code, including in commercial projects, provided the copyright notice and permission notice are preserved. The README does not state a separate licence for exported game content or for the GBVM and GBDK components, so if you are shipping a commercial ROM, check the licences of those dependencies rather than assuming the MIT header covers everything. That is a question for your own review, not legal advice.

The repository is not archived, and the last push was on 2026-09-21. Releases are frequent enough to matter: v4.3.0, v4.3.1 and v4.3.2 landed between 2026-06-08 and 2026-06-22. Upgrading therefore has two costs. The first is the editor download, which is trivial. The second is the toolchain refresh, which is not: after checking out a new version the README says you may need to run npm run fetch-deps again to pick up GBVM and GBDK. Budget for a rebuild and a re-export after any editor upgrade, and keep the previous editor release available in case a project does not open cleanly in the new one. The README does not document a downgrade path.

Editorial conclusion

Adopt GB Studio if you want to ship a Game Boy ROM without writing C, and especially if you want the CLI in a build pipeline: make:rom and make:web take a .gbsproj and produce output non-interactively. Do not adopt it if you need a general-purpose engine, a modern target, or a documented rollback path for project format changes; the README does not document rollback, and the project file format is tied to the editor version. Verify first that your Node version matches the .nvmrc and the engines field in package.json, that npm run fetch-deps pulls the GBVM and GBDK versions your project expects, and that the exported GBDK project still compiles outside the editor.

Frequently asked questions

Official sources

1. chrismaltby/gb-studio on GitHub
2. License: MIT
3. Project website
4. README
5. Releases