# HudLayout > An editor-authored HUD screen and its animation, sent as the JSON the Lectern HUD editor exports. `gg.lode.lecternapi.api.ui.HudLayout` --- ## Signature ```java public class HudLayout ``` --- ## Notes The layout travels as its own document rather than as a series of element calls, which is what lets a UI be retimed or restyled without either side being rebuilt: the editor exports the file, the server ships it, the client plays it. Layouts are cached on the client by id, so a repeat showing costs only the id. Text in a layout may carry `%tokens%`. Values the client knows (position, health, FPS) it fills in itself; anything else comes from `String)`. That is also how **PlaceholderAPI** reaches a layout: PAPI runs on the server against a real player, so the server expands the placeholder and pushes the result under the same name, and a layout written against PAPI tokens works unchanged. ```java api.getHUDManager().playLayout(player, new HudLayout("objective_intro", json) .variable("objective", "Capture the relay") .variable("score", "3 / 5")); ``` --- ## Methods ### variable ```java public HudLayout variable(String name, String value) ``` Sets a value for `%name%` in the layout's text. Variables are global to the client rather than scoped to one layout, so a value pushed once shows in every layout using that token, which is what makes a scoreboard-style screen a set of variables rather than a re-send. | Parameter | Type | |---|---| | `name` | `String` | | `value` | `String` | --- ### variables ```java public HudLayout variables(Map<String, String> values) ``` | Parameter | Type | |---|---| | `Map<String` | `` | | `values` | `String>` | --- ### getId ```java public String getId() ``` --- ### getJson ```java public String getJson() ``` --- ### getVariables ```java public Map<String, String> getVariables() ``` --- ### hasDefinition ```java public boolean hasDefinition() ``` Whether the layout carries a definition, as opposed to replaying a cached one. ---