Bah. Bad page title.

Interacting Bodies

I'm trying to work out a problem here.

Basic Dead Reckoning works on the assumption that each object has a distinct owner. That owner is the authority on the object's state, and provides authoritative updates to reflect the effects of internal state changes - like throttling up a ship's engine, for instance. These internal state changes can only be effected by the owning node, so this arrangment makes sense. Embellishments discussed elsewhere (Software Architecture Ideas/Distributed Security) can introduce authoratative monitoring nodes that can override apparent attempts at hackery, but this doesn't change anything fundamental about how the physical simulations on different nodes stay in synch.

What happens, though, if you want to model objects that affect each other?

Consider a 'tractor beam', or more prosaically and concretely, a tow cable. (They would be simulated similarly, but the beam might not be visible.) This allows the player's ship to apply a force to, say, an asteroid. (A very small asteroid, probably.)

One way to model this is for the player to become the owner of the asteroid, and thus the player can apply 'thrust' to the asteroid just like he can with his ship. Barring hacking, the client program would apply only appropriate force, and would model the effects of force and counterforce between the 'roid and the ship itself.

Points arising (to borrow one of Chris Date's favorite phrases):

• The ship, cable, and 'roid become a single system, owned by the player's node.
• The burden is on the player's node to simulate the entire system, and provide updates to other nodes.
• The player's view will be very accurate and up to date, which is probably good when towing a heavy object right behind your ship. :-)
• Other nodes will receive corrections to the entire system, periodically bringing both the ship and the asteroid back to their correct positions.
• If a second ship attaches to the same asteroid, ownership of the system is in dispute, and this approach breaks down.

Alternately, the connection between the ship and the 'roid could be handled by the overall physical simulator. The cable becomes part of the physical simulation. The player continues to control only his ship, and the effects on the asteroid via the rope are modelled by all nodes themselves. This, however, does not directly model the counterforces on the player's ship.

Points arising:

• The entire simulation is a system, with the possibility of objects interacting. There are a variety of methods for building such a simulation, modelling constraints that represent the interactions.
• All nodes simulate the path of the asteroid based on the actions of the ship. For nodes other than the player's, ship state updates periodically correct the ship's position. The asteroid position, however, can only be corrected by rewinding the simulation and accurately simulating the ship's actual path. Messy. Even this might not work well, since the entire ship path is not known, only a snapshot of updated state.
• Because of the action on the ship by the asteroid, calculating error thresholds gets more difficult. The owning node will be calculating the predicted path based on its knowledge of the asteroid's position. Errors in the asteroid's position on other nodes will cause them to simulate something different. This effect may or may not be significant, but might lead to larger warping effects than usual on the non-owning nodes.
• If a second ship attaches to the same asteroid, rewinding the simulation becomes complicated, since updates from the two ships arrive at unpredictable times. The system consisting of two ships and an asteroid becomes very chaotic. (Actually, I believe even the two-body system would qualify as chaotic.)

At this point, you may be having thoughts along these lines: "So that's why Jumpgate doesn't let ships and 'roids interact." Or perhaps even, "What a wise choice that was on NetDevil's part."

Here's a possible out, although it introduces additional networking mechanisms that will cause a player's control over his ship to become less accurate. Perhaps this will be worthwhile, assuming that such situations are not the norm...

The problem can perhaps be solved by a shift in ownership. When a player's ship attaches to another object, ownership of the ship shifts to an objective node -- a server. The server is now the authority for both the ship and the asteroid. The player's control over his ship now has to occur by sending requested changes to the ship's internal state (thrust vectors and such, but not kinematics such as the actual acceleration, velocity, and position) to the server. Control will not be as precise, from the player's point of view.

Other nodes will either model the two objects independently, or as interacting objects, as described by the two alternatives earlier. In the former case, frequent state updates will need to be sent, because the nodes will be modelling the asteroid as if it were drifting normally. In the latter case, the nodes will simulate more accurately. In both cases, all nodes will be receiving updates for both objects, keeping the nodes in synch (over time, on average, as is normal for dead reckoning). The choice will be a matter of quality desired. It seems likely that the server will have to do an interacting simulation in any case to model what's happening, so the same code might as well be applied to the other nodes.

This method also extends gracefully to accomodate the case where multiple player objects become part of one system; they all undergo the same shift in ownership.

JDH This approach of transferring ownership would seem like it's the only feasible one (the former two appear to be too complex / chaotic). The reduced accuracy of control might be rationalized by the fact that in general the player will be towing something of great mass which generally causes sluggish response. However, my concern is that although response in the real world is sluggish it is even more critical to be able to issue fine grained and predictable control input in these situations (otherwise the system quickly becomes unstable). Another concern is that I believe we would create a more noticeable hierarchy between 56Kers and LPBs - you'd really want a high fidelity connection to consider towing. Oh yeah, the more we ask the server to do the more horsepower we'll need - but I'm not too concerned about that. Ultimately, I think this is an area where experimentation might find a usable compromise. DWM Agreed on all points. On slow connections, the control input sent up to the server will be unreliable, we just have to make sure that it's unreliable in a reasonable way. Carefully selecting the form of the control input would help (desired attitude jet positions and thrust settings, rather than incremental joystick and throttle changes), and we would also have to cull old data that has not yet been transmitted when it is superseded by newer data. Perahps it would be possible to do some form of 'smoothing', but I'm not sure that would be applicable. Experimentation sounds good. :-)

Side note: Interactions that are effectively one-way, such as the gravitational interaction between a planet and a ship, are not a cause for concern. The planet won't be affected in any significant way no matter how many player ships it interacts with, so we model it as a one-way effect, and each node's simulation will be completely accurate.

Side note: Determining who will own a group of interacting bodies should be fairly straightforward, if we assume that there is a hierarchy of ownership in place. The owner will be the common parent node of all the bodies involved. If the server network evolves to a large hierarchy that is arranged to follow the network topology (i.e. parents for a topological region, children closely adjacent to one another), this will place ownership automatically at a good compromise node for all involved players. (All objects are ultimately owned by the root node.)