I have a character building constructs all over a pretty large map. My game blends elements of RTS and fast paced action in a room-based environment where players can only see one room at a time.
I would like to be able to do physics simulation, projectiles and high frame rates in the room the player is in, while also maintaining a significant number of AIs (a few thousand, maybe) wrecking all the buildings that the player has created in other rooms. I want their behavior to be approximately consistent with what they'd do in front of the player.
I have a few ideas I could use feedback on, but I'm mostly wondering what creative approaches are out there and where I can read about this kind of architectural problem (must be common for complicated RTS games)
- Avoid particles, projectiles, turn off anything that's un-needed for non-visual simulation
- Switch all offscreen objects to "offscreenSim" versions of expensive components or somehow switch from running their
Update()methods to running a
SlowUpdatewould run in another thread and do the same thing as
Update, except it would be called less often with much longer deltaTimes. Maybe some semaphore would throttle them to share a fixed total pool of worktime allowance per second.
- i.e. the more objects in the simulation, the longer between SlowUpdates.
- They'd also probably need to use path-intersection based triggers instead of collisions, since they'd be at risk of skipping through normal sized colliders.
- Or.... Maybe I could recreate a completely simplified graph representation of rooms and their inhabitants and just say "there's a path for enemies to go between A->B->C, there's a turret in B, here's a formula for enemy damage/turret and turret damage/enemy."
- This approach seems like it could save a lot of performance, but making two simulations deterministically consistent, plus translating between both representations sounds like a major headache (though maybe players wouldn't notice inconsistency)
- Separate the world into clusters of rooms and leave clusters the player isn't in totally inactive. When a player goes between rooms, run the entire simulation of the cluster they're entering up to that moment in time at 10x speed while showing them a loading screen (I'd worry about keeping them on a loading screen for too long)