The topic pages below collect short public explanations from the ADK project notes.
Each section explains one part of the design. The sections may read like separate introductions instead of one long article, because each comes from the note that owns that subject.
The pages update automatically when approved public text changes. Private plans, file paths, dependencies, and implementation details are not included.
Architecture topic
These notes describe unusual manifestations, the evidence they leave behind, and controlled travel through portal connections. An anomaly may change local conditions or produce spectral residue without rewriting the w...
Architecture topic
These notes describe how Pinky applies operations that Brain has already admitted and approved. The adapter revalidates the relevant local game state, performs only the delegated change, and returns a typed receipt de...
Architecture topic
These notes describe how plugin source becomes a runtime package and how that package is checked before it can affect a live server. Compilation, security checks, shadow testing, external-access review, and final acti...
Architecture topic
These notes define the final safety boundary beside the host. Pinky classifies observation sources, limits passive ingestion, isolates client-specific illusions, and may reject or debounce an approved operation when c...
Architecture topic
These notes explore optional services shared across participating servers. They focus on local authority, portable companions, and custody rules that prevent one identity from being active in several places at once.
Architecture topic
These notes explain how live game information travels between Pinky, which works close to the game engine, and Brain, which performs the heavier reasoning and coordination. They cover the compact frames and entity ref...
Architecture topic
These notes cover how ADK identities are bound to temporary game-engine objects and reconciled as players, NPCs, structures, and other entities appear, disappear, reconnect, become wounded, or respawn. The game remain...
Architecture topic
These notes describe the shared machinery used to build, validate, and run gameplay events and minigames. Server administrators can combine reusable triggers, objectives, enemies, rewards, and ending conditions throug...
Architecture topic
These notes explain how Brain schedules work, runs isolated plugins, resolves competing intents, commits accepted changes, and observes performance. Plugins can request outcomes, but the kernel keeps final mutation or...
Architecture topic
These notes describe how factions obtain resources, move supplies, support production, and experience shortages or recovery. Economy and logistics are connected but remain understandable as separate responsibilities....
Architecture topic
These notes explain how factions track allegiance, reputation, and the information their members collectively believe. Faction knowledge can be incomplete or biased. Individual observations become shared intelligence...
Architecture topic
These notes describe the fast data plane and authoritative memory structures beneath ADK. They cover how Brain and Pinky exchange bounded runtime facts, how logical identities remain stable, and how frequently used st...
Architecture topic
These notes describe world events that change what players encounter without replacing the normal game rules. Cargo drops, raids, moving convoys, blackouts, contested sites, courier visits, and environmental hazards a...
Architecture topic
These notes describe services that outlive one gameplay tick or one local server. They cover durable persistence, identity and access, privacy and compliance, cross-server coordination through ADC, and global economic...
Architecture topic
These notes describe how ADK discovers what a game and exact server build can actually observe or do. Game-specific adapters translate pathing, physics, settings, social structures, landmarks, world conditions, and ot...
Architecture topic
These notes describe how ADK qualifies an exact game build, starts and supervises its integration modules, detects changed host interfaces, and keeps development mitigations separate from trusted production compatibil...
Architecture topic
This part of ADK explains how a request becomes a safe change in the game. Plugins and framework services describe what they want to happen. ADK checks the request, resolves any conflicts, decides whether the change i...
Architecture topic
These notes describe Kestrel, the controlled boundary between player-facing companion tools and the live game framework. Kestrel can present approved information and accept limited requests, but it does not gain direc...
Architecture topic
These notes explain how different players can receive controlled views of the same world and how protected areas remain isolated from effects that should not cross their boundaries. Layering can support private encoun...
Architecture topic
These notes explore NPC decisions, personality, emotion, memory, attention, and explainability. The design aims for expressive characters whose choices still remain limited by evidence, capability, policy, and availab...
Architecture topic
These notes describe optional matches that run alongside the main survival world. They include arenas, races, team battles, capture-the-flag matches, vehicle contests, infection modes, and other short game formats. Ea...
Architecture topic
These notes explore how NPC identity and history can matter over time. Local characters can keep meaningful continuity, while lineage and legacy allow consequences to survive beyond one individual lifetime.
Architecture topic
These notes describe AI that can be uncertain, mistaken, and influenced by incomplete evidence. Observations can become memories, rumors can spread and change, and NPCs do not automatically know the hidden truth of th...
Architecture topic
These notes describe how ADK measures runtime pressure, admits expensive work, records useful diagnostics, and reduces optional detail before server stability is threatened. For example, an overloaded server may lower...
Architecture topic
Pinky is ADK's narrow bridge to the game engine. It observes host facts, translates them into bounded data, and applies only operations that have already passed the appropriate authority and safety checks. These notes...
Architecture topic
These notes describe the deliberately small part of Pinky that sits closest to the game engine. It translates bounded host data and approved operations without moving general plugin logic onto the game thread. Pinky a...
Architecture topic
These notes define reusable gameplay-facing capabilities that many plugins can share, including AI and perception, combat, communication, inventory, movement, simulation integrity, user experience, and world topology....
Architecture topic
These notes describe how the framework communicates important information without overwhelming players with alerts. Messages can appear through the world, interface, sound, or other suitable channels. The system consi...
Architecture topic
These notes explain what a plugin must declare about its data, permissions, deployment effects, maturity, and security evidence. The declarations make review possible before installation and again before an update bec...
Architecture topic
These notes explain how plugins declare needs, receive permissions, expose configuration and commands, and combine framework capabilities into administration tools or gameplay. The area includes plugin governance, Kes...
Architecture topic
These notes explain how ADK records data use, respects player and server choices, limits identifying information, and supports access or deletion requests without weakening local authority.
Architecture topic
These notes cover how approved ADK state becomes game-visible effects, interface elements, selective visibility, historical replay, and network replication without pretending presentation is authoritative game state....
Architecture topic
These notes explain how ADK checks configuration changes, prevents stale updates, and stops plugin work that exceeds its approved limits. The goal is to make failure explicit. Conflicting or outdated changes are rejec...
Architecture topic
These notes explain where plugin code runs and how ADK keeps one plugin from interfering with another plugin or the game server. The runtime gives plugins approved capabilities, time limits, memory limits, and clear f...
Architecture topic
These notes describe reusable services that help plugins discover what the current server can support and choose an appropriate fallback when a preferred feature is unavailable. They also cover shared skill gates and...
Architecture topic
These notes explain how systems read a stable view of a changing game world and how selected runtime history can be retained for debugging or review. A snapshot provides one consistent moment without freezing the whol...
Architecture topic
These notes explain how AI groups choose leaders, maintain trust, react to pressure, and continue operating when plans or relationships begin to break down. Squad behavior is not controlled by one permanent commander...
Architecture topic
These notes describe common ADK functions, data models, capability helpers, and search tools. Plugins can use the same logical operations for routine work and select more specialized behavior through approved options...
Architecture topic
These notes describe tactical decisions made from incomplete evidence: threat assessment, squad command, movement, communication, supply, reinforcement, and multi-stage operations. NPCs and factions should act from wh...
Architecture topic
These notes describe how tactical messages, emergency signals, relays, and deliberate deception travel between eligible participants. Communication depends on available equipment, range, trust, disruption, and current...
Architecture topic
These notes describe long-running world memory: factions, markets, logistics, settlements, anomalies, crises, and selected continuity across wipes. The systems connect local events to lasting consequences while preser...