Player Data and Dependent Systems

Category: Groundwork Architecture and Runtime Dependencies
Context: This page documents the groundwork layer that multiple Data Division systems depended on. The useful portfolio point here is not one isolated mechanic. It is the architectural baseline that made the run loop, drone logic, items, and venue systems talk to each other.

Why This Layer Mattered

There was an array of systems that depended on other systems inside the Data Division prototype to be functional.

The internal shorthand in the documentation was:

Bot and Drone mean the same thing. I used bot to keep it agnostic in case the project pivoted into something broader later.

The main dependent stack was:

• Map System
• Player Manager and PlayerData
• Bot Manager
• Item System

CameraStateManager and TimeManager also existed in the broader groundwork, but they are not the useful focus for this portfolio pass. The stronger point is the way player state, bot state, level state, and item state were all expected to interoperate.

PlayerSaveData

The player side used a PlayerSaveData / PlayerData asset to keep the active profile state.

The important fields visible in the asset are the right kind of fields for a persistent-run architecture:

• Username
• User Occupation
• Account Number
• Account Wallet
• Chosen Bot
• Last Day
• Last Week
• Last Month

That mattered because the player was not only meant to have money and inventory. The player was also meant to have:

• a profession or role identity
• an attached bot/drone profile
• calendar-style progression state
• persistent save information that could drive downstream systems

Why The Player Layer Was Useful

This was the baseline for systems that needed to answer questions like:

• What profession is the player currently presenting as?
• What bot is assigned to the player?
• How much money do they have?
• What day/week/month is the run loop on?
• Which persistent values should survive between runs?

That is why this file belonged in groundwork rather than in a single isolated mechanic page.

Dependency Graph, In Practice

At a high level, the runtime stack looked like this:

graph TD
    A[PlayerSaveData] --> B[Player Manager]
    A --> C[Bot Manager]
    A --> D[Item System]
    B --> E[Map / Venue Selection]
    C --> F[Drone / Bot Runtime]
    D --> G[Trader / Inventory / Flashdrive Flow]
    E --> H[LevelManager and LevelData]

This is the cleaner way to understand the project:

• the player profile anchors persistent state
• the bot layer depends on player and level context
• the item layer depends on player ownership, value, and transfer logic
• the map and level systems depend on what venues and control modes are active

Relationship To The Other Data Division Pages

This groundwork page is the architecture bridge between:

• Level Manager System: LevelData, Scene Staging, and Venue Selection
• Bot and Drone System: Custom Flight Logic and Asset Integration
• Item and Trader System: Collectables, Flashdrives, and Factional Value
• Data Workbench System: Processing, Synthesis, and Information Flow

That is the practical reason to keep it as its own page. The project stopped being legible when everything was flattened into one large technical dump. This page restores the baseline architectural picture.