Telegram Rich Messages: how a game fits inside a chat message

Rich text and Rich Messages solve different problems

Searching for “Telegram rich text” often leads to bold text, links and Markdown. Those features format spans of text. Rich Messages are a separate structured format with blocks such as headings, paragraphs, tables and buttons. Telegram documents this format separately from ordinary message formatting. ^{1, 2}

For a player, the distinction is practical. Bold text alone does not turn a Reversi position into a board. A playable position needs a readable grid, clear actions and an update after each move. In Rich Games, these elements stay in the message: the conversation becomes a place to return to a puzzle or a match.

Message, HTML5 game or Mini App?

Telegram also offers HTML5 Games and Mini Apps. An HTML5 game opens in the in-app browser from a game button. Mini Apps provide JavaScript web interfaces. Rich Messages are rendered by Telegram clients themselves. These are different product approaches, rather than interchangeable names. ^{1, 3, 4}

Start the choice with the action a player needs to perform. A chess move or a Sudoku entry can work as a short series of taps. A character moving in real time, drag-and-drop controls or elaborate animation will usually benefit from a custom web scene. We treat a message as a compact place to play: open it, make a move, and return to the conversation.

Anatomy of one playable message

Imagine a teaching Sudoku position. There is a title at the top, a board underneath, a short status line and a number selector. The abstract structure is “heading → puzzle paragraph → cell table → status → buttons”. This is an interface sketch, not a runnable API request: consult the current specification for actual fields and allowed values.

Suppose a row has one empty square and is missing a seven. The player selects 7 and taps that square. The application checks the move, stores the new position and produces the next board view. Rendering and rules have separate responsibilities. A nicely drawn board should not be responsible for deciding whether an answer is valid.

Reversi uses the same idea differently: choose a legal square and the discs change colour. Kakuro needs compact sum clues and clearly legible digits. The reusable part is the loop from action to validation to a new position. The arrangement of controls should still follow the particular game, rather than forcing every game into an identical panel.

Why this can suit a short game

In a turn-based game, attention belongs on the decision. Keeping a board beside the conversation lets someone start without switching to an unfamiliar context. That can suit a puzzle over coffee or a single move between other things. This is our design rationale, not a claim that every message interface is automatically faster than an app.

Updating the current board helps preserve its place in the conversation. Sending a new board after every action would otherwise produce dozens of almost identical messages. Feedback should be equally concise. A player needs to see the selected square and understand a rejected move; they do not need an explanation of how the server processed the tap.

The constraints that shape the board

The most important test is a real phone. Wide tables, long labels and symbols with different widths can make a board that looks elegant on a desktop awkward to use. In Rich Games we aim to fit a board across the screen and keep labels short. Kakuro makes the trade-off obvious: the answer grid and its sum clues must remain readable together.

Do not assume identical rendering in every client. Check the devices you intend to support, text size, and both light and dark appearances. Updating Telegram is a sensible first step when a message renders incorrectly, but compatibility should be verified for the specific client version. A documented format does not promise identical results on every installation.

Game state is another boundary. Repeated taps, an old board and simultaneous actions by two opponents should not corrupt a result. Those are server-side application concerns. Native rendering removes the need to draw a web page for the board; it does not remove the need to validate actions or preserve progress.

Three examples to try

Start with Sudoku and notice its two actions: choosing a digit and choosing a square. Next, open Reversi, where legal moves show which squares can be played. Finally, compare Kakuro, whose table carries both the answer cells and the puzzle conditions. The three games expose different demands on the same message-based setting.

If you are designing a bot, sketch one screen on paper first. What must someone understand in a second? Which action matters right now? Could a label be shorter? Then choose the technology. The most interesting result of Rich Messages is not a display of formatting tricks: it is the moment when the interface fades into the background and the player starts thinking about the next move.