[pythian] Re: CODE - Network
- From: "Ken Florentino" <majic.majic@xxxxxxxxxxx>
- To: <pythian@xxxxxxxxxxxxx>
- Date: Sat, 27 Jul 2002 18:29:01 -0500
I too have not abandoned this project... real life some times takes over
though... :)
My three cents (which will mirror some of what has been said).
Client data must be stored on the server (if you expect a cheat free game).
All client critical information (not-stored) must be still handled on the
server side. Thus, state machine is the way to handle movement. User presses
mouse button and client sends a "I'm moving forward now". Server gets the
mesg, then responsds with, your position is now x,y,z. Now then, this
movement only has to be sent out about 5-10 times per second, because you
can use interpolation to guess where you are going to be on the next packet
and animate smoothly. This is the exact method that games like QII and CS
use. Additionally, you can keep track of the player state (is the player
involved in combat, and for a short period after you can send faster updates
to keep the battle more precise).
In any situation that is critical, the server is the trusted authority. This
means some people will have skewed realities, but that's life until someone
makes a better internet. This happens all the time in CS when you swear you
buried a clip of ammo into someone then you die and they still have 75% of
their health. It can never be perfect, but it can be very close.
UDP is the only way to go for any sort of heartbeat or positioning. If
positioning packets are lost you ignore it and interpolate based on your
last packet (or last few). Other issues arise (such as out of order
packets), but most of those are easily taken care of by igoring them and
waiting for the next (doing interpolation inbetween).
You can also use TCP/IP at the same time for other types of commands that
won't be issued frequently. No one is going to try and use 20 healing spells
inside 1 second. The other reason to use TCP/IP is for critical packets that
MUST be guaranteed to make it such as chat messages, trading.
Lastly, for critical messages that are issued frequently, you still use UDP,
but have to write your own packet loss/out-of-order handler. The other
option is to use DirectPlay (Direct X 8). It has it's own deal for working
with UDP and it is very fast. You can specify whether you want guaranteed,
non-guaranteed messages as well as assigning priorities to each packet. It
does throttling and a whole lotta other features.
Hope this helps.
----- Original Message -----
From: "Darryl Long" <pythianproject@xxxxxxx>
To: <pythian@xxxxxxxxxxxxx>
Sent: Wednesday, July 24, 2002 1:18 AM
Subject: [pythian] CODE - Network
>
> 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:
