I started with a broad ambition: build a solo Godot game for Steam in which village management and personal stories changed one another. A general production plan was easy to generate and too large to test. I narrowed the idea to a card-driven village whose next event could depend on resources, relationships, and what the player had already chosen.
The useful design step was making a tiny village possible. One location, three villagers, a handful of story cards, and one crisis or short end condition would expose whether a choice could matter at both the resource level and the character level. The assistant generated story templates and prototype structure, and one vignette showed what the cards were supposed to feel like. None of that establishes a playable build. This entry follows the reduction from a Steam-scale plan to the first complete draw–choice–consequence cycle I wanted to prove.
The small game inside the large plan
The suggested first location was a town square. Food and morale would supply immediate pressure; population would be visible in the interface. Villagers would have roles, needs, and relationships that could change through cards.
The initial code draft named three villagers: Anya, a farmer; Berto, a healer; and Ciro, a scout. Starting resources were Food 5, Morale 5, and Population 3. Two basic action cards made the tradeoff concrete:
| Card | Resource effect in the draft |
|---|---|
| Forage the Outskirts | Gain 2 Food, lose 1 Morale |
| Rest Hour | Spend 1 Food, gain 2 Morale |
That was the intended connection between management and story. A choice could change a number immediately while also changing who liked or resented whom.
How a story card was assembled
The assistant supplied GDScript and JSON rather than only a design description. A CardData resource held a title, description, costs, resource changes, relationship changes, tags, target villagers, and optional choices. VillagerData held a role, needs, and a relationship dictionary.
The proposed structure separated five jobs:
| Component | Responsibility |
|---|---|
GameState |
Resources, villagers, applying effects, and change signals |
DeckManager |
Drawing, discarding, and reshuffling cards |
StoryGenerator |
Loading JSON templates and filling in villagers |
CardData / VillagerData |
The data used by the other systems |
| HUD | Resource labels, a draw button, event log, and choice buttons |
Relationship changes were directional. A key shaped like A:B meant that A’s opinion of B changed; it did not automatically imply the reverse. Template rules such as A->B, B->A, and A->All were converted into those concrete pairs after the generator selected villagers.
An actual vignette
The example Firelight at Dusk began with one villager inviting another to share a meal after work. Its template described a small food cost, a morale benefit, and an improvement in both villagers’ opinions of each other. The choices then pushed the scene in different directions:
- Let them linger by the fire: another morale gain and a stronger bond from A toward B.
- Ask them back to work: more food, less morale, and a negative relationship change from A toward the others.
Another template, Draw from the Old Well, introduced rationing when the well ran low. It reduced food and morale and used a relationship change to connect the shortage with a villager’s response to the group.
These examples gave the procedural system something more specific than random flavor text: select participants, substitute their names into a scene, present a choice, and apply its consequences.
What the generated prototype did and did not establish
The supplied HUD randomly chose between drawing a normal card and generating a vignette. Choice buttons created temporary effect cards and passed them back to GameState. The planned UI was more elaborate, with a card hand, village board, and dialogue panel, but the code used a simpler collection of buttons and labels.
The response also proposed checks for unaffordable costs, template interpolation, relationship changes, reshuffling, and repeatable runs. Those were test instructions, not test results. In particular, the draft mixed a run seed with elapsed time in story generation, so its claim of deterministic stories needs more work than simply reusing a seed.
The broad Steam-game plan had narrowed to one village, three villagers, and a small draw–choice–consequence loop. The generated scenes and code structure gave that slice something to test. I had not yet reported playing a built version of it.