The Candidate Spawning Strategy
Another incredibly powerful gameplay architecture to resolve the boundary between location-based spawning and time-based progression is The Candidate Spawning Strategy.
When building dynamic gameplay milestones—such as spawning a time-dependent checkpoint or a finishing race-line that should only become visible or active once a specific game timer concludes—you cannot use the Elastic Graph to decide when the asset appears on the screen.
Instead, you use the graph to handle spatial distribution, and a traditional Unity manager to handle temporal progression:
1. Spawn Invisible "Candidates"
Inside your Elastic Graph, use standard spawner nodes (such as the GridSpawner or PoseSetSpawner) to distribute invisible placeholder prefabs (called "Candidates") across all potential, valid coordinates on the map.
These placeholders represent all possible locations where the milestone could physically appear on the terrain.
2. Evaluate via a Central Manager
Attach a lightweight script to these placeholder prefabs that automatically registers each instance with a central, time-dependent MyCandidateManager upon spawning:
private void OnEnable()
{
// Register this spatial candidate with the central candidate manager
MyCandidateManager.Instance.RegisterCandidate(this);
}
private void OnDisable()
{
// Cleanly unregister when recycled back to pool
MyCandidateManager.Instance.UnregisterCandidate(this);
}
3. Toggle Visibility Dynamically
The central manager maintains a static list of all active candidates. When your time-dependent game state is met (e.g., "Trigger the finish line now!"):
- The central manager queries the active candidates list.
- It evaluates which candidate is at the "best" coordinate (such as the candidate closest in front of the vehicle's forward vector).
- It toggles the visibility (and activates the meshes, materials, and colliders) of that specific candidate, smoothly turning an invisible spatial coordinate placeholder into your active finish line!
This decoupled design allows the location-dependent graph to handle optimized, spatial distribution, while standard C# scripts handle high-frequency, time-dependent game states!