The platform selector next to the prompt offers two options: Mobile Game and PC & Console Game. It is not an export target, and it does not restrict where the game can be played — every generated game ships playable on both, because the app shell binds keyboard, gamepad, and touch to the same actions.

What it decides is which platform the game is designed around. That drives the screen orientation and tells the planner which control scheme the mechanics have to be built for — and those two things reach much further into the design than they sound like they would.

What actually changes

• Orientation: portrait and landscape are different level layouts, not the same layout at a different size.
• Input density: how many distinct actions the player can perform without the controls becoming crowded.
• Precision: touch is a blunt pointer with your thumb covering part of the screen; a mouse is not.
• UI scale: readable text and hittable buttons have very different minimums on a phone.

Choose mobile when

• The core action is a tap, a swipe, a drag, or holding one finger down.
• The game reads well in portrait, or genuinely does not care about orientation.
• Sessions are short and restartable — the game survives being interrupted.
• Three or four distinct actions is enough for the whole design.

Choose PC & Console when

• The player needs simultaneous movement and aiming.
• The design assumes a landscape screen and a wide field of view.
• You want more than a handful of distinct inputs available at once.
• Precision matters — platforming timing, aiming, cursor-driven interaction.

Changing your mind later

You can ask for a different target after the fact, and the controls and layout will be reworked to match. It is a substantial change though, not a setting flip: a design built around twin-stick aiming does not become a good one-thumb game by resizing the viewport. Deciding before the first build is meaningfully cheaper than deciding after it.