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 declare what they need and use shared capabilities. An orchestration combines several capabilities into a larger experience such as an event, minigame, administration tool, profession, or unusual item.

Why it matters

The framework should make ambitious ideas easier without pretending every idea belongs inside the framework itself. ADK supplies reusable rules and services; plugins arrange them into experiences with their own purpose and personality.

A simple example

A rescue event might find trapped players, choose an available vehicle, create an NPC crew, reserve supplies, mark a route, announce information, and reward participants. The event plugin describes the story and desired outcome while shared services handle much of the repeatable machinery.

Where it stands today

The project contains many plugin and orchestration designs because they reveal what the core may need to support. They are design probes, not a promise that ADK will personally ship every minigame, profession, talking sword, and bureaucratic emergency imagined in the notes.

Protecting Identity in Evidence

This service prepares sealed evidence packages for independent review. Player and server identifiers are removed or replaced while the facts and context needed to judge the case are kept.

Redaction reduces identity exposure but does not hide that unusual events might still be recognizable indirectly. Review access remains scoped and audited.

Seeing Why an NPC Chose an Action

ADK is designed to let authorized administrators select an NPC and see a short explanation of what it considered and why it chose an action. The trace could appear above the NPC or in an administrator-only panel without changing the decision itself.

For example, an administrator could see that an NPC ran into danger because fear outweighed its estimated chance of reaching cover—not merely receive the unhelpful diagnosis "AI did something weird."

Scheduling Server Changes In Advance

Administrators can approve a setting, profile, event window, maintenance action, or other registered operation to happen later or recur on a schedule. Approval happens when the schedule is created, so the framework does not need an administrator to return every Friday evening and press the same button.

For example, a server may use PvE rules during the week, activate broader PvP on Friday evening, enable a final purge before wipe, and restore its ordinary profile when the new wipe starts.

Removing Access Without Abandoning Responsibilities

When an administrator leaves, changes role, retires, becomes compromised, or is removed for abuse, ADK immediately ends their administrative access and starts a reason-appropriate review. Work they requested but which has not started is paused until another authorized administrator accepts, transfers, or rejects it. The review also highlights what they did during the previous 24 hours so recent changes are easy to inspect.

Scheduled work and other continuing responsibilities can be transferred to another administrator or to the server-owning organization, or cancelled where they should not continue.

The historical record still shows who originally created and approved each action. Retirement may optionally be recognized through a former-administrator service record or server-local appreciation benefits, while abuse or compromise triggers a much broader review.

A Dungeon-Master View Of The Living World

A far-future administrator workspace may show what factions, NPCs, players, active battles, and likely story triggers are doing across the map. An administrator could inspect an NPC's current targets, understand why a battle is leaning one way, and deliberately nudge an event or character when the unfolding story no longer suits the server.

It is a director's control room, not an all-seeing power silently given to ordinary moderators. Every view and intervention remains permission-bound, temporary where possible, and attributable to the administrator who used it.

Test Environment Creation

ADK is designed to let an administrator create an isolated test version of approved server configuration and plugin state. Software inside the test environment may behave as though it is changing the server, while production data remains unreachable.

This could be used to compare a proposed plugin version with the current one or exercise a risky configuration before deployment. Results and reports may leave the sandbox; test mutations do not flow back into production.

Player Experience Analytics

This service collects player feedback and game data. It creates aggregate reports for admins. The system focuses on what players do, not why. Personal details are kept private. Reports show patterns over time.

Power Grid Topology

ADK is designed to add missions, faction behavior, maintenance, sabotage, and other consequences to an island power grid. When a game already supplies a suitable grid, ADK would observe and augment it instead of building a competing electrical simulation.

For example, repairing a native power station could change which monuments receive power, attract faction patrols, or create a sabotage objective. A framework-owned fallback would be considered only for hosts that lack the required native capability.

Server-Defined Raid Rules

ADK's planned raid-policy service would let a server define when raids are allowed and which optional protections, online-engagement incentives, and frequency limits apply. It would explain each decision while coordinating existing damage, evidence, reward, quota, and notification systems rather than replacing them.

For example, a server might enable a gradually reduced protection curve after every eligible defender has been offline for a while. The same policy could explain the current protection, notify affected players, and preserve a timeline for later review.

Recycler Death Hazard

Standing on an active recycler quickly harms and then kills a player rather than merely downing them. The player's carried items are immediately recycled into components with a high loss.

Someone who stops the recycler within three seconds may still save the player.

Helping Players Find Compatible Groups

ADK's planned matchmaking service would help players find collaborators who fit their group. It uses voluntary preferences, declared needs, and playstyle signals. A raid group could ask for builders, electricians, vehicle specialists, or calmer players rather than just asking for more humans.

Players decide when they are looking and what their profiles may show. The system does not publish a listing automatically, force pairings, or turn behavior into a moral score. It explains a proposed match and requires the relevant players to accept it.

Graveyards That Remember The Dead

Administrators can mark areas as graveyard zones. When players die nearby, one tombstone may form from the death. Night rules might later turn that tombstone into a ghost, zombie, or species-specific continuation.

Tombstones created this way do not copy inventories. Killing the continuation does not create another grave. The system only applies these effects under specific conditions and does not change how players normally die.

Progress That Connects Separate Adventures

A plugin may tell a longer story through several missions and events without keeping one enormous event running for an entire wipe. This service remembers which stages have been reached and which verified results unlock the next stage.

For example, finding a terminal card, meeting a trader in a moving hideout, and completing a raid can remain three separate scenarios with their own cleanup. A small progression record connects them. It does not award items, change reputation, or decide dialogue by itself; those systems confirm their own results.

Reusable Building Blocks for Events and Minigames

ADK is designed to let a scenario describe its participants, phases, objectives, scoring, restrictions, and cleanup without rebuilding the supporting machinery for every event.

The same search, navigation, escort, or survival ability could support both a persistent world event and an isolated arcade-style minigame while keeping their consequences separate. Official scenarios may expose chosen extension points for optional objectives, presentation, rewards, or side encounters. A developer who wants deeper changes may instead fork an openly licensed recipe into a clearly separate version.

World events may be discovered through witnesses, rumours, visible preparations, or consequences instead of a global announcement. Minigame notices can be opt-in, and the same composition may represent one short local incident or a much larger seasonal story.

A Zombie That Does Not Stay Entirely Here

ADK is designed to support an anomaly that shifts between a faint spectral presence and a fully physical zombie. What players see, hear, and can affect would change with the creature’s current state, its rising rage, nearby conditions, and the tools used against it.

The orchestration would coordinate those transitions without secretly owning player health, enemy statistics, inventory, or environmental truth. A failed crossing might be interrupted and produce a bounded consequence; a successful one would create one properly accounted-for physical threat, not a duplicated ghost with paperwork problems.

When the World Remembers

ADK is designed to let past events and remembered characters leave carefully limited spectral traces. A ghostly figure could repeat fragments of an old patrol, react to a place associated with its memory, or whisper a piece of local history only when a player comes close enough to hear it.

The anomaly would coordinate approved memory, sound, and visual effects without rewriting the world's established history. Suppression effects and proximity limits could keep spectral activity rare enough to remain unsettling rather than turning every monument into a paranormal staff meeting.