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 user experience.

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 I go about making this? I know Unity, for example, only exposes one instance of a physics world at a time.

  • \$\begingroup\$ Could you have a separate thread for each simulation and step the intervals faster than your game runs? I.e. if you're running at 60 FPS, update them for 120 FPS. That might only work if you're using a method similar to (or are using) Bullet, though \$\endgroup\$ Jul 29, 2014 at 21:05
  • \$\begingroup\$ Running a single option a single time will only give you an exact result state. How are you imagining this would be relayed as/transformed into probabilities? \$\endgroup\$
    – Attackfarm
    Jul 30, 2014 at 23:11
  • \$\begingroup\$ I was using the word "probable" to describe a "potential" outcome (since most physics engines are not really deterministic). I'm not trying to show which outcome is more probable, but just to show which outcome is likely, given that the player chose A, B or C. \$\endgroup\$
    – OpherV
    Jul 31, 2014 at 8:06

1 Answer 1


In most game engines, physics objects live in their own world, and are connected to game objects through some special logic, responsible, for instance, for copying transformations and notifying about events like collisions.

Your case sounds like it requires multiple physics worlds. Most physics engines will allow you to do that, as they are designed in a modular way to be added to any game engine. For instance, in Bullet you'd create multiple instances of btDiscreteDynamicsWorld.

As long as the physics engine is deterministic, you should be able to maintain a "real" physics world, plus a bunch of "simulation" ones. In order to predict the outcome you'll need to:

  • Step the physics world as far as required. You need to do it by calling the step/update function multiple times with small time deltas. Otherwise the results won't be stable. 60 fps is ideal, but can be expensive. It depends on whether you can afford a hitch while you predict the result.
  • Once you have the results, you can connect the physics world with your game world to display them. You'll have to write some special glue code so you can walk through all the objects in your game and connect them with the appropriate physics object (probably based on name), and then transfer the transform and any other info required.
  • Finally, once the player chooses an option, you simulate it using the "real" physics, in real time.
  • For the next choice, you'll have to destroy the simulation physics worlds and create new ones, up to date.

Unfortunately, I'm not sure how you'd do this directly in Unity. Engines tend to be optimized for the common cases, and having multiple physics worlds is unusual. The advantage is physics engines tend to be written in a modular way, so this should make it easier.

One thing to keep in mind is that if the final outcome depends on how objects react after collisions (e.g. exploding), then you may need to duplicate your whole game world. The only alternative to this would be implementing undo functionality, so you can rewind your world.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .