[!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.
- Initialization: On load, the manager iterated over a list of
TimeTrialDataobjects, instantiated the course prefabs (timeTrialPrefab), and kept their physical checkpoints disabled until needed. - Activation: When a player entered a
TimeTrialActivityTrigger, the route activated, the timer (currentTimeInTimeTrial) began, and theCheckpointManagerwoke up. - Hierarchy Parsing: The
CheckpointManagerdid not rely on strict manual arrays. Instead, it found all objects taggedCheckpointParentand sorted them dynamically based on sibling index in the Unity hierarchy withGetSiblingIndex(). - 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 theTimeTrialDataobject.
TimeTrialManager — main relay for time-trial state.
CheckpointManager.
TimeTrialData — route placement, prefab reference, and trial parameters.
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:
- Standard Practice: A set duration where the player shot static or moving targets for score.
- Quickshot Challenge: A higher-pressure variant with a strict
quickshotChallengeDuration, where the player had to shoot as many targets as possible before time ran out.
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 — bullet layer, target prefab groups, and active challenge binding.
TargetConfig templates — standard vs quickshot, scoring, and completion tracking.
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:
- assign the event a round count
- define enemy spawn locations
- define what enemies can spawn
- optionally assign a boss-type enemy for the final round
- attach the mode to whatever player-data/profile tracking was needed
The core logic was:
- Start the elimination event.
- Spawn enemies for the current round.
- Track remaining enemies and round time.
- Fail if the player does not clear the round before the timer ends.
- 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.
EliminatorManager — rounds, enemy prefabs, spawn points, timer per round, optional boss.