Turn Word-Building Rules into a Game with AI

When a word puzzle changes its rule from round to round, an AI prompt needs to define more than a theme. Give it the physical letter rack, the exact condition for a valid guess, the accepted words, what an error costs, and what advances the player. Then add one rule at a time and compare the resulting state with a small, explicit check.

This guide uses Mosslight Letter Trial, an original fictional design exercise. Its prompt templates were not submitted to a game generator, and no build or playtest exists. The word lists and outcomes below are a hand-authored contract for readers to adapt and verify in their own prototype.

Turn the rule change into a test case

Start with a rule sheet that a person could follow without guessing what “make a word” means. Each round has one rack, one constraint, a fixed accepted-word list, and one transition. The lists are intentionally small: they make this exercise deterministic without claiming to represent a complete dictionary.

Read the rows as a contract, not as three dictionary puzzles. A guess must use physical tiles from the current rack, and a tile instance cannot be selected twice. After that, check length, then the round’s include-or-exclude rule, and only then the round-specific allowlist. Stop at the first failure so the player sees one actionable reason rather than several competing messages.

For example, TONE uses four available tiles and appears in the Round 1 list, so the proposed rules accept it. STENO uses five rack tiles and meets the length condition, but it is not in the listed set; it therefore reaches the allowlist check and fails there. These are expected outcomes from the written contract, not observations from a running game.

Prompt the first rack and input loop

Ask for one round before asking for progression. That isolates the basic interaction: choose a tile once, remove it by selecting it again, clear the row without cost, submit, and either keep editing after an error or advance on a valid word. The first prompt can be copied as a starting brief:

Create a small fictional word-building game prototype called Mosslight Letter Trial. Show one rack with the physical tiles S, T, O, N, E; an active rule that a submitted word must use at least four rack tiles; an ordered guess row; Submit; Clear; two attempt markers; and an always-visible Restart. A player can select each physical tile once, unselect it by clicking again, and clear the whole guess without spending an attempt. Accept only STONE, TONE, NOTE, ONES, or SENT for this one-round prototype. A valid guess shows a temporary “Round complete” checkpoint, not the final game victory. Keep the rack after an invalid submit, spend one attempt, and allow a corrected guess. Do not add a dictionary, score, timer, random letters, or more rounds yet.

Now inspect the input contract on paper. Selecting T, O, N, and E in that order forms TONE; the unused S stays in the rack. Selecting those same physical tiles in a different order would form another guess, so the final word must be checked against the allowlist rather than accepted merely because its letters came from the rack. Two copies of one tile are never created by clicking the same tile twice.

Write down the expected states before implementation: a valid listed word advances; an invalid submission spends one of two attempts but leaves its guess editable; Clear empties the guess while leaving both markers unchanged; and the second invalid submission ends the run. Restart is available in every state and returns to Round 1 with an empty guess and two attempts. This turns a visual input request into a testable sequence of state changes.

Add constraints without changing the core input

Once the first rack contract is stable, request the later rounds while explicitly preserving its controls and accepted words. Round 2 changes both the minimum length and an include-letter condition. Round 3 instead forbids a letter. The change is easier to inspect when the prompt states the precedence of those checks and gives a case that would fail at each boundary.

Keep the first-round rack, controls, and accepted words exactly unchanged. Extend the game to three rounds. Round 2 uses rack A C E R T, requires all five tiles and the letter R, and accepts only CARET, CATER, CRATE, REACT, TRACE. Round 3 uses rack P L A N E T, requires at least four tiles and forbids E, and accepts only PLAN, PANT, PLANT. One valid word immediately advances and replaces the rack/rule; one valid word in each round completes the run. The win state shows exactly the three accepted words from that run and no fourth rack. Do not add a dictionary API, extra rounds, scoring, or random tiles.

Use the examples to see why order matters. In Round 2, CATE is shorter than the five required tiles, so its first message should be “Use all five tiles”; it should not jump ahead to the missing-R condition or the word list. CARET meets the length and include-R checks and appears in the allowlist. In Round 3, PLAN meets the minimum length, omits E, and is listed. PLANET has six rack tiles but includes the forbidden E, so that rule should be reported before allowlist membership.

The fixed word sets are design constraints, not a claim about an English dictionary. If a creator later wants open-ended vocabulary, they must choose and test a dictionary source, casing behavior, inflections, and duplicate-letter rules separately. Keeping that decision out of this first exercise prevents a hidden service or unbounded vocabulary from changing what “valid” means.

Check failed input and round state

Use a third prompt to make failure and restart behavior explicit. A player should be able to repair a guess after the first miss, while the second miss ends the run. A valid word moves immediately to the next round and resets that round’s two attempt markers. The victory state contains the words accepted in that run, in order, and no next rack.

Keep the game contract unchanged. Each round allows two submissions. Validate in this exact order: tile membership/no reuse, length, the include/exclude-letter rule, then the fixed accepted-word list. Show only the first failed reason. An invalid guess consumes one attempt and keeps the selected tiles in the guess row so the player can edit them; Clear empties the guess but does not consume an attempt. The second failed submit ends the run with defeat. Restart stays visible in every state and resets to round 1, rack S T O N E, empty guess, two attempts, and no result. Confirm STENO reaches the allowlist error, CATE reaches the five-tile length error before its missing-R condition, and PLANET reaches the forbidden-E error before the allowlist; do not claim these checks passed until run.

This prompt asks for expected feedback, not just a win screen. In a fresh Round 1 run, STENO should fail the allowlist twice; the first miss leaves the guess editable, while the second shows defeat. A new run can then submit STONE to reach Round 2, where CATE should show the length message. Clear should remove CATE without spending another try; CARET should advance. In Round 3, PLANET should show the forbidden-E message, and PLAN should complete the run. The table records the first failure for three representative inputs, so a reader can tell which validation branch needs correction without treating the paper trace as a test result.

The success trace is deliberately short: Round 1 accepts STONE, Round 2 accepts CARET, and Round 3 accepts PANT. Each word satisfies that round’s written constraints and allowlist. The result image is an original concept illustration of that defined state, not a screenshot or evidence that a game was built.

Repair one validation rule at a time

If a future prototype accepts PLANET in Round 3, start by recording what the prototype actually displayed and which rules version it used. Then ask for one narrow correction: validate the forbidden-E condition before checking the allowlist, keep the same rack and word set, and repeat PLANET followed by PLAN. Compare the new messages with the contract. Do not infer that a fix worked until the same sequence has been run and observed.

The same discipline applies to unclear behavior. If clicking a tile twice duplicates it instead of toggling it off, describe the physical-tile identity, the current guess, the action, and the expected row. If Restart leaves an old result visible, specify the state it must clear. Changing one rule at a time keeps a later comparison interpretable; changing the lexicon, controls, and progression together would make the cause of a mismatch hard to locate.

Take the brief to a game workspace

SEELE’s Free AI Game Maker page describes a general workflow for expressing a game idea in plain English, reviewing a playable 2D or 3D result, and iterating in Workspace. That product information supports a place to try a future brief; it does not verify Mosslight, the word lists, or any of the prompts above. Before you begin, review the current Workspace options and displayed account or generation terms, then compare any result against the explicit checks rather than assuming the prompt produced them.

When you are ready to turn your own bounded rules into a starting point, open the Free AI game maker. Its published workflow describes plain-English prompts, a playable 2D or 3D first result you can test in the browser, and follow-up prompts for refinement. Before submitting a generation, review the selected model, available Koin balance, and displayed cost. Bring the rack, rule, accepted words, error order, and restart behavior as part of the brief; then inspect your actual result. This article makes no promise about a particular game result.

Frequently asked questions

What should an AI prompt include for a changing word rule?

Name the rack, the exact length and letter conditions, the accepted-word set, the error order, and the transition after a valid or invalid guess. Add one changing rule per stage and include an example that should pass and one that should fail. This gives a future result specific behavior to inspect without assuming a broad dictionary.

Should I connect a dictionary API right away?

Not for this bounded exercise. A tiny allowlist makes each expected result explicit and avoids an unchosen dependency. If you later use an open dictionary, decide which source and language it covers, how it treats plurals or inflections, and how it handles duplicate letters; then test those rules separately. Mosslight’s lists are fictional and intentionally incomplete.

What happens after an invalid guess?

Under this proposed contract, the first invalid submission consumes one of two attempts but leaves the selected tiles in the guess row so the player can edit them. Clear empties the row without spending an attempt. A second invalid submission ends the run. These are intended rules for a future prototype, not behavior observed in a working game.

How can I check that the same tile is not used twice?

Track the physical tile instance when it is selected, not only the letter shown on it. The same tile should toggle off when selected again, and the guess row should contain no duplicate reference to that instance. A useful future check is to select a tile, click it again, and verify that it disappears without changing the rack or attempt count.

Is Mosslight Letter Trial a generated or tested game?

No. Mosslight is an original fictional design exercise, and its prompt templates were not submitted to a game maker. The tables and success trace were resolved from the written rules by hand. There is no playable build, prompt execution, software test, playtest, measured result, customer story, or online case to report.