Data Workbench System

Category: Progression, Resource Management, and Information Processing
Context: This system was one of the central economic and progression pillars in Data Division. The player goes out to obtain data, then has to decide what to do with it: synthesize it for progression, sell it for money, or route it elsewhere. That choice was meant to shape both the player’s material survival and the behavioral direction of the AI-drone over time.

What The System Was For

The data workstation is where the player synthesizes the data. This was the main leveling and long-term progression path. Raw extracted data was not meant to be just a generic loot number. It was the central resource of the game.

That is also why the project was named Data Division: the player is going out to obtain data, and then making a meaningful decision about it.

The intended high-level split was:

• Synthesize the data for XP / progression.
• Sell the data for money and upgrades.
• Donate / route the data in ways that affect faction alignment and drone behavior.

The drone’s level of reactivity was supposed to be partly dependent on what the player did with that data.

The simplified directional behavior plan was:

• donating data to the government would make the drone more oppressive or aggressive
• selling data to companies would make the drone friendlier but more selfish
• donating data to the player-aligned group would make the drone act more aware and more covert

So this was not just an economy system. It was also the beginnings of a behavioral and political shaping system.

What The Data Workbench Is

The Data Workbench is a system where players manage and process captured data using a workstation if they decide not to sell the data for immediate profit.

At the concept level, this leaned on a very basic truth about modern AI systems: without data to train on, infer from, or process, the system has nothing. So the game tried to make data feel like a real resource rather than an invisible abstraction.

Within Data Division, the workstation can be configured with different GPUs to alter throughput, cost, and scale. The main components were:

• WorkstationConfig: defines the properties and behaviors of a workstation, including GPU management and data processing
• WorkstationManager: manages a single workstation, GPU placements, and activation behavior
• SimulcraManager: manages multiple workstations and their processing expenses at the systems layer
• Database: stores the synthesized/processed information up to a finite capacity
• Flashdrive / insertion logic: moves captured data into the workstation pipeline

Core Loop

At a gameplay level, the loop was:

1. Extract data in the field.
2. Return to the neighborhood.
3. Insert the captured drive into the workstation.
4. Offload raw data into the local processing pipeline.
5. Use installed GPUs to synthesize/process that data.
6. Store it in a finite database.
7. Decide whether to use the output for progression, money, or factional/behavioral routing.

This made the workstation the home-base mirror of the field-heist loop.

graph TD
    A[Stolen Thumbdrive Inserted] --> B[Data Dumped to Workstation]
    B --> C[Empty Thumbdrive Ejected or Reused]
    B --> D{Data >= Processing Threshold?}
    D -- No --> E[Wait for More Raw Data]
    D -- Yes --> F[Process or Synthesize Data]
    F --> G[Upload to Active Database]
    G --> H{Sell, Use, or Route?}

GPU Workstation Logic

Whenever the player buys, finds, or places a GPU at the workstation, the game instantiates a gpuPrefab into the correct placement transform and assigns the relevant GPUData.

There is a hard cap of 10 GPUs because of literal space constraints on the workstation prop.

Each GPU contributes to:

• processing strength
• memory capacity
• processing cost / quota burden

That running cost matters because GPU-heavy processing and LLM-style computation are expensive. The player was not meant to ignore infrastructure cost. More GPUs improve processing power, but also increase the burden of keeping the workstation running.

Default Workstation and Attached Database

The first workstation is driven by a DefaultWorkstation ScriptableObject. That object stores the baseline workstation behavior and also requires an attached database.

Important fields included:

• sizeOfDataToReachProcessInGB
• default GPU / slot expectations
• currently attached database
• historical pastDatabases reference

The sizeOfDataToReachProcessInGB field is exactly what it sounds like: how much raw data must be accumulated before the workstation can synthesize a processed result.

This mattered because the system was not supposed to reward every tiny haul equally. The player had to either:

• commit to infrastructure and accumulation
• or cash out early and stay materially afloat

EXP System

The EXP system tracks workstation progression based on the amount of data processed.

This was not a generic player XP meter in the abstract. It was tied to how much data the workstation had successfully synthesized over time. An AnimationCurve defined the progression shape so the designer could control how early growth versus late growth felt.

Key progression behavior:

• track current and max levels
• update based on processed data volume
• level up only when synthesis thresholds are met

This means progression was materially linked to information throughput, not just mission completion.

Simulcra Manager

The SimulcraManager is the singleton manager for the broader workstation ecosystem.

Its job was to:

• ensure only one manager exists
• instantiate and track workstations
• monitor active stations
• calculate total processing expense across all active GPU usage

So while WorkstationManager handled the local prop-level behavior, SimulcraManager handled the broader economy and infrastructure layer.

Downloading and Information Flow

Downloading the data was itself a pipeline of components and actors.

When a thumbdrive is inserted through gameplay, the system sets currentInformationTypeBeingProcessed and begins processing based on the workstation’s current GPU loadout.

Once the pipeline starts, isCurrentlyProcessingData becomes true until processing completes or is interrupted.

The flashdrive itself is a world item. When it enters the non-functional USB mesh trigger, it is treated as inserted and starts downloading or transferring however much data had been captured on that drive.

This means the drive is not just an inventory icon. It is an actual object participating in the workstation loop.

Database Behavior

The database stores processed information and has a finite storage limit.

That means:

• every database has a maximum capacity
• once full, another database has to be used
• capacity can be tuned per database instance
• the system can retain old databases for historical reference

This prevents infinite invisible accumulation and keeps data as an infrastructure problem rather than a magical number.

Scene Constraint

The WorkstationManager was intended to be available only in the Neighborhood scene.

That mattered structurally because the workstation was part of the player’s home-base and recovery loop, not something meant to be carried into the active field space. The field and the workstation were supposed to feel like two linked but distinct phases:

• field: risk, extraction, acquisition
• neighborhood: synthesis, storage, progression, and alignment

Why This System Mattered

This system was one of the clearest places where Data Division moved beyond simple heist logic.

The player was not only stealing information. They were deciding what kind of relationship to build with information:

• as money
• as progression
• as alignment
• as training material

That made the workstation one of the more important bridges between the educational AI-literacy framing and the more game-like extraction/progression structure. Even in the more action-brained branch of the project, this system retained some of the original thesis: data is not background flavor, it is the thing the entire world is organized around.