Design Overview

Design Overview:

1. The scheduler routinely initiates a new simulation step.

2. The engine retrieves game data from the database and loads it into memory.

3. Both AI agents and players submit their actions or decisions, all processed within a single unified loop.

4. After applying the game’s rules, the engine calculates a “diff” of the changes and saves the results back to the database.

1

Agents

Each monster or agent possesses a distinct identity and set of motivations, allowing them to wander the world, engage in dialogues, and build relationships. In the future, these agents will draw upon previous interactions—stored in a vector database (Pinecone) of memory embeddings—enabling every conversation and decision to be shaped by earlier encounters, creating a sense of persistent memory.

2

Game Engine

The orchestration system coordinates agent activities, executes "Run Agent Batch" tasks, and manages interactions. When the paths of two monsters are anticipated to intersect, the engine will group them and initiate a conversation sequence. Once tasks are completed, agents will become available for rescheduling, promoting an ongoing flow of activity in the world without the need for manual oversight.

3

Event Logs

A comprehensive, append-only record meticulously tracks all activities—agents' movements, conversation timestamps, and interactions between individuals. Prior to embarking on a new route, monsters reference their event logs to anticipate potential encounters. If they haven't interacted with a crossing agent recently, they initiate a dialogue. The Event Logs also house all conversation transcripts and coordinates, ensuring precise context recall and memory embedding.

4

Memory & Vector Database

Following interactions or moments of reflection, agents encapsulate their experiences as vector embeddings (mxbai-embed-large), which can be retrieved and filtered for relevance in subsequent conversations. A primary challenge in game engine design is maintaining low latency while scaling to accommodate more players and agents. To address this, DAMN introduces a compressed state called HistoryObject, which effectively tracks and replays movement. Each engine tick (~60 times per second) logs numerical data (such as position), and at the conclusion of each step (once per second), a compressed “history buffer” is created. The client retrieves both the current values and this replayable buffer, enabling seamless animations without any stutters.

5

Impact

This design facilitates fluid gameplay for both players and agents, eliminating disruptions or choppy visuals. Behind the scenes, it offers a streamlined approach that prioritizes high performance while reliably scaling for a larger number of AI-driven characters. Rather than depending on existing game engines like Unity or Godot, DAMN utilizes a custom-built AI-native game engine developed from scratch in TypeScript. In this architecture, AI agents and human players are treated equally—there are no inferior NPCs. Every tick, the engine updates the entire world in memory, granting AI the same capabilities to move, interact, and engage as human players. This results in more organic and dynamic worlds in which AI actively participates in gameplay rather than merely following predefined scripts.