Re: Network game design (UDP)
Re: Network game design (UDP)
- Subject: Re: Network game design (UDP)
- From: Matt Slot <email@hidden>
- Date: Thu, 27 Jun 2002 03:15:02 -0400
Jens Bauer (email@hidden) wrote:
>
I have 2 models:
>
>
A: One server, a bunch of clients.
>
B: Each client also has a built-in server.
>
>
The advantage of (A) is that it is easy to implement.
>
The advantage of (B) is that a number of bytes can be saved, if 2
>
computers are on the same LAN.
A dedicated server will be more secure and simpler to code, but putting
all the server logic in each client will let players join/quit on the fly.
>
Say we have 8 clients and one server:
>
1: Each client sends its "move" to the server.
>
2: When the server received all 8 moves, it sends the 8 moves to each
>
client.
The server shouldn't wait for all 8 moves, since packets will often be
lost or late. Each host would send data at a regular interval, and the
server would collate these and send his data at regular intervals as well.
A client may miss a "heartbeat" or double up, but a little interpolation
(smoothing) and extrapolation (prediction) can hide these hiccups.
>
My question is:
>
Should I go for the easy solution, which is a separate server, or would
>
it pay to go for the model, where I have a server built into the game
>
itself ?
It's an important trade-off, and really depends on the nature of the game.
You have also glossed over another distinction, which is the separation of
network topology and game authority. I touch on such things in articles at
my website:
http://www.codewhore.com
>
I worry about lost UDP packets as well.
As well you should. For most cases, 1-2% packet loss is normal, but you
can find networks of 5% loss or even spikes to 20%. Adding a reliable
layer on top of your UDP engine is a must for Internet play.
>
I don't know the exact size of a UDP package, but let's assume it's 16
>
bytes. For 8 players, this would be 16 + 2 + 1 + (8 * 2) = 35 bytes per
>
frame, and if we have 60 fps, we'll get a minimum cps-rate of 2100, which
>
means we'd need 21000 baud in case of no errors.
Never, EVER send a packet per graphic frame. You'll flood yourself off the
net, and be shunned by network admins the world over.
A reasonable number of packets for a fast-paced Internet game is 4-8 per
second. You can gather and send state changes (fire weapon, capture base),
along with status updates (at position 20,20 with speed x, orientation y),
and use interpolation to smooth out the animation.
Seriously, you need to write your game engine from the ground up with
networking in mind. Design the physics to cope with latency and errors,
and make sure objects move according to absolute time and not each
graphical frame. Only after you get the engine working should you try to
layer graphics on top of it.
>
-So... Is it worth the trouble supporting networks behind modems, or
>
should I assume that noone is using PPPoE for gaming ? :)
Modems offer crappy bandwidth and even worse latency. However, the only
way to determine whether your game will work over them is to actually try
it in the real world. You need to play test your engine so that you can
find the right balance between network traffic and smoothing/prediction.
Some games or network designs will be amenable to modems, others simply
will not.
Finally, let me suggest you also check out OpenPlay. It's an open source
network game engine that handles most of the gory details for you. There
are alot of smart people working on it, and you'd be hard pressed to beat
it on your own.
Matt
/* Matt Slot, Bitwise Operator * <
http://www.ambrosiasw.com/~fprefect/> */
/* "I never let schooling interfere with my education." -- Mark Twain */
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.