[pythian] Re: CODE - Network
- From: mike@xxxxxxxxxxxxx
- To: pythian@xxxxxxxxxxxxx
- Date: Wed, 24 Jul 2002 04:05:43 -0500
About latency and pings etc, I think we should decide now what sort of
target connection we'll be looking at. Are we going to focus on
broadband only, or modems too? What sort of ping times will be required?
That's basically what the problems boil down to, isn't it? The more
lag we have, the harder it becomes to retain integrity. So we'll need
to define limits for that.
In other news, progress here at chez mike has been unfortunately non
existant as far as the project is concerned. All my time has been
sucked up with preparing to move away and start a new life down in
Malvern, as well as the 2 jobs I've managed to land myself (one of
which is doing programming). This sucks as it means most of the stuff
I'd intended to do over the summer is now on hold, but at least I'll
have some funds to get me started in September.
Don't worry, I haven't abandoned the project! I just wish I could get
paid to work on it, that'd be much simpler :)
By the way Darryl where have you been lately? I haven't seen you on
ICQ for ages.
thanks -mike
On Tue, Jul 23, 2002 at 11:18:20PM -0700, Darryl Long wrote:
>
> I've started reading and researching. So far I haven't read much I
> didn't already know, but I still feel like I don't know anything, so
> that's not good. :p Here's a link to a list of network game development
> articles:
>
> http://www.gamedev.net/reference/list.asp?categoryid=30
>
> Read what looks interesting.
>
> Here's what I've established so far:
>
> - We will use a dedicated server archietecture, meaning all data is sent
> and received from the server, never from another client. This also means
> we need a server application that is a stripped-down version of the game
> client.
>
> - We will use UDP for everything, and implement our own simple
> lost-packet-resend mechanism. A single UDP packet can not exceed 1450
> bytes. We will collect data into 1450 byte chunks before sending to
> minimize packet overhead.
>
> - We will have a "TNetworkClientEngine" which manages connecting,
> sending and receiving on the Client. Similarly, we will have a
> "TNetworkServerEngine" to manage all the clients from the server's end.
>
> - All remote characters are represented on the client with a
> "TRemoteCharacterController". Data relevant to a character is received
> and sent through the TRemoteCharacterController.
>
> - Only information about characters in the immediate area of the player
> is sent to a client. This means commands such as "AddCharacter" and
> "RemoveCharacter" must be issued by the sever when a character adds or
> leaves the area of relevance around the player's character.
>
>
> The first issue we need to resolve is should we perform a full
> simulation on the client, use a state/update system, or a server simulation?
>
> A full simulation means the actions of a character are sent to the
> client and the client simulates the actions. For instance, the player
> Joe presses the forward key, and this command is sent to the sever which
> relays the command to all the other clients. Every client's
> PhysicsEngine simulates a movement forward.
>
> A state system means Joe presses the forward key, only his own
> PhysicsEngine simulates the movement, and his updated state (in this
> case position) is sent to the sever which relays the new state to all
> the clients.
>
> A server simulation system has the server performing the simulation of
> all characters and objects in the world. Not a very good solution by
> itself since you'd need a super computer.
>
> A full simulation has the advantages of keeping all the clients
> synchronized and low-bandwidth usage. It has the disadvantages of:
> requires a lot of CPU processing to simulate everything and the
> simulation can sometimes get out of sync (due to round errors or
> latency) which completely screws up everything. A full simulation is
> risky for us because gameplay may go on for a very long time in a MMORPG
> and the probability of out-of-sync problems is too high.
>
> A state system may or may not use more bandwidth, depending on how often
> the updates are sent. State interpolation can be used to smooth state
> transitions. The biggest problem is synchronization. Joe shoots an
> arrow at Bob's head. Meanwhile, Bob ducks. An update state packet is
> sent by Bob's client to relay his crouched state. Before Joe's client
> receives this information, his client simulates a hit between the arrow
> and Bob's head (the arrow was Joe's, so his client simulates the arrow).
> Obviously the arrow missed, but how do we convince Joe's client of this
> since Joe's client was simulating the arrow?
>
> There are ways around all the problems listed above but from what I've
> read, nothing is easy. I think we will need to go with the state/update
> system because it is more scalable than the full simulation (that is, it
> can handle a lot more clients).
>
> We could use the server to validate possibly troublesome interactions.
> For instance, to resolve the example of Joe and Bob, Joe's client would
> send a message to the server saying "I think I hit Bob in the head at
> this time" and the server would perform a partial simulation to
> determine if this was possible. In this case, the server would say,
> "No, Bob's head wasn't at the location at that time, so you didn't hit
> him." That has it's own complications, but I think we need it since we
> can't trust the client to always be accurate/honest.
>
> That's all for now.
>
> Darryl
>
>
>
Other related posts:
