State - the class/structure that stores the given part of the world data, and can create a Delta, given another State.
Delta - a class that stores the difference between 2 State classes ( this is used very often in the CoH client-server communiacation to reduce used bandwidth )
Serializer - a class that can read/write either State or Delta to a Bitstream.
State - Delta design will be a little bit tricky, since for each connected client the collection of State objects will have to be maintained.
ClientState is basically a server-side model of 'What we think given Client "knows" about the map/entity/other State'. Whenever a packet is acknowledged by the Client, we need to update the server's ClientState with the acknowledged Delta/State.
I think we'll end up with a bit strange design, and I'm not at all sure this is the way to go, does this look overly complicated to anyone ?
Thinking out loud
Code: Select all
Map - Model [ Authoritative Model of the Map, updated by physics, AI, and other subsystems ] | 1 | | * Client Model [ Last client acknowledged State, the delta between this, and current MapModel is what's got to be sent to the client fairly frequently ] | 1 | | 0..* Delta [ Each of those can be acknowledged which should invalidate all older Deltas, and update the ClientModel by that Delta ] - This looks very data base'y ( 'commit' anyone ? :) )
Given the following contents of the ClientModel, when the MapModel_t4
ClientState_t0 [x=1] -> Delta_t1 [ 2 ] -> Delta_t2 [ 3 ] -> Delta_t3 [ 1 ]
When the client acknowledges receiving Delta_t2 the following things must work:
Acknowledging Delta_t3 - we must be able to 'commit' the Delta_t3 over updated ClientState_t2, even though the Delta_t3 was created between ClientState_t0 and MapModel_t3
Possible solution: when Delta_t2 is acknowledged, update Delta_t3 with negative Delta_t2 : ( ClientState_t3 = (ClientState_t2-Delta_t2) + Delta_t3)
Drawback 1: if we have many Deltas following Delta_t2, it might be inefficient ?
Drawback 2: All deltas must be reversible ( what is the inverse of 'delete entity 1' delta ?)
Sending a Delta_t4 - we need to send a new delta at time 4, we send it using ClientState_t2, what happens when the Client receives our delta, and it has just updated it's ClientState using Delta_t3 ?