UI cards

All your 2D interface is a card — HUDs, menus, buttons, labels, dialogue. Not 3D text on a plane, not a texture with words on it.

Cards are laid out like a normal interface, in front of the 3D view, so they stay crisp at any distance and on any screen size. Text in a card is readable; text on a plane in the world is at the mercy of the camera.

A card is a resource, and you attach it to an object.

Two ways to place one

Overlay fills the screen. This is your HUD, your menu, your dialogue box.

Anchored pins the card to an object's position on screen — a name over a character, a price over a product.

An anchored card does not shrink with distance

It stays the size you designed and hides when its object goes behind the camera. It is a label attached to something, not an object in the world. If you want something that gets smaller as you walk away, use 3D text instead.

What you can build

The usual building blocks are all there:

container · text · image · gif · video · separator · grid · gallery
pager · tabs · state · indicator · slider · input · select · switch

There is no button component — and that is fine

A button is a text or a container with a background, some padding, a border and an action. It sounds like extra work and it is actually the opposite: you get exactly the button your design asks for, instead of fighting a default one.

For anything repeated (a row in a list, a chip, a card in a gallery) build a template once and reuse it.

A card can hold several screens of its own and switch between them without involving the scene at all. That is the right way to build a tabbed panel or a multi-step dialogue: the scene never needs to know.

Custom components and third-party extensions such as Lottie will not render.

Making a card do something

A card has its own variables and can change itself with them — show and hide, swap text, switch screens, run timers. Anything purely about the interface should stay inside the card.

When it needs to reach the scene, there are three ways, in increasing order of power:

Way	Use it for
A built-in card action	interface state only — a tab, a toggle, a timer
A scene step on the action	running a scene step with no code: switch scene, play an animation
A named action plus a script	game logic

An action on a card also raises an ordinary event that travels up the hierarchy, so an event on the scene can catch a press from any card inside it — by name, or any press at all.

Talking to a script

A script can read a card's variables, write them, and listen for presses:

const ui = ctx.getDivKit(entity);

ui.set('score', (v) => v + 1);
ui.subscribe('lives', (v) => {
  /* the display changed */
});
ui.onAction('restart', () => {
  /* the restart button was pressed */
});

This is the pattern worth internalising: the game state lives in the script, and the card displays it. Not the other way round.

Pointing at images and video

Inside a card, point at a project resource rather than a URL. References work inside expressions too, so picking an image based on a condition behaves the way you would expect.

Before you start designing

• A card only shows while its scene is active, so interface never leaks between scenes.
• A screenshot of the 3D view will not include your cards. Check interface in preview.
• Card variables are not shared between participants and reset on reload. Anything that must be shared or survive belongs in a script.
• The visual editor shows a curated set of properties but keeps hand-written layouts intact — they survive editing, they just have no properties panel.

---

Next: Material graphs — when the standard materials are not enough.