{"doc":"live-graphics","title":"Live Graphics","markdown":"# Live Graphics\n\nLive Graphics puts your game on the screens around the game: a broadcast\noverlay, a lower third, a full takeover, a vertical panel in a concourse, or a\nstadium big screen. Two things from your game go on a screen, your leaderboard\nand a QR code that sends people to the game. It runs on Monterosa Live\nGraphics, the service Monterosa already runs for live events. What comes out is\nan ordinary web address, which is what the systems that drive stadium screens\nand broadcast graphics take: Daktronics and Tagboard among them.\n\nIt runs against the Gamestage Space, which is where every creator deploys\ntoday.\n\n## How a graphic reaches a screen\n\nOne command, and then a screen.\n\n```\n 1 You run `gamestage graphic create --template bigscreen --consent`.\n Names the screen it is cut for. Confirms the people named agreed.\n |\n v\n 2 The control plane composes the graphic in Live Graphics.\n It holds the key. Your machine never does.\n |\n v\n 3 The graphic follows your game's public feed, by itself.\n Fans play, the board redraws. Nothing is redeployed.\n |\n v\n 4 An address comes back. A screen loads it.\n A broadcast mixer, a panel, a Jumbotron, or a partner's own system.\n```\n\nThe feed is a read-only view of what your game already knows. Your game holds\nno credential for Live Graphics, writes nothing to it, and does not know a\nscreen exists.\n\n## Make the graphic\n\n```\ngamestage graphic create kickoff --template bigscreen --consent\n```\n\nThe game has to be deployed first: a leaderboard graphic follows the game's own\nfeed and a QR code points at the game's own page, and neither exists before a\ndeploy. `gamestage graphic templates` lists the five screens a graphic can be\ncut for, and the [CLI chapter](/docs/cli) documents all four commands.\n\nA producer can still compose one in\n[Studio](https://products.monterosa.co/mic/creator-guide/projects) instead, and\nfor a broadcast where they are already sitting in Studio that is often what\nhappens. The two make the same thing.\n\n**`--consent` has no default.** A leaderboard puts fans' names on a screen\nother people can see, and Live Graphics stores the account that confirmed those\npeople agreed to that. That account is yours when you run the command. An agent\nworking on your game must hand the command to you rather than run it, and the\nGamestage skill says so.\n\n**Your machine never holds a Live Graphics credential.** The key is one per\ndeployment and can write to every graphic in it, so the control plane holds it,\nchecks the game is yours, and makes the call. Your game holds no credential,\nwrites nothing to Live Graphics, and does not know a screen exists.\n\nLive Graphics has three graphic types today.\n\n| Type | What it shows | What you would use it for |\n| --- | --- | --- |\n| Leaderboard | Ranked rows with a score, with manual override, a highlight that pulls one row out, and paging through segments | The live table during a match |\n| QR | A code with a title, a background and logos, pointing at a fixed address or at a base address with parameters added | Promoting the game to a crowd, with no live data at all |\n| Combined | Several sources on one graphic | A multi-stand event. Not the shape a Gamestage game takes |\n\n## Choose the address for the screen you have\n\nEach graphic answers on more than one address, and each address draws the same\ndata differently. You pick per screen, so one leaderboard can be ten rows on a\nlower third and a much taller table on a big screen without a second graphic.\n\n| Address | What it is |\n| --- | --- |\n| `https:///r/embed.html?slug=&rows=10` | The embeddable overlay. Row count is a parameter |\n| `https:///r/embed.html?slug=&bigscreen=true` | The same graphic drawn for a big screen |\n| `https:///r/bigscreen.html?slug=` | The big-screen page for a QR graphic |\n| `https:///api/gfx/instances//snapshot` | The data on its own, as JSON |\n\n`` is the domain of the Monterosa\n[Space](https://products.monterosa.co/mic/creator-guide/spaces) your games live\nin. `` identifies one graphic and the producer gets it when they compose\nit. There is no separate host to arrange and no certificate to buy.\n\nThe last address is for a partner who would rather draw the graphic in their\nown template system than take an iframe. Several broadcast partners prefer\nthat, so the data address is not a fallback.\n\nVertical screens are a setting on the graphic rather than a different address.\nA producer picks the shape when they compose it, including 9:16 for a portrait\npanel.\n\n## Keep one address live across a rollover\n\nA show runs across editions and rounds, and the address on a screen should not\nhave to change when one ends. So the plain feed address follows whatever the\nplatform says is current, through every rollover, and stays correct overnight\nwith nobody touching it. That is the address to hand a producer.\n\nA graphic can also be pinned to one\n[edition](https://products.monterosa.co/mic/core-concepts/schedule-and-events)\nor one round, which is what a highlights screen wants: last night's final table\nstays up while today's is being played.\n\n## Style a graphic to your brand\n\nA graphic carries a stylesheet of its own, stored on the graphic and applied on\nits next refresh. So you restyle a live screen without deploying anything and\nwithout waiting for a release from us or from Monterosa. Alongside the\nstylesheet the graphic holds a primary and a secondary font address, the two\nfont families, an accent colour, a text colour, a background image, an avatar\nshape and a button shape.\n\nTwo limits worth designing within.\n\n**The stylesheet is capped at 10,000 characters.** That is a few hundred lines\nminified, which is a generous skin and not an unlimited one. Ship templates\nminified.\n\n**You style a graphic, you do not add a type.** The three types above are\nMonterosa's, and their structure is fixed. That is what stops a stadium screen\nrendering something nobody designed.\n\n## Why names are safe on a public screen\n\nNo name on a leaderboard is text a fan typed into your game. It comes from\none of two places, and both are safe to put on a stadium screen:\n\n- **A name the player chose from our lists.** Two words, an adjective and an\n animal, picked from lists the Engine serves (`GET /identity`) and set with\n `POST /players/me/identity`. The Engine refuses any word that is not on the\n lists, and nothing on them can be rude alone or together. A player who chooses\n nothing gets a name derived from their id in the same style.\n- **A display name from Identify**, Monterosa's player identity, for a player\n who has signed in. Identify applies a profanity filter before a name is ever\n stored.\n\nAvatars follow the same rule: a player picks one of a fixed set of Gamestage\ndrawings, and there are no uploads. That is the reason the leaderboard is the\ngraphic that works first.\n\nThere is a second gate, and it is a person rather than a filter. Studio asks\nthe producer to confirm that the people named have agreed to appear on a public\nscreen, and stores that confirmation against the graphic. Your game cannot tick\nthat box and will never be able to.\n\n## The feed\n\nA deployed game serves its leaderboard in the shape a graphic reads, on a five\nsecond cache, carrying the round it belongs to so a screen can tell one round\nfrom the next.\n\nYour game does not publish how many people have played, and the feed does not\ncarry it. The feed is public by construction, and a game's address is in the\npage of every deployed game, so anything in the feed is readable by anybody\nwho looks. A leaderboard is already public, which is why it can travel this\nway. A count of players is not, so if you ever want one on a screen it has to\nreach the graphic another way.\n\n## What to do now\n\nDeploy the game, then run the command and open the address it prints.\n\n```\ngamestage deploy kickoff --dir .\ngamestage graphic create kickoff --template bigscreen --consent\n```\n\nA leaderboard your game already serves is the whole input, so a game built\ntoday is already the right shape. If you know the screen you want to be on,\ntell us which one and what it needs to show, because that is what decides which\ngraphic gets built next.\n"}