What would it take to make the client program 'open', in the sense of "open to development of alternative user interfaces or platforms" by other people or organizations?
Security
See /Distributed Security. The scheme described there could go a long way towards making an open client feasible. We could make the physics engine available, in binary or even as source. Ideally, hacking the game's physics would not confer any undue advantage at all; if a client's physics modelling is out of whack with that used by other nodes in the game, then updates that client provides will be flagged as erroneous.
Object ownership management and arbitration over significant events involving multiple objects (e.g. weapons hits, docking) would have to be carefully designed to provide this type of security.
Being an owning node for an object means that the node can send updates about that object's state directly to any other client. This encourages that objects which a player cares very much about or which a player directly controls will be simulated locally, making them very responsive as compared to a remotely owned object.
If an authorized server objects to a state update (such as an object activation), then it will tell all interested parties of the violation. Additionally, a state update that appears impossible to a client's own simulation code will cause a rejection, and a notification to an authorized server. In the case of an update of physical parameters, e.g. position or velocity, it's the physical simulator that would make such checks.
In the case of object activation, another player's client program can't directly verify that the object exists; object existence and ownership is verified only by servers. So clients should probably only accept object activation notifications from authorized servers, forcing a client that wishes to active an object to do it via a dialog with a server.
Example: Player Fires Missile
Player A's client notifies an authoritative server that a missile has been activated with certain initial conditions. The server verifies that this missile existed and was at the location specified. (The database will need hierarchical ownership information for inactive objects; e.g. the inactive missile is known to be in the players ship prior to independent activation. This implies that loading armaments into a ship also requires interaction with a server.) The server forwards the activation information to all interested parties.
All clients now start simulating the missile's motion, and receive authoratative updates from Player A's node. According to /Dead Reckoning, these updates will override local simulations, but according to /Distributed Security, they will be checked against what's considered feasible. (See next section, 'Determing Feasibility'.)
Player A's machine simulates the missile's guidance system. Other players' simulators assume that the missile's dynamic characteristics -- thrust, orientation -- are constant between updates. These other players may see 'skip' lag effects if the updates arrive slowly. The missile's guidance simulation may have the same problem vis a vis the target that it tracks. (Perhaps the allowable error band in the dead reckoning algorithms narrows as the objects approach one another, causing more frequent updates.)
At some point, the missile's proximity logic dictates detonation, or collision occurs. (These two types of events can probably be simulated similarly -- treat missile radius of effect as an object?) A notification of this event is sent by Player A's computer. Since Player A's computer believes that it has directly affected Player B's ship, a special interchange is initiated by with B (because B owns the affected ship). The two will try to agree on the precise positions of the involved objects at the time of the event -- possible causing a small 'skip' effect on each system due to compromise. If compromise cannot be reached, the server will be notified. (I have no idea what it will do, though!) If positions are adjusted, then of course each node will send position updates to any other listeners.
- Frank Swierz Dan, I think this is a great idea for things like missles which are not directly under a players control (once launched of course). However, let me pose another scenario which I think was a common form of cheating in JumpGate. Let's define a situation where two players enagage in a dogfight. Player A is a good and honest. Player B is a cheater. Player B hasn't figured out how to make his ship faster, have more armor, or anything like that, but this player can simulate extreme lag at will. In JumpGate this can be done by uploading a very large file so that your upstream packets to the server don't arive in a timly fashion. Back to the Scenario. Player A and B are approaching each other head on. Gun blazing. As they pass, player B induces lag (by the method described above) before turning to fire on Player A. Because of this Player A's ship simulates that ship B is continuing on it's original vector. Ah ha, Player A uses this info the think that player B is attemping to run away. Player A then pursues player B's simulated ship. Because player B didn't affect his download stream, he continued to receive valid positional updates from player A's ship. What this means is that now player A thinks he is chasing player B and is hot on his tail. In reality player B is right behind player A. Player B stops the simulated lag and releases his upstream connection, and this causes Player A's ship to see player B's ship skip from infront of him to behind him. Player A's sim would register this as valid because based on the last known positional information, it would be possible for player B's ship to be at it's new reported position. My (long winded) point here is that it would be difficult (if not impossible) to detect this kind of cheating, but because player A's movements were based on the simulated position, he can be at a severe disadvantage in this situation. I'm not sure how we would fix this, just wanted to make sure that this kind of cheating was considered. Feel free to edit these comments out of existence Dan. :)
- More comments based Dan and Wegiz's IM conversation on the subject....
DanM: Hi buddy. Just reading yer comments on Open Client.
Wegiz says: Sweet. I didn't think it would take you very long. The crux of what I was trying to get across was that some kinds of cheating would be indistingushable from lag. I hope that was made clear by all my rambling.
DanM: Yeah, I can see your point. Haven't read the whole thing yet, but so far it makes good sense. I'm thinking about your scenario. I can't come up with a simple fix. 'course that's not surprising, who said it should be easy?
Wegiz says: Yeah, me neither. I think it's one of those solution is worse than the cure problems.
DanM: Part of how dead reckoning deals with the skipping is to smooth out the non-owned object's path, so it approaches its correct position asymptotically instead of warping.
DanM: Not sure how to reconcile that with potentially harmful player/player interactions, though.
Wegiz says: Ahh, that might help. Must grok that for awhile. I think there should be some penalities to players with lousy pings. Better than the other way around which is how it works in jumpgate.
DanM: Yeah, maybe there can be some voting mechanism for the negotiation I describe, with the votes weighted by level of interest in the outcome? Sounds hard.
Wegiz says: Yeah, voting for that sort of problem sounds hard. Especially with many laggy connections voting on the outcome.
Wegiz says: There is also the ZeroPing approach used by UnrealTournament. Which places the responsibility on the attacking clients end. Of course, then we really need to make sure no one can tamper with the client.
DanM: Yeah, the ZP approach is highly insecure. Worth thinking about, maybe there's way to make it safe.
DanM: Perhaps the votes could also be weighted by variability in packet travel time -- the more variable, the less we count your vote.
Determing Feasibility
In order to determine what's 'feasible', a local physical simulator needs to know certain things about the missile. What is its mass? What is its maximum thrust? How much fuel does it have? Perhaps even: How smart is it's guidance system? All of this information could be provided with the activation notification. However, if this information is stored locally, it is potentially accessible to hacked code. (Especially if source is distributed!) Thus this would rip away the fog of war -- as soon as an opponent launches a missile, all the vital statistics about the armament are known. A similar scenario applies with respect to another player's ship, of course.