The problem

In most word games a word is worth its letters. We wanted a word to be worth its meaning: SNAKE should poison, GHOST should go invisible, DRAGON should fly, a CASTLE should never move. Hand-designing that for a whole dictionary, in six languages, is not something a solo developer can do. So every word goes through a pipeline that produces a "game sheet" once, offline. The game itself never calls an AI at runtime.

What a game sheet contains

For each playable word:

• an archetype: melee, ranged, tank, swarm, flying, building or generator
• seven axes scored 1 to 5: speed, weight, size, alive, range, toxicity, healing
• an optional element: water, earth, fire, wind, ice, lightning
• at most two abilities from a closed list: poison, stealth, slow, shield, heal, area damage, knockback, burn, pierce, freeze, chain lightning, life steal, summon, flight...
• a short definition and a one-line explanation of why it got those stats

Power and cost are not decided by the pipeline. The game computes them from the axes, so balance stays in code we can tune.

Verbs and adjectives don't become units: they become spells, and for them the axes describe the effect (size = area, speed = how fast it lands).

The pipeline

1. Dictionary sources. Lemmas and frequencies come from Lexique (French) and wordfreq; definitions come from Wiktionary dumps.
2. Embeddings as a first guess. Each word is embedded with several models. Distance to hand-written anchor concepts ("fast", "heavy", "alive"...) gives a rough tier for each axis. A lexical network (JeuxDeMots for French) adds relations like is-a, located-in and opposite.
3. An automatic sheet. Votes from the three embedding spaces plus a few rules produce a v1 sheet.
4. One LLM pass. A small model reads the definition, the v1 proposal and the embedding hints, and writes the final sheet on an absolute scale with explicit anchors per axis. Rules are stated literally ("a building or an immobile object always has speed 1"). The output is constrained to the closed list of abilities.
5. Targeted passes. One pass gives abilities to playable nouns that came out bland. Another picks a visual "plan" (object, weapon, vehicle, building) so the sprite drawn in code matches the word.
6. Export + review panel. A fixed panel of reference words is checked after every run.

What went wrong, and what fixed it

• Relative scales lie. In v1 the axes were quintiles from embeddings: in a list of animals, something has to be the slowest, so CAT came out slow and SNAKE heavy and huge. On a reference grid written in advance, 36% of the panel's axis values were out of range. Switching to an absolute 1-5 scale with anchors chosen by the LLM brought that to 5%. (The grid was written by the same person who wrote the prompt anchors, so it's a consistency check, not ground truth.)
• LLMs are stingy with abilities. The first pass gave abilities to too few nouns, which made most words feel identical. A cheap second pass with a reduced schema ("ability + why") fixed it, at the cost of a few stretches (INSTANT → fast, STREET → fast).
• Homographs are the hardest part. French PÊCHE (peach / fishing) vs PÉCHÉ (sin) or FORT as an adverb: errors there come from the lexicon, not the model.
• A small blocklist is still needed for words that are valid but shouldn't be units.

Why do it offline

• The game stays fast and free to run: sheets are static files loaded after the menu.
• Every result can be reviewed, diffed between versions, and fixed by hand.

Try it

Free, no signup, no ads, in English, French, Spanish, German, Portuguese and Italian: https://wordlegion.bonnaf.com/en/?src=hashnode