[pythian] Re: CODE - Network
- From: Andy <andreastropschug@xxxxxx>
- To: pythian@xxxxxxxxxxxxx
- Date: Sun, 28 Jul 2002 11:50:27 +0200
Hi,
little comment on the networking discussion:
In CS I remember to have a Commandline option to set if the server should
do hit calculations or the client. That's for optimizing your hit-accuracy.
If you want to be dead-sure to kill that but you can order the server to do
everything. If the shots are calculated by the client, you could never be sure
to
really hit the guy, but it has the advantage to stay smooth..
But the control, as Ken said, stays with the server, the client calculates for
himself and sends packets to the server. The server calculates the same
things, and sends back Info from the surroundings and tells you if you are hit
and with a certain frequency you get position updates. So you pop arround if
the server calculated something different than the client.
Maybe we could do a similar mixture?
People with bad connection will rely on their client to give them smooth
gameplay, the others will give the control to the server. At least they can
choose which evil to take :)
I think in massive multiplayer you must always let the server control
everything, even if cheating would be no concern. Syncing clients with their
different cpus, net-speeds, system loads, ... Operating systems... and so
forth and so on. I think there's no alternative.
The server:
Could you do kind of a a distributed server system?
Just thoughts,
Andy
28.07.2002 01:29:01, "Ken Florentino" <majic.majic@xxxxxxxxxxx> wrote:
>
>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:
