Foundation and Memory
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 which version of an object a request refers to. Brain keeps the framework's working view, while Pinky reports what the game engine actually did.
Why it matters
Fast-moving games produce a great deal of changing information. ADK must avoid repeatedly copying, converting, or searching through data that has not changed, while still refusing to mistake an old fact for current reality.
A simple example
If a vehicle is destroyed and the game later creates another vehicle in the same memory location, ADK must not deliver the old vehicle's repair order to the new one. Stable identities and clear generations help keep yesterday's jeep from haunting today's bicycle.
Where it stands today
The project has detailed designs for memory ownership, identity, change tracking, and recovery. Their real speed and memory cost still need to be measured in an implemented runtime.
Storing Components Locally
Warehouse stores local component data that Brain logic reads and changes. It tracks where components are kept in memory. Warehouse does not manage databases or plugins. It only handles local storage of components.
It depends on contracts for memory rules and persistence boundaries. Pinky is not part of Warehouse. Warehouse does not interact with Pinky. This service does not make decisions about mutation order. It applies writes only when an approved authority selects the operation.
Example: Warehouse can hold a live component for Brain, but a separate service must decide whether a proposed change is allowed.
Memory Discipline for Fast Paths
Hot-path services must use bounded memory structures. They cannot use unbounded or dynamically sized data. The system avoids delays by preallocating memory. Work that stalls the host tick is not allowed. These rules only apply to hot-path services.
This keeps performance strong and prevents slowdowns.
Finding Things Quickly by Location
Spatial Hashing is a local service that speeds up spatial queries. It groups objects into buckets by location. This helps answer questions like 'what is near this point?' without deciding where objects actually are.
Other systems control real-world rules. The Brain owns the source data. The Warehouse provides authoritative state. The service does not make decisions about object placement or behavior. It only supports fast lookups. It cannot change the actual world. It never makes final game logic calls. Only approved Brain owners can update the index.
Where Data Lives While ADK Is Running
ADK decides which information needs to remain in fast memory and which information can move to slower storage. It does not commit the project to one database or storage technology.
Plugins cannot choose their own storage location directly. They declare what they need, and the framework places the data according to shared performance, validity, and recovery rules.