Physics engines compute the next states of modeled objects using "ticks" of processing. With each tick, the engine iterates on the objects, collects the relevant interactions and forces, calculates their effects, and updates the state of the object.
The availability of processing time for running a tick is variable. You may accomplish 60 ticks per second, or 50, or 40. When a lot of objects and interactions are involved, you will get fewer ticks per second.
To ensure that the computation remains consistent, you calculate the time passage since the last tick and use that "time delta" to scale the changes to state.
Example: an object with a velocity of 5 meters per second would have its position modified by (V x dT). If the time since last tick was 0.2 seconds, the tick's modification to the position would be (5m x 0.2s) or 1 meter.
Let's now assume a simulation in which
Each object is assigned an independent process,
Each process has instant access to the state of all other objects within some radius, and
There is no global clock.
In this simulation, the objects are processed under their own tick rates. The tick rates will depend on the computational load of the object's process.
We can expect that the tick rate of each object's process will be inversely proportional to the number of nearby objects, since each available object adds computational load.
The denser cluster on the left will have lower tickrates as there are more computations to be accomplished
With no global clock to correct against the differences of tick rates, we can expect a skew to emerge in the calculations.
To understand this, let's look at a spring force.
A spring will exert force to maintain a target distance
Two objects connected by a spring will attempt to maintain a specific distance (x above). If the objects are further than x, they exert an attractive force toward each other. If the objects are closer than x, they exert a repellant force.
Consider what happens if blue's tickrate is lower than green
The distributed simulation is not maintaining a consistent tickrate on each object. If blue's process is under heavier load than green, it will advance its computation at a lower proportional rate to green. Eg 1/5th the rate of green.
Lower tickrate reduces the effects of the spring on blue
This introduces an asymmetric skew to the results of the computation. As the green object is capable of processing the effects of the spring more rapidly, the centerpoint of the two objects will shift closer to the blue object.
In a scenario in which a collection of objects were connected pairwise by springs, this skew would cause the objects to be drawn together in aggregate, despite the lack of interactions between the objects.
Tickrate modulation causes a net effect on the springs
The modulation of the pairwise objects' spring forces would produce a net attraction toward other objects. Other kinds of forces than springs might have other aggregate effects, but the decreased effect upon clustered objects will remain consistent: The closer you are to a cluster of objects, the more force is required to move away from the objects. As a result, in this hypothetical distributed simulation, gravity is an emergent characteristic of processing load.
Is this a meaningful idea? I don't really know. This is something that occurred to me about 10 years ago when I read a paper that suggested intentionally modulating clock rates to handle network load in multiplayer games. I figured out the net effect on the phys sim, then modified the idea to unintentionally modulate clock rates due to distributed processing.
It's appealing to model the universe as a computational system. The laws of thermodynamics make intuitive sense to me as the result of computation - a system which is iterative, deterministic, but nonreversible due to information loss. Describing general relativity as a quirk of distributed computation is then satisfying to me as a distributed systems engineer.
I brought this idea up in front of some other engineers and they told me that this was the plot of Devs? I've never seen it.
At any rate, it might be fun to try a larger scale simulation and see if the model works. I'd need to come up with a more meaningful core set of forces than a bunch of springs though.