Platforms & export targets#

Ignitor is built so the game you author is mostly data — rooms, dialogue, puzzles, animations and art — sitting on top of a small, portable engine. That design is what lets one project reach many platforms: your content carries over for free, and only the engine gets re-wrapped for each target.

This page is deliberately honest about how far each target actually goes today. A young engine earns trust by under-promising ports, not over-promising them — so every platform below is graded by what Ignitor really does right now, with a clear line between "press export" and "here's the part you'll still do yourself."

How to read this page#

Roadmap (⚪) targets are shown as exactly that — a roadmap with the real gates named. They are never something you simply "turn on."

At a glance#

Desktop#

Windows — the one-click target#

Windows is the fully shipped path. From the Distribution Manager you press Compile, and Ignitor packages your active project into a portable Windows package — a small executable that uses the system's built-in web view, not a bundled browser, so the download stays lean. There's no toolchain to install: packaging uses a precompiled template that ships inside Ignitor.

Ignitor handles: assembling your project, naming the app from your project's title and version, and building the final package — with a live build log.

You still do: optionally buy a code-signing certificate to remove the "unknown publisher" warning Windows shows for unsigned apps; and set up a store page (Steam, itch.io) if you're selling.

The only friction most people hit is the unsigned-app warning, and that's a certificate purchase, not a missing feature.

macOS#

The engine runs unmodified on macOS, and the Distribution Manager's macOS tile builds a real .dmg there — the build toolchain is proven, not just theoretical. It has to run on a Mac (the .dmg packaging can only happen on macOS), and what's left before you can distribute is Apple's own gate: you sign and notarize the app with your own Apple Developer account, or macOS blocks it as "damaged / unidentified developer."

Linux & Steam Deck#

The same desktop pipeline that builds Windows also builds a Linux .AppImage — the Distribution Manager's Linux tile is one-click, but only actionable on a Linux build machine (or a Linux CI runner) — the Linux bundle can't be built from Windows.

Steam Deck isn't a separate build. The Distribution Manager's Build for Deck button produces the exact same Windows .exe as the regular desktop target — just framed for the Deck. That's genuinely enough: the Deck runs Windows games through Proton out of the box, and gamepad navigation already ships in every build, so point-and-click works on the controller with no extra step from us. The only thing left on your side is Steam's own last mile — add the .exe as a non-Steam game and force Proton compatibility in its properties. There's no dedicated Deck packaging or Deck-specific testing beyond that; it's the Windows build, playing where Windows games play.

Web / HTML5#

This is the lowest-effort target, because an Ignitor game is a web app already. The desktop build produces a clean, self-contained folder that is, structurally, a deployable website: relative asset paths, saves stored locally in the browser, no server required.

Ignitor handles: the export itself — Distribution Manager → Export Web (.zip) builds a clean, itch.io-ready zip in one click (entry page at the archive root, viewport + touch tuned for embeds), on the free tier.

You still do: host it. On itch.io: create a project, set Kind of project to HTML, upload the zip, tick This file will be played in the browser, then turn on Mobile friendly and the Fullscreen button in the embed options. Or just unzip it onto any static host. It runs as an online page — there's no offline/installable web packaging at this stage.

Heads-up: the web build is also your most exposed target — the game's code ships as readable-ish files on a host. Every export (web and desktop/mobile alike) now runs through a built-in, modest JS obfuscation pass automatically — it raises the bar against casual copying, not a DRM promise, and you don't have to turn it on. Assets also travel packed (not as loose, readable files), and you can turn on domain protection: a locked web export refuses to run if it's re-hosted on a domain you didn't authorize.

Mobile#

Android#

The Android path is proven end to end: touch input (tap to walk, verb interactions, long-press for the default verb, hotspot highlight) shipped as real engine work, not a wrapper hack, so it's the same touch handling every platform benefits from. The Distribution Manager's Android tile builds a real .apk — and the first time, it downloads and configures the toolchain for you (JDK 17 and the Android SDK; automatic, with your consent, and one-time). Saves work offline.

You still do: provide your own release keystore (never committed — Ignitor signs the AAB with it, with an automatic versionCode); and, for Google Play, the Play Console account and store listing. A phone in landscape is letterboxed today; a tablet is the comfortable fit.

iOS#

iOS shares the same touch-input work Android proved, plus the same Mac template machinery that produces the .dmg above. Two ways in:

• A free Safari / PWA dry-run — serve the web build over HTTPS and it runs in mobile Safari (the same engine the native app uses); "Add to Home Screen" gives a chromeless demo. No Mac or Apple account needed.
• A native .ipa — the Distribution Manager's iOS tile builds one on a Mac. The unsigned .ipa is proven end to end; distribution signing layers on top of it, with your Apple Developer account.

You still do: a Mac to build on, and Apple's own signing — a free Apple ID for short-lived demo profiles, or an Apple Developer account (~$99/yr) for final signing, TestFlight and a real App Store submission (budget for at least one review cycle). That whole stretch is Apple's, and happens outside Ignitor.

Consoles#

Consoles (PlayStation, Xbox, Nintendo Switch) cannot run web technology — there's no certified web-view path. Reaching them means a native port of the engine to Godot 4, after which your content (still just data) carries over. This is a real engineering project, not an export button — but the architecture is designed to make it a bounded project rather than a rewrite, and we've already banked some of that work (a conformance test suite the native port can be checked against).

The Godot bridge — a paid conversion service, not a DIY port#

We're building the Godot bridge as a paid cloud conversion service, not a toolchain you run yourself: you'll upload your exported content, our server runs it through one maintained Godot runtime, and you get back a real Godot 4 project loading your content as-is. We keep the engine small and pure specifically so this conversion stays mechanical and reliable release over release. What exists today is the readiness — the design, the data formats, and a conformance test suite the Godot runtime is checked against — not a finished service you can use yet or a console build you can produce from the editor.

PlayStation, Xbox & Nintendo Switch#

These ride on top of the Godot bridge and then hit the non-technical gates that dominate console shipping:

• Platform developer approval (Sony / Microsoft / Nintendo) and dev hardware.
• A porting partner under NDA — Godot doesn't ship console exports itself; a licensed partner provides them.
• Age rating and the platform's certification (save behavior, suspend/resume, controllers, localization).

A couple of honest specifics: Xbox we have not yet researched in depth, so we don't put promises on it; and Nintendo Switch is the most memory-constrained target, where a game that's fine on PC may need an asset diet to fit. These are genuine "someday" targets — feasible by design, but gated by licensing and certification rather than by Ignitor.

What's shipped, and what's left#

The near-term checklist that used to live here is done: one-click Web export, the Linux build in the Distribution Manager, gamepad navigation (which is what makes Steam Deck a real one-click target), Android's touch input and polish, and the built-in JS obfuscation pass all ship today. Every platform in the table above except the consoles row is a real, working build path in the Distribution Manager right now.

The one front that's still genuinely ahead of us is the console row: standing up the paid Godot conversion service itself, then the licensing/partner/certification chain each platform holder requires on top of it. That work stays parked until a game is finished and the investment is justified — exactly the posture the rest of this page takes toward every other "someday."