Actions, State, and Lifecycles

Pressing a button does not always mean the game has accepted the result. A local puzzle may check and apply a move immediately. An online item trade may need to confirm the player, price, available funds, inventory space, current versions, and responses from more than one service.

AGC uses one plain journey to make those differences visible: offer a choice, capture the intention, check whether it is allowed, reserve anything scarce, prepare the effects, ask the responsible parts to apply them, record the outcome, show feedback, and clean up temporary work.

Simple games can combine several steps. They do not need a bureaucracy for moving one tile. The distinctions become useful when the same idea grows into crafting, dialogue, building placement, card resolution, combat, or a networked exchange.

Check before changing

The game checks the actor, target, timing, prerequisites, conflicts, capacity, and the exact situation that was observed. A useful answer says why an action was accepted or refused. “Available a moment ago” is not a guarantee if the world has changed since then.

Ask the responsible part

The part allowed to make the final change is the owner of that state. Inventory owns item containment, the wallet owns money, character state owns health, and objectives own progress. An action asks those owners to make bounded changes and collects their results; it does not seize all their data.

If a sword purchase removes money but the inventory rejects the item, the trade must undo the debit or clearly enter recovery. Showing a cheerful “Purchase complete” animation would not make the missing sword less missing.

Record and explain the outcome

The result should distinguish success, refusal, a repeated request, old information, cancellation, interruption, recovery, or failure. Fast local feedback may be shown before confirmation, but it must be clear when it is only a prediction.

Cleanup is part of correctness

Reservations, asynchronous tasks, temporary effects, subscriptions, animation locks, and predicted presentation all need terminal cleanup. A module that works once but leaves later actions blocked has not completed its lifecycle.

Where it stands today

AGC has an advisory model and made-up test examples for a simple local puzzle move and a trade involving several system owners. They test the shape of the reasoning; they are not playable features, production transaction systems, or proof that the model fits every game.