Architecture and Concurrency Model for Persistent Generative Entities in Real-Time Multiplayer State

Executive Recommendation

The integration of generative Large Language Models (LLMs) into live, server-authoritative multiplayer environments introduces profound synchronization challenges that threaten to shatter the illusion of a cohesive, shared digital reality. Traditional real-time game architectures rely on high-frequency, deterministic state updates—often processing at 60 to 128 ticks per second—to maintain strict synchronization across all connected clients1. Conversely, LLM inference is intrinsically non-deterministic and highly latent, frequently introducing multi-second delays that decouple the entity's cognitive process from the real-time physical simulation3. When multiple uncoordinated human participants interact concurrently with latency-bound generative entities, the system enters a regime prone to severe race conditions, stale state mutations, and split-brain phenomena5. This latency gap creates what is known as the "Uncanny Valley of Time," where the immersion provided by a highly intelligent entity is entirely destroyed by its failure to react to immediate physical changes in its environment3. To resolve this fundamental impedance mismatch without sacrificing environmental authority, it is recommended that the overarching architecture adopt an Asynchronous Bounded Actor (ABA) model, governed by Monotonic Fencing Tokens and Optimistic Concurrency Control (OCC)5. Under this paradigm, non-player characters (NPCs) are not integrated as privileged, synchronous components of the core game loop. Instead, they are orchestrated as isolated, asynchronous background-worker clients—often referred to as headless actors—that connect to the authoritative game server through the exact same networking ingress and event-validation pipelines as human participants9. This decoupling ensures that the primary game server retains absolute, pessimistic authority over all physical state, spatial routing, puzzle logic, and event serialization11. To satisfy the stringent requirement that controller type (human versus generative) must remain opaque to both the clients and the underlying model, all entities will be assigned Universally Unique Lexicographically Sortable Identifiers (ULIDs)14. The generative model will receive contextual game-state updates as a serialized append-only log10. Crucially, to prevent an NPC from acting on an outdated worldview—such as requesting to walk through a door that a human locked during the model's inference window—all generative requests must be paired with a monotonic fencing token representing the exact version of the room state the model observed8. If the room state mutates before the model's response is received, the authoritative server seamlessly rejects the invalid physical action, gracefully dropping the stale computation without leaking internal system errors to the public room text. This report exhaustively details the concurrency invariants, domain boundaries, conflict resolution strategies, and systemic failure mitigations required to deploy this architecture at scale.

Authoritative State and Event Model

The preservation of authoritative game state requires a strict, unyielding decoupling between the physical simulation, the storage of episodic memory, and the nomenclature of the participants. The system must navigate the complexities of concurrent access while ensuring that no single component oversteps its designated boundaries.

Domain Boundaries and System of Record

The architecture enforces a rigid separation of concerns across the three distinct domains provided in the system constraints. The following table delineates the responsibilities and concurrency roles of each subsystem.

Unification of Identifiers and Controller Obfuscation

A fundamental constraint of this architecture is that participant records must never disclose or confirm whether a controller is human or generated20. Systemic leaks often occur through structural discrepancies in primary keys, such as utilizing UUIDv4 for players while assigning sequential integers or distinct namespaces to NPCs. To ensure absolute cryptographic and structural parity, the system will utilize ULIDs for all entities, sessions, and events14. ULIDs consist of a 48-bit timestamp followed by 80 bits of cryptographic randomness. Because ULIDs contain no namespace or version bits that could map to a specific generation source, a human client and an AI worker generating an identity simultaneously will produce structurally indistinguishable strings15. Furthermore, ULIDs are inherently sortable by time, a property that allows the authoritative server to maintain a strictly ordered, linearizable event log without relying on secondary timestamp columns that are vulnerable to clock skew14. All downstream systems, including the LLM inference wrappers, the frontend UI, and the external memory endpoints, will reference entities exclusively by their ULID and the canonical string name provided by the external nomenclature service. When a human player approaches the "front desk" to visit an NPC by their exact full name, the system queries the active roster to map the canonical name to the current active ULID. The LLM itself is strictly denied access to the internal controller-type enumerator. When constructing prompts, the LLM is simply informed that it is observing actions from a participant identified by their canonical name and ULID, ensuring that the model cannot alter its behavior based on the biological status of its interlocutor.

The Headless Actor Model and the Silent Sleep

The working proposal dictates a maximum persistent roster of 10 NPC identities per active game, with social rooms accommodating around 7 to 8 combined participants, and a strict limit of no more than 6 active NPCs in any single room. To support the requirement that NPCs persist and maintain their internal state even when no human is present—while strictly preventing them from making costly AI-model calls—the system must implement an Actor Model utilizing suspendable workflows24. Each NPC is instantiated as a distinct, isolated Actor workflow. When one or more human participants are present in the room, the NPC Actor subscribes to the room's event bus, processing incoming spatial and dialogue events, maintaining an internal context window, and conditionally triggering inference calls. However, when the human count in a specific room reaches zero, the game server emits a room dormancy event. The NPC Actors within that room receive this signal, flush their short-term context to their designated memory endpoint, and suspend their event loops. Their persistent identities, relationship matrices, memories, and last authoritative physical coordinates remain locked in the authoritative server's memory store, surviving for the duration of the active game rather than being deleted and recreated24. This "silent sleep" mandate prevents runaway AI-to-AI conversational loops from burning compute resources and mutating persistent memory clusters in unobserved environments25.

Event Routing, Public Text Consistency, and Audio Isolation

All interactions, encompassing movement, physical puzzle manipulation, and typed dialogue, are routed through the authoritative server as discrete, immutable events27. The system constraints dictate that NPC interaction relies exclusively on typed in-game text. Optional human-to-human voice chat remains a separate, opt-in player feature, and the architecture strictly forbids routing player audio to any NPC transcription or speech service3. Consequently, the textual event bus is the sole medium of communication between generative entities and human players. The requirement dictates that public room text must remain visible and in the exact same order for everyone present, while direct addressees receive extra visual emphasis. This is achieved by separating the transport of the message from its local presentation rendering. When any participant emits text, they submit a command payload containing the source ULID, the text payload, and an array of target ULIDs. The authoritative server receives this payload, stamps it with an authoritative incrementing sequence number, and broadcasts it globally to all clients subscribed to that room29. This guarantees linearizability, ensuring that every client receives the dialogue in the exact same order10. Upon receiving the broadcast, the local UI client evaluates the target array. If the local player's session ULID exists in that array, the client's rendering engine flags the text for localized visual emphasis, such as bolding or color shifting. The backend server remains completely unaware of how this emphasis is drawn, treating it purely as local UI state6. The generative model cannot manipulate UI styling; it can only append a target ULID to its semantic intent, preserving the integrity of the public room text.

Sequence Diagram for a Contested NPC Turn

The following sequence illustrates a highly contested, multi-user scenario that tests the limits of the concurrency model. In this scenario, two players address an NPC simultaneously. Concurrently, one player locks the only exit door. The NPC attempts to reply to the players and move through the door simultaneously. The server's monotonic fencing token architecture resolves the conflict deterministically, dropping the stale physical movement while probabilistically preserving the conversational text.

Code snippet sequenceDiagram autonumber participant HA as Human A (Client) participant HB as Human B (Client) participant GS as Escape.GamesFor.Me (Auth Server) participant NPC as NPC Actor (Worker) participant LLM as Inference Pipeline

Note over GS: Room State is stable at Fencing Token 100

par Concurrent Player Actions HA-\>\>GS: Action: Lock Door (South) HB-\>\>GS: Speak: "Are you leaving us?" end

GS-\>\>GS: Validate Lock Door. Increment Token 100 \-\> 101 GS--\>\>NPC: Event Broadcast: Door Locked (Token 101\)

GS-\>\>GS: Validate Speech. Increment Token 101 \-\> 102 GS--\>\>NPC: Event Broadcast: HB Speak (Token 102\)

Note over NPC: NPC Actor debounces events and bundles context up to Token 102 NPC-\>\>LLM: Async Inference Request (Context Base: Token 102\)

HA-\>\>GS: Speak: "Don't go anywhere." GS-\>\>GS: Validate Speech. Increment Token 102 \-\> 103 GS--\>\>NPC: Event Broadcast: HA Speak (Token 103\)

Note over NPC: NPC receives Token 103, but LLM is already processing based on Token 102\.

LLM--\>\>NPC: Response Payload: \[Reply: "I must go"\] \+ \[Action: Move South\] NPC-\>\>GS: Submit Turn: Speak & Move South (Attached Fencing Token: 102\)

Note over GS: Auth Check: Provided Token 102 \< Current Token 103\. Stale token detected.

alt Action mutates physical state (Move South) GS-\>\>GS: Reject Move South. Door was locked at Token 101\. GS--\>\>NPC: Internal Error: Invalid Route / Stale Token (Hidden from players) else Action is communicative (Dialogue) GS-\>\>GS: Apply Probabilistic Decay. HA's speech at 103 does not physically invalidate the reply. GS--\>\>HA: Broadcast: NPC Speak: "I must go" GS--\>\>HB: Broadcast: NPC Speak: "I must go" end

The sequence above demonstrates the critical separation between physical state mutation and communicative soft state. The generative model's physical command is entirely neutralized by the authoritative server because it violates the monotonic sequence of events, ensuring that the NPC remains mechanically subservient to the authoritative location graph, doors, locks, and puzzle conditions6.

Exact Concurrency Invariants

To guarantee that the shared game state never corrupts and that NPC behaviors remain strictly constrained within the legal parameters of the authored environment, the architecture must enforce a rigid set of concurrency invariants. These invariants act as the foundational laws of the distributed system, defining the limits of autonomy for all active participants.

Monotonic Fencing Tokens per Room

Distributed locks alone are critically insufficient for managing long-running, asynchronous LLM operations. In a distributed environment, an NPC worker might acquire a lock, trigger a lengthy inference call, and then experience a garbage collection pause or network timeout, causing its lock lease to expire8. During this pause, another system or human player might advance the game state. If the stalled NPC worker eventually wakes up and applies its stale physical decision to the game world, it corrupts the shared reality, leading to phenomena where characters walk through walls or duplicate items17. To mitigate this, the first invariant mandates strictly monotonic gating. Every room instantiated by the authoritative server maintains a monotonically increasing integer known as a Fencing Token. Any state mutation occurring within that room—such as a player moving, a door locking, or a puzzle piece shifting—increments the room's token by exactly one7. When an NPC, acting as a headless client, requests an action, its payload must explicitly include the token representing the state of the room at the exact moment the model's prompt was constructed. If the provided token is mathematically lower than the server's current token, the server identifies the request as stale. Physical actions, such as movement or item manipulation, are strictly rejected under pessimistic locking rules8. Non-physical actions, such as dialogue, undergo evaluation for contextual relevance and may be accepted optimistically if they do not directly contradict the interleaved events5.

Idempotency Boundaries and Exactly-Once Execution

In a distributed multiplayer environment, packet loss, network jitter, and client retries are inescapable realities28. If an NPC issues a valid command to transfer an inventory item to a human player, a momentary network interruption could cause the NPC's transmission layer to retry the packet. Without idempotency controls, the server might process the command twice, duplicating the item and destroying the economic integrity of the game session32. The second invariant enforces exactly-once execution semantics through robust idempotency boundaries. Every state-mutating request originating from any participant must carry a unique idempotency key, generated as a distinct ULID specifically for that action intent24. The authoritative server maintains a bounded cache of recently processed keys, typically configured with a time-to-live matching the maximum expected retry window. When a request arrives, the server checks the cache; if the idempotency key already exists, the server bypasses the execution logic and immediately returns the cached success response from the original transaction32. This ensures that no matter how many times a disconnected client retries a transaction, the physical game state mutates only once.

Bounded Autonomy and Mechanical Subservience

Generative models are highly susceptible to hallucinating capabilities they do not actually possess. In an unconstrained environment, an LLM might generate a narrative intent declaring that it phases through a locked steel door to escape a room. If the system naively trusts the narrative output, the game logic is broken. The third invariant establishes the absolute supremacy of the authoritative server. The system must treat all NPC model outputs as untrusted client requests, identical in privilege and scrutiny to the packets received from human players13. The LLM does not execute movement; it submits a formatted movement request to the server6. The authoritative server validates this request against the exact same location graph, door statuses, lock states, and puzzle conditions applied to human avatars10. An NPC may not bypass a route simply because a model proposed it. If the generative intent violates a constraint, the server nullifies the movement and returns a localized, internal error to the NPC actor, prompting it to recalculate its approach without disrupting the public state.

Transaction Boundaries and Isolation

A single persistent NPC identity may be engaged concurrently by multiple different participants across completely isolated game sessions. If memory boundaries are porous, an NPC in one game might spontaneously reference a puzzle solution or a private conversation that occurred in an entirely different session, destroying the illusion of a contained narrative16. The fourth invariant mandates strict transaction boundaries and cross-game isolation. Because multiple participants may interact with the same NPC concurrently in different games and at different times, game-specific clues must never leak across boundaries. All requests routed to the external memory endpoints must be deeply namespaced utilizing a composite key consisting of the NPC's identity ULID and the active game's lifecycle ULID16. Episodic memories are structurally bound to the game instance and physically cannot be retrieved by an actor operating under a different game identifier. Approved social or general memories, such as broader personality traits, may be accessed across encounters, but specific situational data remains hermetically sealed within the transaction boundary of the active game.

Stable Conflict and Error Outcomes

When race conditions and state conflicts inevitably occur in the wild, the system must resolve them deterministically. More importantly, it must resolve them without exposing the underlying conflict mechanisms to the player layer, as visible system errors would instantly compromise the controller-type obfuscation6. The following stable outcomes govern conflict resolution.

Pessimistic Rejection of Stale Physical Actions

The handling of physical state is unforgiving. If an NPC proposes a movement, puzzle interaction, or door manipulation paired with a fencing token that is older than the current authoritative token, the action is dropped entirely8. The authoritative server does not attempt to merge, fix, or reconcile the movement, as doing so requires complex rollback logic that degrades server performance and introduces visual artifacting13. Instead, the server returns an internal HTTP 409 Conflict code to the NPC actor. The actor process absorbs this error, ingests the updated state log from the server, and initiates a fresh cognitive cycle based on the new, settled reality5. The human players in the room observe nothing but a slight delay in the NPC's physical reaction time.

Optimistic Application of Dialogue

Unlike physical movement, conversational text is considered soft state. If an NPC submits dialogue with a stale fencing token—for example, if a player shifted a non-critical object in the room during the model's inference time, thereby advancing the room token—dropping the NPC's dialogue creates an unnatural, jerky silence that degrades the user experience25. To handle this, the system applies an optimistic concurrency control mechanism modeled as Probabilistic Reply-Chain Decay6. When the server receives dialogue tagged with a stale token, it evaluates the nature of the state mutations that occurred in the intervening time. If the interleaved events do not directly involve the NPC's immediate physical target or its direct conversational addressee, the dialogue is accepted and broadcast to the room. The game server acts as the final arbiter, assessing whether the delayed events semantically invalidate the speech, allowing conversations to flow naturally even in highly active environments.

Asynchronous Cancellation of Stale Model Work

Given that LLM inference can easily consume thousands of milliseconds, the room state may fundamentally alter while token generation is mid-flight. If a critical, paradigm-shifting event occurs—such as a player completely leaving the room, or the room's lights being extinguished—the inference currently underway is instantly obsolete. To conserve compute resources and prevent the eventual submission of guaranteed-to-fail actions, the game server emits a targeted interrupt signal to the specific NPC actor. Upon receiving this signal, the actor immediately terminates the outbound HTTP or WebSocket connection to the LLM backend, effectively cancelling the generation pipeline24. The partial generation is discarded, and the actor realigns itself with the newly established game state.

Race and Replay Failure Cases with Mitigations

In a highly concurrent, multi-agent environment where human unpredictability meets asynchronous generative inference, edge cases proliferate. The following twelve failure modes represent severe systemic risks, categorized by their underlying mechanisms, alongside their engineered mitigations.

Topology and Lifecycle Failures

Case 1: Simultaneous Join and Leave (Phantom Room Loading) A human participant enters a social room, triggering the dormant NPCs to wake up. At the exact millisecond the inference call begins, the human participant leaves the room. The inference completes several seconds later, and the NPC speaks to an empty room, violating the strict policy that no AI-model calls are made when no human is present. Mitigation: The authoritative server evaluates the room occupancy dynamically at the exact moment the NPC attempts to commit the action, rather than relying solely on the occupancy state at the time of inference initiation. If the human occupancy registers as zero upon the return trip, the server intercepts the payload, silently discards it, and forces the NPC actor back into dormancy, ensuring no compute is wasted and no actions occur in isolation6. Case 2: Thundering Herd on Room Wake A single human participant enters a social room containing the maximum allowable six NPCs. The sudden entrance event wakes all six NPCs from dormancy simultaneously. All six actors trigger inference calls concurrently, slamming the external API rate limits and resulting in a cacophony of simultaneous, overlapping greetings that flood the public text log18. Mitigation: The system employs orchestrated jitter and spatial gating. When an actor wakes from dormancy, its inference trigger is delayed by a randomized backoff multiplier. Furthermore, an NPC will only initiate an unprompted greeting if its simulated line-of-sight cone or proximity radius intersects the human participant, naturally staggering the activation sequence and preserving API bandwidth34. Case 3: Split-Brain Worker Nodes A severe network partition causes the orchestration layer to lose track of an NPC actor, spinning up a replacement. The network heals, resulting in two separate worker nodes believing they are the authoritative host for a single NPC identity. Both submit LLM inferences, causing the NPC to rapidly output schizophrenic, interleaved dialogue31. Mitigation: The architecture implements a distributed lock via consensus protocols (such as Raft or Redis Redlock) for the instantiation of the actor process itself18. Only the worker node that actively holds the lease—refreshed via high-frequency heartbeats—can establish an event-bus connection to the authoritative game server. If a split-brain scenario materializes, the central game server drops all connections from any node presenting an expired or superseded lease7. Case 4: Zombie Inference and Orphaned Callbacks An NPC is mid-interaction, but its actor process suffers a critical memory fault and restarts on another node24. The original LLM API request completes externally and attempts to push data back via a webhook or callback to the dead or restarted actor, potentially executing a duplicate, out-of-context turn. Mitigation: All external LLM callbacks are cryptographically signed with the session ULID of the specific actor instance. When a new actor spins up following a crash, it generates a fresh session ULID. The zombie callback's session ULID fails to match the active session, and the incoming payload is safely routed to a dead-letter queue and discarded32.

Timing and Concurrency Conflicts

Case 5: Stale World State on Movement (The Ghost Walk) An NPC generates a request to walk through a doorway. During the three-second LLM inference delay, a human participant interacts with a puzzle that locks the door. The delayed model returns the decision to walk through. If the server is naive, the NPC phases through a locked physical barrier, destroying the game's mechanical integrity. Mitigation: Fencing token validation serves as the ultimate backstop8. The door lock event incremented the room token. The NPC's subsequent movement request carries the old, stale token. The authoritative game server strictly rejects the physical movement, preserving geometric authority and forcing the NPC to re-evaluate the locked door7. Case 6: Locking Timeout and Slow Inference Desynchronization The game server issues a lease for the NPC's communicative "turn." The LLM takes an abnormally long 4.5 seconds to respond, but the game server's hard turn-timeout is configured to 3.0 seconds8. The server passes the conversational turn to a human player, but the NPC suddenly acts asynchronously 1.5 seconds later, breaking the dialogue flow. Mitigation: Event cancellation via fencing tokens seamlessly resolves this. Because the server advanced the conversational turn, it incremented the global event token for the room. The delayed 4.5-second response is inherently stamped with an obsolete token and is instantly dropped at the server edge, preventing conversational collisions18. Case 7: Dual Addressing and Cross-Talk Contention Human A types "Hello" to an NPC. Merely 100 milliseconds later, Human B types a highly aggressive command to the exact same NPC. The NPC's context window ingests Human A's text and immediately begins processing. It completely misses Human B's text, resulting in a polite, immersion-breaking greeting delivered in the middle of a hostile encounter. Mitigation: The NPC actor implements a strict debounce and coalesce buffer10. Upon receiving a direct address, the actor does not fire immediately; it waits for a tunable threshold to batch concurrent inputs. This ensures both Human A and Human B's inputs are coalesced into a single semantic context block before shipping the prompt to the model3. Case 8: Duplicate Request Replay (The Echo Chamber) A momentary packet drop on the edge network causes the NPC actor's transport layer to retry transmitting a successfully generated line of dialogue. The authoritative server receives both packets due to the retry logic, causing the NPC to stutter the exact same sentence twice in the public chat log32. Mitigation: Enforced idempotency boundaries neutralize this threat. Every outgoing command from the NPC is wrapped with an Idempotency-Key. The game server's ingress layer deduplicates requests matching a recently seen key, ensuring the dialogue is committed to the public room text exactly once24.

State Isolation and Data Integrity

Case 9: Cross-Game Memory Leak (Identity Contamination) The NPC identity is present concurrently in Active Game 1 and Active Game 2\. Human A in Game 1 tells the NPC a critical secret password. Simultaneously, Human B in Game 2 asks the NPC for a password. Because both instances query the memory endpoints for the same character name, the password leaks across game boundaries, ruining the puzzle for Human B19. Mitigation: Absolute namespace isolation is enforced at the database layer. The memory endpoints require all queries to be parameterized with the active game's lifecycle ULID. Episodic memories are structurally bound to the specific game instance and physically cannot be retrieved by an actor operating under a different game identifier16. Case 10: Stale Memory Read versus Write (Memory Collision) An NPC in a room is actively writing a new episodic memory to the external memory endpoints regarding a newly met player. Concurrently, another player asks the NPC a question, triggering an inference. The actor reads its memory store before the asynchronous write concludes, acting as if it hasn't met the first player yet5. Mitigation: The architecture enforces read-after-write consistency mapping. The NPC actor maintains a local, ephemeral cache of its pending memory writes. During inference preparation, this local cache is aggressively merged into the prompt context, bypassing the slower network trip to the external endpoints to ensure immediate short-term events are accurately reflected in the LLM's context16. Case 11: Controller Identity Leak via Error Propagation An NPC attempts to execute an invalid move due to an LLM hallucination. The authoritative game server returns an error. If this error is inadvertently logged to the public room text—for example, rendering "Error: LLM Model Timeout" in the chat—the human players instantly know the entity is a generated AI, violating the core obfuscation constraint6. Mitigation: Strict error containment protocols are enacted. The system standardizes all validation errors. If a human client requests an invalid move, the server silently corrects their position via rubber-banding1. If an NPC does it, the server silently returns an internal failure to the actor. The room's public event log must never receive debug, routing, or controller-origin metadata under any circumstances20. Case 12: Idempotency Key Exhaustion or Collision Under extreme server load, or due to a poorly seeded random number generator in a specific worker node, idempotency keys collide. An NPC's perfectly valid action is rejected because the server incorrectly assumes it is a replay of an older, unrelated action, halting the NPC's ability to participate32. Mitigation: The system strictly utilizes ULIDs for idempotency keys rather than standard random UUIDv4s14. A ULID encodes the timestamp to millisecond precision in its primary bits, ensuring that even if the random entropy pool degrades, keys generated at different times will never collide, mathematically guaranteeing the integrity of the deduplication layer.

Minimal Implementation Order and Stress-Test Matrix

To deploy this complex, multi-layered architecture without introducing cascading regressions into the existing live environment, the engineering organization must adopt a strict, phased integration sequence.

Implementation Phases

Phase I: Foundation and Fencing The initial phase requires zero AI integration. The engineering team must implement ULID generation across all existing microservices. The core game server ingress must be deeply refactored to require, track, and validate Monotonic Fencing Tokens and Idempotency Keys on all state-mutating requests, including those from existing human clients. This establishes the bedrock of concurrency control. Phase II: The Headless Actor Lifecycle The asynchronous NPC actor framework is developed and deployed as an isolated service. It connects to the game server using standard client WebSockets, masquerading exactly as a human client. The dormancy and wake lifecycles are implemented and tested against dynamic room occupancy sets to ensure compute resources scale precisely with human presence. Phase III: Domain Integration and Nomenclature The external dependencies are integrated. The external nomenclature service is queried upon game initialization to seed the actor roster with canonical names. The actor's internal state management is wired to the external memory endpoints, with rigorous testing of the composite key isolation to prevent cross-game data contamination. Phase IV: Concurrency Hardening and Optimistic UX The final phase involves tuning the user experience in highly concurrent scenarios. The probabilistic reply-chain decay logic is implemented for dialogue handling to prevent unnatural silences. The debounce and coalesce buffers are fine-tuned to ensure inference triggers gather maximum context before dispatching to the LLM.

Stress-Test Matrix

Before authorization for a production release, the architecture must be validated against a rigorous matrix of extreme network and concurrency conditions to guarantee absolute stability. The following matrix details the critical test vectors.

By adhering strictly to monotonic fencing, idempotent transactions, and a rigidly decoupled headless actor model, the system architecture successfully bridges the gap between deterministic game state and non-deterministic generative AI. This ensures a resilient, scalable environment where generative characters operate seamlessly alongside humans, completely preserving the integrity, stability, and mystery of the shared digital reality.

Works cited

1. What are Server-Authoritative Realtime Games? \[Updated for 2026\] | Metaplay Blog, https://www.metaplay.io/blog/server-authoritative-games
2. How to Build and Design a Multiplayer Game | Unity, https://unity.com/how-to/how-build-design-your-multiplayer-game
3. Beyond the Script: 5 Surprising Breakthroughs Bringing Local AI NPCs to Life, https://blog.devwithawais.com/beyond-the-script-5-surprising-breakthroughs-bringing-local-ai-npcs-to-life-7081e15cf0ff
4. Echoes of Others: Real-Time LLM Dialogue Generation for Immersive NPC Interaction \- ACL Anthology, https://aclanthology.org/2025.inlg-demos.1.pdf
5. \[2606.15376\] CoAgent: Concurrency Control for Multi-Agent Systems \- arXiv, https://arxiv.org/abs/2606.15376
6. Bounded Autonomy: Controlling LLM Characters in Live Multiplayer Games \- arXiv, https://arxiv.org/html/2604.04703v2
7. FencedLock (Hazelcast Root 5.5.0 API), https://docs.hazelcast.org/docs/5.5.0/javadoc/com/hazelcast/cp/lock/FencedLock.html
8. Beyond the Lock: Why Fencing Tokens Are Essential | by Konstantin Tarkus, https://levelup.gitconnected.com/beyond-the-lock-why-fencing-tokens-are-essential-5be0857d5a6a
9. Experiences from my multiplayer game designing with concurrency in mind \- Swift Forums, https://forums.swift.org/t/experiences-from-my-multiplayer-game-designing-with-concurrency-in-mind/74148
10. How do multiplayer games sync their state? Part 1 | by Qing Wei Lim \- Medium, https://medium.com/@qingweilim/how-do-multiplayer-games-sync-their-state-part-1-ab72d6a54043
11. Authoritative Servers, Relays & Peer-To-Peer \- Understanding Networking Types and their Benefits for each Game Types \- Edgegap, https://edgegap.com/blog/explainer-series-authoritative-servers-relays-peer-to-peer-understanding-networking-types-and-their-benefits-for-each-game-types
12. Sever authoritative multiplayer \- how does it work? : r/gamedev \- Reddit, https://www.reddit.com/r/gamedev/comments/1oo7zfy/sever\authoritative\multiplayer\how\does\it\_work/
13. Server-Authoritative Game Logic to Prevent Cheating in Multiplayer Games \- AccelByte, https://accelbyte.io/blog/server-authoritative-logic-to-prevent-cheating
14. UUID vs ULID vs UUID7: Why, Where, and When? | by Ramachandran Krish \- Medium, https://medium.com/@ramachandrankrish/uuid-vs-ulid-vs-uuid7-why-where-and-when-647414482bec
15. Welcome\! :: Mark Hamstra | MODX Development & Services, https://www.markhamstra.com/
16. When running multiple agents in parallel… how do you stop them from stepping on each other? \- Reddit, https://www.reddit.com/r/AI\Agents/comments/1ry7qmc/when\running\multiple\agents\in\parallel\how\_do/
17. How to do distributed locking \- Martin Kleppmann, https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
18. Distributed Locking: Redis, ZooKeeper & Redlock | Layrs, https://layrs.me/course/hld/12-reliability-patterns/distributed-locking/
19. Understanding State and State Management in LLM-Based AI Agents \- GitHub, https://github.com/mind-network/Awesome-LLM-based-AI-Agents-Knowledge/blob/main/8-7-state.md
20. Tag \#game studies \- Bibliography of Software Language Engineering in Generated Hypertext (BibSLEIGH), https://bibtex.github.io/tag/game%20studies.html
21. Emerging Trends in Electrical, Communications and Information Technologies \- National Academic Digital Library of Ethiopia, http://ndl.ethernet.edu.et/bitstream/123456789/35480/1/Emerging%20Trends%20in%20Electrical%2C%20Communications%20and%20Information%20Technologies.pdf
22. Why Choose ULIDs Over Traditional UUIDs or IDs for Database Identification? \- Reddit, https://www.reddit.com/r/programming/comments/1ckklm9/why\choose\ulids\over\traditional\uuids\or\_ids/
23. Distributed Locks \- Redict, https://redict.io/docs/usage/distributed-locks/
24. Durable Player Sessions with Temporal Actor Workflows, https://temporal.io/blog/actor-workflow-player-sessions
25. Tiny AI Models for Game NPCs \- What Works Under 1B Parameters \- Fazm Blog, https://fazm.ai/blog/tiny-models-game-npcs-survival
26. Leveraging LLM Agents for Automated Video Game Testing \- arXiv, https://arxiv.org/html/2509.22170v1
27. Authoritative Multiplayer \- Heroic Labs Documentation, https://heroiclabs.com/docs/nakama/concepts/multiplayer/authoritative/
28. Real-Time Gaming Analytics with Streaming | Conduktor, https://www.conduktor.io/glossary/real-time-gaming-analytics-with-streaming
29. Best Practices for Designing Real-Time APIs for Multiplayer Matchmaking and Seamless Data Synchronization Across Client Platforms \- Zigpoll, https://www.zigpoll.com/content/what-are-the-best-practices-for-designing-a-realtime-api-that-supports-multiplayer-matchmaking-and-seamless-data-synchronization-across-different-client-platforms
30. \[2604.04703\] Bounded Autonomy: Controlling LLM Characters in Live Multiplayer Games, https://arxiv.org/abs/2604.04703
31. Engineering Multicloud Consensus: Implementing Distributed Locking with Fencing Tokens, https://dev.to/sertaoseracloud/engineering-multicloud-consensus-implementing-distributed-locking-with-fencing-tokens-31c
32. Idempotent transactions and retry patterns in Economy v2 \- PlayFab \- Microsoft Learn, https://learn.microsoft.com/en-us/xbox/playfab/economy-monetization/economy-v2/tutorials/idempotent-transactions-and-retries
33. Design a Matchmaking Service for Multiplayer Games \- Hello Interview, https://www.hellointerview.com/community/questions/roblox-matchmaking-queue/cmbne3hns00s008ad9y959f3j
34. The Redlock Algorithm \- Redis Patterns \- antirez, https://redis.antirez.com/fundamental/redlock.html
35. Changelog \- LettuceAI, https://lettuceai.app/changelog
36. Distributed Locks are Dead; Long Live Distributed Locks\! \- Hazelcast, https://hazelcast.com/blog/long-live-distributed-locks/