From game systems to runtime owners

963. Lesson identity

Module

3.1 — Runtime architecture

Academic type

Systems

Order

1

Estimated content time

20 minutes

Estimated practice time

15 minutes

Total estimated time

30–40 minutes

964. Learning objective

After this lesson, you can assign an owner, lifecycle responsibility, and execution boundary to each part of a small game architecture.

965. Why this matters

A design document can describe inventory, encounters, progression, and interface as separate systems. A running game needs concrete objects or services that create, coordinate, update, and release those responsibilities. When ownership remains implicit, initialization order becomes fragile and multiple components may make contradictory decisions.

Clear runtime ownership gives a developer or AI coding assistant an explicit architectural target: who has authority, when that authority is active, and which mutations must not cross a boundary directly.

966. Prior knowledge

You should be able to describe a small game system by its player-facing responsibility: what the player can do, what the game decides, and what result the player observes. You do not need a completed project or knowledge of a particular engine.

967. Core concept

A design-level system describes a responsibility in the game. A runtime owner is the concrete object, service, or coordinator with authority over the relevant decisions, data, or lifecycle work.

One design-level system may involve several runtime owners, but each important decision or mutation should have one clear authority. For example, combat may involve an input adapter, a combat resolver, player state, and a health presenter. The combat resolver has authority over the rule decision; the interface does not.

An execution boundary states what an owner may decide or mutate directly and what must cross to another owner as a request, command, or observation. A boundary prevents a UI component from changing domain state directly or a scene controller from silently acquiring every system responsibility.

Authoritative state and presentation appear here only as boundary examples. The complete state-ownership model belongs to module 3.2.

968. Owner–Lifecycle–Boundary model

Use four questions for every proposed runtime component:

Use these artifacts while practicing:

1. Ownership map: Responsibility | Owner | Authority | Cross-owner request or observation | Evidence.
2. Lifecycle strip: Create → Initialize → Active → Reset/Deactivate → Release if applicable.
3. Boundary check: one permitted direct action and one prohibited direct mutation for each owner.

A composition or session owner may connect systems and coordinate their lifecycles without owning every domain rule. Domain owners make their assigned runtime decisions. Presentation owners observe or display results without acquiring authority over the underlying state.

969. Concrete example

Consider a small infiltration encounter:

These assignments illustrate boundaries rather than prescribe a complete state architecture. The resolver has authority over encounter-rule decisions. State and presentation remain separate responsibilities. A direct call that lets HudPresenter award a resource would violate the boundary.

970. AI-native workflow

Use AI as a drafting and criticism aid, not as the final architectural authority or as a project editor.

Example prompt:

Draft a runtime ownership map for this architecture: the player issues Search; the current location determines whether a search may reveal an item; successful reveals update inventory; the interface displays the result and inventory count; a new session clears temporary state. Use no more than five owners. For each owner, state its authority, lifecycle responsibility, one permitted direct action, one prohibited direct mutation, and concise evidence. Identify a cross-owner request or observation when applicable; otherwise mark it not applicable and explain why the owner does not initiate cross-boundary work. Mark every assumption not stated in the brief. Do not provide a complete action trace or detailed message ordering.

Review the draft row by row. Keep a proposal only when the brief supports its authority and lifecycle. Reject unsupported assumptions about engine classes, persistence, event buses, networking, or scene structure. Revise the map until each important decision and mutation has one authoritative owner.

The learner makes the final architecture decision. Do not ask AI to edit files or generate implementation code for this exercise.

971. Common mistake

A common mistake is assigning ownership according to visibility rather than authority. A screen may display a timer, but that does not make the screen the owner of time. A scene controller may know when a scene loads, but it should not automatically own combat rules, inventory mutation, and progression thresholds.

Ask which component is allowed to make the decision, not which component happens to be active when the result becomes visible. Also avoid inventing interactions merely to make every owner send a request. Some owners only receive commands, expose observations, or manage their own authoritative state.

972. Guided practice

Create a runtime ownership map for this small architecture:

• The player can issue a Search command.
• A search may reveal an item only if the location permits it.
• The inventory records the item after a successful reveal.
• The interface shows the result and current inventory count.
• Starting a new session clears the previous session's temporary state.

Use no more than five owners. For each selected owner, record:

1. The responsibility it owns.
2. When it is created or activated and when it resets or deactivates.
3. One action it may perform directly.
4. One direct mutation that is prohibited.
5. One cross-owner request or observation when applicable. Otherwise, mark it not applicable and justify why the owner does not initiate cross-boundary work.
6. Concise evidence that its responsibility was performed.
7. The release, unsubscription, or detachment boundary when relevant; otherwise mark it not applicable.

Do not produce a complete Search action trace, detailed message ordering, or a teardown procedure. Those topics belong to the next lesson.

If you use an AI draft, annotate each row as supported, rejected, or revised. Then decide whether the location-permission check belongs to the search command handler, the inventory owner, or a separate rules owner. Defend your choice in two or three sentences using authority and lifecycle rather than convenience.

Suggested timebox:

• 8 minutes: draft and refine the ownership map.
• 4 minutes: complete lifecycle and boundary entries.
• 3 minutes: review authority conflicts and submit the practical evidence.

973. Validation and evidence

Your work is sufficient when it includes:

• A completed ownership-map row for every selected owner.
• One authoritative owner for the location-permission decision.
• One authoritative owner for inventory mutation.
• A lifecycle statement covering the new-session reset.
• One permitted direct action and one prohibited direct mutation per owner.
• A cross-owner request or observation where applicable, or a justified not-applicable entry.
• Release, detachment, or unsubscription handling only where the stated architecture makes it relevant.
• A boundary preventing the interface from awarding or removing items directly.
• If AI was used, at least one reviewed assumption marked supported, rejected, or revised.

Reject the map if two owners can independently authorize the same inventory mutation, no owner clears temporary session state, a relevant lifecycle responsibility is unowned, or the interface can directly change inventory.

Complete the linked practical assessment to demonstrate the capability.

974. Key takeaways

• Design systems describe responsibilities; runtime owners make those responsibilities executable.
• Authority, lifecycle, and visibility are distinct architectural concerns.
• Every significant decision or mutation needs one clear authority.
• Execution boundaries identify permitted actions and prohibited direct mutations.
• Cross-owner work should be recorded only when it actually applies.
• AI may draft an ownership map, but the learner must verify assumptions and assign final authority.

975. Next lesson

Continue to 3.1 L2 — Trace one action through the architecture.

976. Knowledge check