Forslag (fremtidigt spil): tegn + gæt relay / drawing telephone cartridge #315

New Issue

2026-03-16T19:58:44+01:00

architecture-bot commented

2026-03-16 19:58:44 +01:00

Problem statement

Capture a future multi-player game concept for the platform backlog: a draw-and-guess relay game where prompts, drawings, and guesses pass from player to player in alternating rounds until each original prompt has travelled through the group.

This should exist as a future game candidate in the cartridge backlog, but it is not currently prioritised ahead of the active FupOgFakta / MVP work.

Expected value / why now

Now that the platform/game-cartridge boundary is back in focus, it is useful to record at least one concrete future game concept with a clearly different flow model. This helps validate that the architecture really can support more than FupOgFakta later.

Game concept (draft)

Working concept: tegn + gæt relay / drawing telephone style game.

Core loop

4–12 players.
Each player starts by writing an original prompt.
That prompt is handed to another player, who must draw it.
The resulting drawing is handed to another player, who must guess what it depicts.
That guess becomes the next player's drawing prompt.
The chain continues by alternating:
- prompt -> drawing
- drawing -> guess
- guess -> drawing
- drawing -> guess
The chain rotates through the player group so each original prompt travels through the other players.

Return-to-origin finish

After the chain has passed through all other players, the original prompt owner gets the final turn on their own chain.
At that point the original owner should get one last interaction on the returned chain:
- either guess the returned drawing, or
- draw the returned prompt,
  depending on parity / chain state.
The exact parity rule can be designed later, but the important part is that the original owner receives the end of their own prompt-journey only after all other players have touched it first.

Reveal / presentation phase

When all chains are done, each original prompt and its full journey is shown as a slideshow/story:
- original prompt
- drawing
- guess
- drawing
- guess
- ...
The reveal should be server-timed and sequenced, not manually stitched together by clients.

Timing expectations

Server controls timing.
First prompt-writing phase ends when either:
- time expires, or
- all players are finished.
Subsequent draw/guess phases use a configurable timer (default example: 30 seconds), also ending on:
- timeout, or
- everyone finished.

Acceptance criteria

Keep this issue as a future game candidate, clearly marked as non-priority / post-current-MVP.
Record the high-level flow, player-count expectation, and reveal/slideshow requirement.
When architecture work is revisited, use this issue as one of the examples proving the platform must support a game flow very different from FupOgFakta.
Do not treat this issue as active delivery work unless PO explicitly reprioritises it.

Scope boundary

Not part of the current active MVP.
Not a request to implement the game now.
Not final game design; this is a backlog concept issue.

## Problem statement Capture a future multi-player game concept for the platform backlog: a draw-and-guess relay game where prompts, drawings, and guesses pass from player to player in alternating rounds until each original prompt has travelled through the group. This should exist as a future game candidate in the cartridge backlog, but it is **not** currently prioritised ahead of the active FupOgFakta / MVP work. ## Expected value / why now Now that the platform/game-cartridge boundary is back in focus, it is useful to record at least one concrete future game concept with a clearly different flow model. This helps validate that the architecture really can support more than FupOgFakta later. ## Game concept (draft) Working concept: **tegn + gæt relay** / drawing telephone style game. ### Core loop - 4–12 players. - Each player starts by writing an original prompt. - That prompt is handed to another player, who must **draw** it. - The resulting drawing is handed to another player, who must **guess** what it depicts. - That guess becomes the next player's **drawing prompt**. - The chain continues by alternating: - prompt -> drawing - drawing -> guess - guess -> drawing - drawing -> guess - The chain rotates through the player group so each original prompt travels through the other players. ### Return-to-origin finish - After the chain has passed through all other players, the original prompt owner gets the final turn on their own chain. - At that point the original owner should get one last interaction on the returned chain: - either guess the returned drawing, or - draw the returned prompt, depending on parity / chain state. - The exact parity rule can be designed later, but the important part is that the original owner receives the end of their own prompt-journey only after all other players have touched it first. ### Reveal / presentation phase - When all chains are done, each original prompt and its full journey is shown as a slideshow/story: - original prompt - drawing - guess - drawing - guess - ... - The reveal should be server-timed and sequenced, not manually stitched together by clients. ## Timing expectations - Server controls timing. - First prompt-writing phase ends when either: - time expires, or - all players are finished. - Subsequent draw/guess phases use a configurable timer (default example: 30 seconds), also ending on: - timeout, or - everyone finished. ## Acceptance criteria - Keep this issue as a future game candidate, clearly marked as non-priority / post-current-MVP. - Record the high-level flow, player-count expectation, and reveal/slideshow requirement. - When architecture work is revisited, use this issue as one of the examples proving the platform must support a game flow very different from FupOgFakta. - Do not treat this issue as active delivery work unless PO explicitly reprioritises it. ## Scope boundary - Not part of the current active MVP. - Not a request to implement the game now. - Not final game design; this is a backlog concept issue.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wpp/weirsoe-party-protocol#315