velven

Ask AI for one game system you can actually inspect

Make me a game leaves almost every design decision open. I'd rather ask for a collection system with a precise boundary, then connect it to one object. A smaller request gives me a much better chance of understanding both the result and the next bug.

By VelvenIntermediate2 min readPublished
A tiny modular game island split into three clearly connected mechanical subsystems on a workshop bench, cream robot, bridge and exit gate.

Define what the system owns

A collection system receives a contact event, checks whether an item is still available and updates progress. It might emit a reward event for the interface and audio to handle. It doesn't need to redesign either of those systems.

Write down the state it owns: collected item identifiers and the current count, for example. Decide what resets with the round and what persists. Those lifetime decisions belong in the request before implementation starts.

I would also name what the assistant must leave alone. A good boundary protects working movement, camera and menu behavior from unrelated edits.

Connect one object before making twenty

Add one collectible and one visible counter. Touch the object and check that progress changes once. Stay in contact, leave and return, then restart and collect it again.

Use those cases to inspect the implementation. Which condition prevents double collection? Which operation resets the state? Where does the visual disappearance happen?

If you can't answer those questions, pause expansion and ask for an explanation tied to the actual code. Generating more instances won't make the underlying system easier to understand.

Let integration reveal the next boundary

Once the simple case works, connect the reward sound or completion condition through a clear event or function call. Check that the connection doesn't create a second owner for the same count.

Try restarting during the reward effect. Delayed callbacks should not update a new round with work from the old one. Keep cleanup responsibilities with the system that created the work.

I wouldn't split every small function into a separate architecture exercise. The useful boundary is the one that makes changes easier to reason about. Keep a working build after each connection, and expand only when you can explain how information crosses from one system to the next.

Sources & further reading

Made something playable?

Share your game, world or experiment with people exploring what AI can help create.

Add your space to Velven

Keep making