Is it possible to run a physics simulation in the background for possible future outcomes?

I'm designing a physics-heavy game in 3d.

The core mechanic of this game is that the user gets to choose his actions based on probable future outcomes.

For example - the player has a choice whether to try option A, B or C. When the option comes up, I want to copy the game state and world into three separate simulations and then run the three options in super high speed to determine probable outcome. The game will then present the probable outcome for each player choice. This needs to happen instantaneously in terms of UX.

It doesn't have to be an exact copy of the game state, a simplified simulation can also work as long as the current world physics state can be duplicated and simulated.

How would you go about implementing this? Is there a way to instantiate a new physics world and run it in a separate thread?

 

You could instantiate three more copies in an offscreen area of the scene, perhaps simplified versions.

I would be getting ahead of myself to suggest object pooling rather than true instantiation, since this whole approach might not be the best solution. However, it would allow you to use Unity's Physics engine, although it might be a bit too heavy.

You could maintain the three simplified simulations at all times, rather than instantiating them at the moment of choice. This would keep framerates more stable. Then after choosing a branch to follow, you'd have to resync the simulations with reality.

If it works in your design, you might bypass Physics and maintain your own, simplified simulations instead. Then you wouldn't have to instantiate offscreen objects in the scene, etc.

 

PhysX doesn't have a way to simulate forward instantaneously.

If complicated collisions are not a factor in these simulations ("complicated" = anything you can't simulate with a raycast and a couple of physics-textbook equations), I would recommend writing your own physics solver to use there - follow the Kerbal Space Program route, where for orbit prediction they have a separate physics "engine" that does nothing but calculate orbits (which they also use for high time warp as well as prediction). Near the middle of Squad's Unite 2013 talk, they discuss this system, if you want to check that out for a bit of guidance.

 

Doh, not sure what I was thinking in my previous reply. Guess I was too focused on the second part, which StarManta wrote much better about.

(Oh, I remember -- I was thinking of fast-forwarding time, then resetting your real version. Again, not as good a solution as doing your own physics simulation.)

 

TonyLi, StarMant - thanks for the answers guys, you're awesome
I watched the Unite 2013 KSP talk and it was very enlightening.

However, it's not truly relevant to my case, so I'll try to elaborate on what it is I'm actually doing and maybe you'll have some good advice for me.

As part of my research thesis I'm working on an RTS game that is based on evolutionary models. Specifically I'm relying on this prior research, which modeled very simple virtual creatures with box colliders:

The "units" in my game are actually evolved creatures that have a defined target function. Units multiply and mutate while doing so, and those who are below a certain target function threshold die off.

So if for example your target function is creature speed, then throughout the generations only the fastests creature survive and after 1500 generations you get a pretty fast creature compared to the one you started with. This part is already working quite well in my Unity prototype.

The problem is that within an RTS game mechanic, waiting 1500 generations is no fun So I've set out to speed up the evolution part. My idea is that when a player chooses for a certain creature to evolve "to be faster" or "better at combat", the game will carry out the 1500 generation simulation in the background, and the "next" offspring of the creature will be the result of that simulation.

Does this shed light on my question?
There's nothing "special" in my physics use. The creatures are all comprised of simple box colliders, which PhysX handles quite nicely when simulating the evolution bit in real time. That is why I'm reluctant to re-write solvers that mimic exactly what PhysX is doing. The three-simulations-in-place idea is really interesting, but that will not allow me to run the simulation at a faster rate than that of the "real" game.

Maybe you have a better idea on how to tackle this? Much appreciated

 

In theory (not tested) you could speed up time in Unity using the Time manager, for both physics and the game loop (likely you'd have to tweak both) - but then slow down everything else, or roll your own timing for other things. It does mean you can't mix normal time physics with the sped up version though.