[pythian] Re: CODE - Network
- From: "Ken Florentino" <majic.majic@xxxxxxxxxxx>
- To: <pythian@xxxxxxxxxxxxx>
- Date: Sun, 28 Jul 2002 23:26:46 -0500
see comments interspersed below...
----- Original Message -----
From: "Darryl Long" <pythianproject@xxxxxxx>
To: <pythian@xxxxxxxxxxxxx>
Sent: Sunday, July 28, 2002 5:05 PM
Subject: [pythian] Re: CODE - Network
>
> Hi,
>
> Thank you Ken and Andy for the helpful comments. I'm glad you two are
> still around and interested in the project.
>
> Based on what you wrote I am sure now that the server must simulate
> everything. Knowing that other games have taken this path helps as
> well. It also shows me why people always say that you must design your
> game as a network-enabled game right from the beginning, and not add
> multiplayer as an afterthought. Fortunately, I believe our engine is
> quite capable of handling multiplayer.
>
> I will refer to the messages we send between the client and server, for
> movement and such, as "state messages". These will include position,
> velocity, acceleration, rotation, rotational velocity and rotational
> acceleration.
>
> This is how I imagine the communication working under our architecture:
>
> - The player presses the forward key
> - The client sends a message to the server saying "I am moving forward"
> - The client's PhysicsEngine simulates the movement forward
> - The server receives the message and simulates the movement forward in
> its PhysicsEngine
> - The server sends back an updated state
> - The client adjusts its state to match the server
one addendum to this. the client and server would need to both anticipate
lag so that the client doesn't have to wait for the server in order to start
moving. In other words, here is what I see...
a) The player presses the forward key and begins moving forward IMMEDIATELY.
b) The server receives the "i am moving forward"
c) The server knows that the client has about 200ms latency so he
anticipates how far the client would have moved by the time the server has
received and replied and updates the position accordingly.
d) The player receives the position and adjusts accordingly. Since he was
already moving and the server was smart enough to pay attention the average
latency, the player notices no sort of "teleport" because the discrepancy
between where the player actually is (server authority) and where the player
is currently is minor.
another important aspect of this movement is that it needs to be time based
and not frame based. A player moves X units per second. That way, the
renderer which constantly refreshes at whatever FPS, doesn't interfere with
movement. A person with very low FPS would see jumps in his movements,
whereas a player with high FPS would see smooth movement... as it should be.
>
> For other players within range of this client, the server will simply
> send state messages and the client will simulate their movement in its
> PhysicsEngine.
>
> I see an easy opportunity for cheating. It would be easy to hack the
> client so that other players and NPCs are visible through walls. I
> could do it in about 1 line of code, actually. I think by having an
> open source multi-player game we are setting the world of anti-cheating
> games back by about a decade. Oh well :/
There are variety of ways to prevent this. One of the simplest is to
calculate if you can see the player on the server side and only send the
position of the enemy if it can be seen by the player. Obviously this
requires more processor power, but server operators are used to having to
have high-end boxes for their servers. In fact, they go as far to boast
about how powerful their boxes are.
Other important aspects to cheating are compressing/encoding the game
packets, using CRCs, sequence numbers, etc. Some cheats revolve around
packet sniffing the packets and replaying them (or modifying them slightly
then replaying them) as well as IP spoofing. There must be an effective (yet
simple and lightweight) method of authentication. This obviously can be put
in later, but something to consider eventually.
>
> Darryl
>
>
>
Other related posts:
