How ADK Fits Together

ADK separates game integration from heavier framework decisions so each part can do one understandable job.

The simple picture

ADK is designed to sit between game-server plugins and the game itself. Plugins ask for outcomes, ADK decides how accepted requests fit together, and the game still has the final say over what physically happens inside it.

The design separates that work into a few named parts. The names are slightly whimsical; the jobs are not.

Brain and Pinky

Brain runs outside the game engine and does most of the framework's thinking. It keeps ADK-managed information, schedules work, checks requests, and decides the order of accepted changes.

Pinky is the small bridge beside the game engine. It notices relevant game events and carries out approved actions. It stays deliberately light because heavy work there could slow the game server itself.

Plugins send structured requests called intents instead of changing important framework data behind ADK's back. The game engine remains in charge of its own physics, objects, and final accepted state.

Shared services

Other parts of ADK would handle jobs that plugins often rebuild: settings, saved data, permissions, menus, searches, outside connections, and diagnostics. Developers get reusable building blocks, while administrators get a clearer place to inspect access and disagreements.

For example, several plugins may need to know which players are inside a town. ADK could maintain that answer once and let each approved plugin use it, rather than making the server repeat the same search for every plugin.

Optional ADC services could later help with approved accounts, distribution, and information shared between servers. A local server should still keep running when those central services are unavailable.

Where it stands today

This is the intended division of responsibility, not a report from a running system. The first implementation still has to prove that these boundaries work under real game-server load and failure conditions.