You build on a computer, even when the game is for a phone

Stage Engine is a desktop application. You install it on a Mac or a Windows machine, you build there, and the game runs locally on the copy of Godot bundled with the app. There is no phone app, no tablet editor and no browser version.

It also does not handle store submission. Nothing here signs a build, fills in a store listing, or talks to Apple or Google on your behalf. If you were looking for a tool that takes a prompt and returns a live App Store listing, that is not this, and it is better to say so on the first screen than the fifth.

What it does is remove the code. That is a large removal, and for most people it is the actual obstacle.

Every mobile game you have played was made on a computer. Phones are for testing, not authoring. A 6-inch screen with no keyboard is a poor place to lay out a level, tune a curve or watch a scene at framerate.

The place a phone-first tool ends up is a template gallery with sliders, because that is what fits on the screen. You get something quickly and you hit the wall quickly. A desktop builder with a real 3D viewport is a different kind of tool with a different ceiling.

So the honest framing is: build on the desktop, play on the desktop while you iterate, and treat the phone as the destination rather than the workshop.

Stage Engine is a capability layer on top of Godot. Your project is a plain Godot project, not a proprietary file. Godot is open source and widely used, including for games that ship on phones, so the project you build here is not a dead end when you start thinking about a device.

The work of getting a build onto a device, the signing, the store accounts and the review process is yours. Stage Engine is where the game gets designed, built and made good.

That distinction is worth holding on to. Being locked out of code is what stops most people from ever having a game to publish. The publishing pipeline is bureaucratic, but it is documented, and it is not the part that ends projects.

The decisions that make or break a mobile game are made early. Whether it plays one-handed. Whether the touch targets are reachable. Whether a session is two minutes or twenty. Whether the thing on screen is legible at arm's length in daylight.

You can hold all of those while you build, and you should, because they change the design rather than the port. Input is code: describe a drag, a tap-and-hold, a swipe, and Director 1 writes the GDScript for it in your project.

Then you play it and say whether it feels right. That loop is the work. Not writing the code has never meant not judging the result.

The download is free and there is a free plan. Indie is $10 a month and Pro is $50. Paid plans buy more usage, not a different engine, and there is no team or per-seat tier.

Building needs an internet connection, because Director 1, asset generation and world data come over the network. Playing what you have built does not.

Sessions are short and interrupted. Someone will close your game mid-level because a train arrived. That makes saving constantly, resuming exactly, and never punishing an interruption into design requirements rather than polish.

Screen real estate is the other constraint. Anything the thumb covers is invisible, and a heads-up display that works on a monitor is a wall of clutter at phone size. Deciding what to remove is design work and it is yours.

Both of those turn into code, and code is what Director 1 writes. Describe a save-on-every-action rule or a layout that keeps the bottom third clear, play it, and say whether it works. The judgement is the part you supply, and it is the part that decides whether the game is good.