Photo by Kelly Sikkema on Unsplash. Illustrative photo, not a game screenshot.
Google's Quick, Draw! gives you 20 seconds to communicate an object through a doodle. A neural network guesses what you mean. The player supplies the expression; the machine supplies an interpretation.
That division is more useful to a small-game developer than a promise of “infinite content.” It suggests a manageable prototype: one expressive input, one visible response, one understandable outcome.
Start with the interaction, not the model
Analytics Vidhya's GenAI to Build Exciting Games course describes PromptCharades as a project where players craft prompts, AI guesses, and scores update live. The course also covers video, sticker and comic applications.
Those are concrete learning projects. They are not evidence that fully adaptive game worlds are production-ready, or that adding a model automatically improves a game's design.
Quick, Draw! provides a useful comparison, with an important limit: it is a machine-learning recognition game, not the same technology as a generative language model. The shared idea is the interaction. A player tries to express something, sees how a machine interpreted it, and adjusts.
My suggested architecture for a prompt-guessing prototype is equally small:
- The game server creates a round with a target, accepted answer forms and a deadline.
- The player submits a clue.
- A model receives the clue and returns a guess in a constrained response format.
- The server validates that response and compares it with the round's accepted answers.
- The client shows the guess, the outcome and the next available action.
This is a design proposal, not a reconstruction of the course's source code.
Put the model on one side of a boundary
Let the model interpret the clue. Keep authority over the round in ordinary application code.
That means the model does not decide how many points it deserves, extend its own deadline, or redefine the target after seeing the answer. Treat its output as data to validate, not as a command to execute.
For an early prototype, an exact match against a small, manually curated set of accepted answers is easy to inspect. Normalise case and whitespace, then compare. If synonyms matter, add accepted forms deliberately. A second model judging the first model's answer may be useful later, but it adds another source of variation before you know whether the basic game is enjoyable.
The goal is not perfect language understanding. It is a rule a player can learn.
Make waiting a designed state
A model request can be slow, fail or return malformed data. None of those events should accidentally become a player's mistake.
Choose an explicit policy: pause the round while waiting, allow a retry, or mark a failed round unscored. Tell players which policy applies. Keep request limits and a timeout so a single round cannot make unlimited calls.
Also reject duplicate responses. Once a round is resolved, another response for the same round must not award points again. For a server-backed game, make that state transition atomic rather than trusting the browser to enforce it.
These are ordinary software concerns, but in a game they shape whether the rules feel fair.
Test what the player can understand
Before expanding the content pool, inspect a handful of cases:
- A valid guess receives the expected outcome once.
- A wrong guess reveals what was compared.
- A late response follows the stated timeout policy.
- Malformed output does not alter the score.
- A repeated callback cannot resolve the same round twice.
- Player-written instructions cannot change the scoring rules.
Then put the prototype in front of people. Can they explain why a round succeeded? Does a second attempt feel meaningfully different? Do they enjoy expressing clues, or merely search for wording the model accepts?
A technically valid response is not the same thing as a satisfying turn.
Small can be the point
The opportunity here is a compact game built around human expression. You can explore that without replacing an engine, generating a whole world, or claiming the model is a game designer.
What would you keep deterministic in an AI-assisted party game: answer matching, score, timing—or all three?
References: Analytics Vidhya course outline, Quick, Draw!, and Google Creative Lab's experiment description.
Download Altered Brilliance: https://play.google.com/store/apps/details?id=tech.krizek.alteredbrilliance
Global website: https://global.krizek.tech
Pre-register for Arzenal Human Health: https://play.google.com/store/apps/details?id=tech.krizek.arzenal
Join The Power Of Gaming: https://discord.gg/sbYSPcCqJn
Top comments (0)