# Host screens in Common UI or your own layers

> Use the Rolly screens in a Common UI game, put each player's screens into a layer of your own interface, and hand the game's input to your own input policy.

Product: Rolly Save 1.0.0 | Sheet: guide | Updated: 2026-10-31 | HTML: https://rolly-docs.pages.dev/save/guides/hosting-screens/

## In a Common UI game

Nothing to set up. When the game viewport client is Common UI's (Project Settings > Engine > General Settings > **Game Viewport Client Class** is Common Game Viewport Client or a subclass), each player's Rolly screens open inside an activatable widget of their own on the viewport, so Common UI's router keeps focus on them, and:

- Accept on a row acts on the row (a slider steps once, a choice moves one option), never a click at its centre;
- Rolly's prompts stay on the player's device: the analog cursor's moves never switch them to the mouse;
- Back goes up Rolly's levels, then closes the screens;
- when the last Rolly screen closes, the activatable widget goes and focus returns to the game's widget that had it.

Rolly's prompt bar shows the prompts of every Rolly screen. Common UI's action bar lists nothing while a Rolly screen is on top: hide it while it is empty.

Project Settings > Plugins > **Rolly Save Core UI** > Common UI:

| Setting | What it does |
|---|---|
| **Common UI** | Auto (the default) adapts when the game uses Common UI's viewport client; Off leaves the screens as they are. |
| **Common UI Host Class** | The activatable widget the screens open in: a Widget Blueprint subclass of Common Activatable Widget, to set its input config or desired focus target. Empty: Common Activatable Widget. |
| **Common UI Host Panel** | The panel of that class (an Overlay, by name) the screens go into. Empty: they fill it. |

### Into your layer stack

To put the screens into one of your own activatable widget stacks (a Menu layer of your root layout), call **Push Rolly Screens Into Common UI Stack** with the player controller and the stack before you open a Rolly screen: it pushes the host class into the stack and shows the player's screens in its panel. The stack takes the widget off again when the last Rolly screen closes.

## Show the screens in a panel of your HUD

For a panel you own (an Overlay of your HUD), **Set Host Panel** on the player's stack is enough; see [Open screens on the screen stack](https://rolly-docs.pages.dev/save/guides/screen-stack/#choose-where-screens-show).

## Show the screens in a layer system

A game with its own layer system puts each player's host (the widget that holds the player's screens) into one of its layers with a presenter: a small C++ class implementing `IRollySaveCoreUIPresenter` (`Present`, `Dismiss`, `IsPresented`, and optionally `GetAreaSize` for the compact layouts), handed to each player's stack with `URollySaveCoreUIStackSubsystem::SetPresenter`. While Rolly screens are open the host keeps the player's input from the game.

## Replace the input handling

A game with an input policy of its own can replace how screens take and give back the game's input: implement `IRollySaveCoreUIInputHandler` and hand it to `URollySaveCoreUISharedSubsystem::SetInputHandler`. The built-in handler records the viewport's input flags and the cursor when the first screen opens and restores them after the last one closes (see [Open screens on the screen stack](https://rolly-docs.pages.dev/save/guides/screen-stack/#what-the-stack-does)).

## Limits

- The screens do not use Common UI's bound actions: their keys come from the engine's navigation config and the screens' own key lists.
- Common UI's names are read by name: a later engine version that renames one turns the adaptation off with a setup message, and the screens work as without Common UI.