Live Graphics

Live Graphics puts your game on the screens around the game: a broadcast overlay, a lower third, a full takeover, a vertical panel in a concourse, or a stadium big screen. Two things from your game go on a screen, your leaderboard and a QR code that sends people to the game. It runs on Monterosa Live Graphics, the service Monterosa already runs for live events. What comes out is an ordinary web address, which is what the systems that drive stadium screens and broadcast graphics take: Daktronics and Tagboard among them.

It runs against the Gamestage Space, which is where every creator deploys today.

How a graphic reaches a screen

One command, and then a screen.

  1  You run `gamestage graphic create <game> --template bigscreen --consent`.
        Names the screen it is cut for. Confirms the people named agreed.
              |
              v
  2  The control plane composes the graphic in Live Graphics.
        It holds the key. Your machine never does.
              |
              v
  3  The graphic follows your game's public feed, by itself.
        Fans play, the board redraws. Nothing is redeployed.
              |
              v
  4  An address comes back. A screen loads it.
        A broadcast mixer, a panel, a Jumbotron, or a partner's own system.

The feed is a read-only view of what your game already knows. Your game holds no credential for Live Graphics, writes nothing to it, and does not know a screen exists.

Make the graphic

gamestage graphic create kickoff --template bigscreen --consent

The game has to be deployed first: a leaderboard graphic follows the game's own feed and a QR code points at the game's own page, and neither exists before a deploy. gamestage graphic templates lists the five screens a graphic can be cut for, and the CLI chapter documents all four commands.

A producer can still compose one in Studio instead, and for a broadcast where they are already sitting in Studio that is often what happens. The two make the same thing.

--consent has no default. A leaderboard puts fans' names on a screen other people can see, and Live Graphics stores the account that confirmed those people agreed to that. That account is yours when you run the command. An agent working on your game must hand the command to you rather than run it, and the Gamestage skill says so.

Your machine never holds a Live Graphics credential. The key is one per deployment and can write to every graphic in it, so the control plane holds it, checks the game is yours, and makes the call. Your game holds no credential, writes nothing to Live Graphics, and does not know a screen exists.

Live Graphics has three graphic types today.

Choose the address for the screen you have

Each graphic answers on more than one address, and each address draws the same data differently. You pick per screen, so one leaderboard can be ten rows on a lower third and a much taller table on a big screen without a second graphic.

<space-domain> is the domain of the Monterosa Space your games live in. <slug> identifies one graphic and the producer gets it when they compose it. There is no separate host to arrange and no certificate to buy.

The last address is for a partner who would rather draw the graphic in their own template system than take an iframe. Several broadcast partners prefer that, so the data address is not a fallback.

Vertical screens are a setting on the graphic rather than a different address. A producer picks the shape when they compose it, including 9:16 for a portrait panel.

Keep one address live across a rollover

A show runs across editions and rounds, and the address on a screen should not have to change when one ends. So the plain feed address follows whatever the platform says is current, through every rollover, and stays correct overnight with nobody touching it. That is the address to hand a producer.

A graphic can also be pinned to one edition or one round, which is what a highlights screen wants: last night's final table stays up while today's is being played.

Style a graphic to your brand

A graphic carries a stylesheet of its own, stored on the graphic and applied on its next refresh. So you restyle a live screen without deploying anything and without waiting for a release from us or from Monterosa. Alongside the stylesheet the graphic holds a primary and a secondary font address, the two font families, an accent colour, a text colour, a background image, an avatar shape and a button shape.

Two limits worth designing within.

The stylesheet is capped at 10,000 characters. That is a few hundred lines minified, which is a generous skin and not an unlimited one. Ship templates minified.

You style a graphic, you do not add a type. The three types above are Monterosa's, and their structure is fixed. That is what stops a stadium screen rendering something nobody designed.

Why names are safe on a public screen

No name on a leaderboard is text a fan typed into your game. It comes from one of two places, and both are safe to put on a stadium screen:

• A name the player chose from our lists. Two words, an adjective and an animal, picked from lists the Engine serves (GET /identity) and set with POST /players/me/identity. The Engine refuses any word that is not on the lists, and nothing on them can be rude alone or together. A player who chooses nothing gets a name derived from their id in the same style.
• A display name from Identify, Monterosa's player identity, for a player who has signed in. Identify applies a profanity filter before a name is ever stored.

Avatars follow the same rule: a player picks one of a fixed set of Gamestage drawings, and there are no uploads. That is the reason the leaderboard is the graphic that works first.

There is a second gate, and it is a person rather than a filter. Studio asks the producer to confirm that the people named have agreed to appear on a public screen, and stores that confirmation against the graphic. Your game cannot tick that box and will never be able to.

The feed

A deployed game serves its leaderboard in the shape a graphic reads, on a five second cache, carrying the round it belongs to so a screen can tell one round from the next.

Your game does not publish how many people have played, and the feed does not carry it. The feed is public by construction, and a game's address is in the page of every deployed game, so anything in the feed is readable by anybody who looks. A leaderboard is already public, which is why it can travel this way. A count of players is not, so if you ever want one on a screen it has to reach the graphic another way.

What to do now

Deploy the game, then run the command and open the address it prints.

gamestage deploy kickoff --dir .
gamestage graphic create kickoff --template bigscreen --consent

A leaderboard your game already serves is the whole input, so a game built today is already the right shape. If you know the screen you want to be on, tell us which one and what it needs to show, because that is what decides which graphic gets built next.