Jet Studio Gives Tiny Game Hardware a Godot-Style Editor

Making a tiny game console is one project. Making tools that let you build its games without rewriting every scene in low-level firmware is another.

Jet Studio, by developer fedyfausto, tackles the second problem. Its November 2 prototype 0.7.0 combines a Godot-built desktop interface with a separate C++ game runtime, the Jet renderer and a scripting language called JetScript. The target includes small ESP32-S3 and STM32 boards.

The distinction is important: this is not the full Godot engine squeezed unchanged into a microcontroller. Godot provides the authoring interface. The smaller runtime is what follows the game onto the embedded hardware.

One Runtime, Several Places to Run It

The pinned project documentation describes the same runtime operating inside the editor, in an SDL2 desktop player and in the board firmware. That is a useful design choice: the editor's game view is not simply a separate, more capable renderer pretending to be the final device.

Scenes contain nodes, properties, assets and connections. JetScript uses familiar GDScript-style syntax, but the language and supported runtime are their own system. A similar-looking editor does not make an arbitrary Godot project compatible. Existing scripts, engine extensions and assets still need to fit what Jet Studio actually implements.

The examples make its ambition concrete. Jet Blaster is a side-scrolling shooter; JetRun uses a receding road, curves and sprite-based traffic; other scenes explore physics and textured geometry. These are examples to inspect, not evidence that every game genre will fit the same boards.

Creator-published editor screenshot, not a device photograph. fedyfausto and Godot UI contributors; complete MIT notices. Resized as WebP.

Choose the Board and Display Together

The hardware catalog lists Arduino Nano ESP32 and several ESP32-S3 development-board configurations, plus STM32 targets including the Nucleo-F746ZG. The underlying chip name is not a complete compatibility check. Available memory, flash, display controller, wiring and the selected build configuration all matter.

Jet Studio exposes board, display and input choices in project settings. Its documentation also distinguishes configurations that compile from combinations tested on hardware. That is a better starting point than assuming that two boards with a related processor will behave identically.

The editor tries to make resource limits visible early. It warns about expensive geometry and large textures, and its board-build checks can stop an oversized package with suggestions about which textures to reduce. Those checks cannot guarantee a good frame rate, but they make a concrete hardware budget part of authoring rather than a surprise at the end.

Read the Small Print on Frame Rates

The project reports about 62 frames per second for its shooter on the Nano and 83 on the Nucleo-F746ZG. Those are developer-reported measurements for that example, not independent Meteor Makers benchmarks or universal performance ratings.

There is another qualification in the 0.7.0 documentation: the neon_car test's measurements were taken without a display connected, leaving its real-panel image and physical buttons to be checked. A completed render-loop timing is not automatically a verified end-to-end handheld experience. Different examples also have different measurement conditions; one number should not silently certify all of them.

That warning is a reason to read the repository, not a reason to dismiss it. The prototype exposes enough of its architecture and limitations for another builder to judge what needs testing.

A Practical Starting Point

For a first experiment, keep the evaluation small:

• Match the exact board, memory configuration and display to the documentation.
• Start with one included example before importing a larger scene.
• Check physical controls, panel output and remaining memory, not just a render-loop counter.

That is a proposed evaluation path, not a claim that we performed it.

The MIT license and third-party notices make the code inspectable and reusable under their respective terms. They do not clear arbitrary imported game artwork. The README specifically excludes an unlicensed demonstration car model from the repository, a useful reminder to audit assets separately from an engine's license.

The interesting result is the workflow: small hardware does not have to mean giving up visual scene authoring. It does mean keeping the editor's promises tied to a much smaller runtime and a real device budget.

What would you build on a tiny game board? Tell us in the comments below.