[!NOTE] The core mechanic of “picking a place to go, doing something, and leaving” was functional early on. However, stakeholders requested more immediate action and gameplay loops. That mandate pushed engineering time toward standalone activities such as target practice, time trials, and elimination-mode combat instead of letting the prototype stay concentrated only on the broader extraction/progression path.

Dynamic Game Modes

Category: Activity Structures
Context: Beyond the core extraction loop of Data Division, the game used multiple in-world activity types layered onto the hub and level spaces. These were not menus - they were embedded activities managed by independent systems that overlaid objectives onto the existing world space without requiring hard scene loads.

Screenshots below are from the internal POV: Pixelshift technical documentation export (same numbering as the source doc). Unity build settings / tags-and-layers-only frames are omitted.

Activity Type 1: Checkpoint Racing (Time Trials)

The TimeTrialManager handled checkpoint racing courses. Rather than hard-coding races into levels, it used dynamic prefab instantiation.

  1. Initialization: On load, the manager iterated over a list of TimeTrialData objects, instantiated the course prefabs (timeTrialPrefab), and kept their physical checkpoints disabled until needed.
  2. Activation: When a player entered a TimeTrialActivityTrigger, the route activated, the timer (currentTimeInTimeTrial) began, and the CheckpointManager woke up.
  3. Hierarchy Parsing: The CheckpointManager did not rely on strict manual arrays. Instead, it found all objects tagged CheckpointParent and sorted them dynamically based on sibling index in the Unity hierarchy with GetSiblingIndex().
  4. Resolution: If the clock exceeded timeTrialLength, the trial failed. If the player hit all checkpoints sequentially, their completion time was recorded and translated into a star rating by the TimeTrialData object.
TimeTrialManager component overview
TimeTrialManager — main relay for time-trial state.
Time trial instantiated route and checkpoint wiring
Instantiated trial prefab, route transform, and attached CheckpointManager.
TimeTrialData ScriptableObject fields
TimeTrialData — route placement, prefab reference, and trial parameters.
Checkpoint ordering and sibling index behavior
Checkpoint route / ordering context (hierarchy-driven GetSiblingIndex sorting).

Activity Type 2: Target Shooting

The TargetChallengeManager orchestrated shooting-gallery mechanics. This was a separate activity type from checkpoint racing - the player went to a physical shooting range in the world.

It bifurcated into two variants based on the attached TargetConfig:

graph TD
    A[Player Reaches Target Range] --> B{Challenge Type?}
    B -- Normal --> C[Spawn Fixed Target Count]
    B -- Quickshot --> D[Start Challenge Timer]

    C --> E[Shoot Targets]
    D --> F[Player Shoots as Many as Possible]

    F --> G{Time Up?}
    G -- No --> F
    G -- Yes --> H[Calculate Star Rating]
    H --> I[Reward: 1 to 3 Stars]

To prevent memory leaks and overhead during frantic shooting, the system used object-pooling concepts. When a target was destroyed, the manager listened via an OnTargetDestroyed action and cycled the empty placement transform backward into a Queue<Transform>. That allowed repeated spawning within limited physical placements without overlap.

TargetChallengeManager and bullet layer configuration
TargetChallengeManager — bullet layer, target prefab groups, and active challenge binding.
Target config selection and challenge modes
TargetConfig templates — standard vs quickshot, scoring, and completion tracking.
Target activity trigger for debug and play
Activity starter / trigger hook for standing up a range instance quickly.

Activity Type 3: Elimination

Elimination was intended as a more specific game-mode structure rather than a generic filler activity. The design direction for it was illegal bot-fighting rings: a contained event type where the bot/drone would be the focal actor inside a higher-pressure combat loop.

The setup intent was:

The core logic was:

  1. Start the elimination event.
  2. Spawn enemies for the current round.
  3. Track remaining enemies and round time.
  4. Fail if the player does not clear the round before the timer ends.
  5. Advance until the final round, then spawn the boss-type enemy if configured.

So the important point is not that there was another random minigame. It is that elimination was supposed to become a bot-centered illegal fighting-ring mode inside the broader Data Division world.

Eliminator Manager rounds, spawns, and boss configuration
EliminatorManager — rounds, enemy prefabs, spawn points, timer per round, optional boss.
Simple door trigger system for arena access
Arena door / trigger setup (open on enter — further expansion was planned for context keys).