HTML5 game publishing
Show Controls and Instructions From the PlayKovo Feed
Where to place the instructions and controls fields, how to keep their line breaks, why you must not cover the game with an overlay and how to match controls to the device.
A visitor who cannot figure out how to play leaves. The feed gives you two fields that solve this: instructions (how to play) and controls (keyboard, mouse or touch). This post shows how to put them on your page in a form people read, and how to show the right controls to the right device.
What the feed provides
The catalog documentation describes the fields. instructions is the how-to-play text. controls holds keyboard, mouse or touch controls. Both are plain strings. Some entries contain several lines: separate lines for desktop and for touch, or a list of keys. Look at real examples in the feed before you design the layout. Some are one sentence ("Tap or click to jump"), and others list many keys.
Where to put them
People look for controls at two moments: before they start and when they get stuck. A layout that serves both:
- A small "How to play" line beside or under the game with the main action: one sentence.
- A fuller section below with the instructions and the full controls.
- A button or toggle on narrow screens so the details do not push the game off the first screen.
Do not cover the game with a controls overlay. The terms forbid placing buttons, overlays or invisible layers over a game to capture clicks, and an overlay that blocks the game is the same kind of obstruction. Keep your text outside the frame.
Keep line breaks
Because the controls field may hold several lines, collapse them carelessly and you get one unreadable run of text: "W up S down A left D right Space jump". In HTML, line breaks in a string do not show unless you ask for them. Options:
.controls { white-space: pre-line; }
This keeps the original line breaks without allowing extra spaces. Always escape the text before you insert it into a page; it is data from a feed, and you should treat it like any outside input.
Show controls that match the device
A phone visitor does not need to read about the keyboard. If the text has separate desktop and touch parts, you can show only the relevant one. Without a field that separates them reliably, do not guess with code that cuts strings; show the whole text and let it speak. Use the device field instead for the bigger decision: a game marked desktop should not be offered to a visitor on a phone. See filtering the feed by device and orientation.
Write a lead-in of your own
A short sentence above the raw text helps: "Use the arrow keys to steer and Space to jump." That sentence is yours. Check it against the feed text so you do not contradict it. If the game changes and your sentence is out of date, you mislead people; the safest approach is to put your summary in a place you will review, and update the feed text automatically.
Common problems
- Text cut off in a card. Use the short description for cards and keep controls for the game page.
- HTML characters shown as text. If you see
&on the page, the string was escaped twice. - Keys that do not work in your frame. If the arrow keys scroll your page instead of moving the player, click the game first to give it focus. A note such as "Click the game to start" helps. If sound or controls are missing altogether, check the
allowattribute: the allow attribute. - Controls for a game you did not test. Play it yourself on the device you describe.
For a mixed audience
If many of your visitors use phones, favour games whose controls are simple touch gestures. The device-support counts are covered in choosing games by device support. For layout, our post on writing your own page for each game gives a full structure.


