ADK is a large design, so the topic pages below divide it into smaller pieces. You do not need to read them in order or understand the internal names before starting.
Each main topic begins with a plain introduction: what that part of ADK is meant to do, why it matters, an example of how it could help, and where the work honestly stands. Deeper sections then collect approved public explanations from the project notes that own those subjects.
The pages describe a proposed framework, not finished software. Some ideas belong to the first implementation; others are longer-term possibilities kept in the design so the foundations do not accidentally make them impossible later.
Private plans, security details, internal evidence, file paths, and implementation records are not included merely because they exist. The public site is an explanation, not an unattended vault tour.
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 is turned into a package that a server can run, and how that exact package is checked before activation. The intended checks stay separate: build it, test it in an isolated copy,...
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 ADC services that can connect participating servers without taking control away from them. Each server still decides what happens locally. One possible service lets a player carry a truste...
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 stable ent...
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 retain...
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
This is the planned coordinator that keeps plugin work orderly when many things want to happen at once. What it is The execution kernel is the coordinator inside Brain. It would decide when plugins run, check their st...
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
This is the groundwork that helps ADK remember the right thing without making the game wait for it. What it is This area covers the information ADK needs while a game is running: what exists, what has changed, and whi...
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
This area covers optional services that could coordinate approved information beyond one local server. What it is Global systems are the optional parts of ADK that could help information survive beyond one moment, one...
Architecture topic
These notes explain how ADK checks what a game server and its exact build can actually see or do. A small game-specific adapter translates movement, physics, settings, landmarks, world conditions, and other native fea...
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 an intent 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 explore NPCs that can be wrong for believable reasons. An NPC may hear a rumor, remember it as fact, and make a poor choice until better evidence arrives. The design does not give every NPC secret knowledg...
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
This area covers the narrow bridge that lets ADK observe a game and ask it to perform approved actions. What it is Pinky is the planned bridge between ADK and the game engine. It would report relevant game events to t...
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
This area collects reusable gameplay building blocks that plugins could combine instead of rebuilding alone. What it is Platform features are reusable gameplay building blocks that many plugins could share. They cover...
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
This area shows how developers could turn ADK's shared building blocks into useful tools, events, minigames, and stranger contraptions. What it is This area covers the things developers could build with ADK. Plugins d...
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, rejects updates based on old information, and stops plugin work that exceeds its approved limits. For example, if two changes were based on different versions...
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 capability 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...
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
This is the planned toolbox for common plugin work: shared answers to problems that should not need fifty slightly different solutions. What it is The standard library is ADK's planned collection of ordinary, reusable...
Architecture topic
This area explores NPCs that plan from what they know and what they can actually reach, carry, command, or afford. What it is This area explores how NPCs and factions could make plans with limited knowledge, people, t...
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
This area explores game worlds where events, shortages, relationships, and mistakes can leave consequences for later. What it is This area explores worlds that remember more than the latest fight. Factions, markets, t...