Re(2): Network game design (UDP)
Re(2): Network game design (UDP)
- Subject: Re(2): Network game design (UDP)
- From: Jens Bauer <email@hidden>
- Date: Thu, 27 Jun 2002 14:34:57 +0200
Hi Matt,
On Thu, 27 Jun, 2002, Matt Slot <email@hidden> wrote:
>
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.
I think it's possible to make a join/quit on the fly by going through the
server as well.
>
>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.
This is necessary, otherwise the entire "board" would have to be sent again.
This is very complicated. Especially in a World where we have time
machines and other mad inventions. ;)
>
Each host would send data at a regular interval, and the
>
server would collate these and send his data at regular intervals as well.
Unfortunately, we'd go out-of-sync, as tight timing is essential here.
Currently I can't think of any possible solution on how to synchronize
this correctly, if using a loose model.
>
A client may miss a "heartbeat" or double up, but a little interpolation
>
(smoothing) and extrapolation (prediction) can hide these hiccups.
Unfortunately not. If you travel back in time and kill a fly (something,
which doesn't appear to be important), the World will look completely
different 2000 years later. -Because someone got distracted by this fly,
and started thinking of other things when he was disturbed. This is
approx. what will happen in this game. =)
>
>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
Definately interesting! Thanks for this link. :)
>
>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.
Yes! =)
>
>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.
Hehehe, well, ofcourse, I will always sync to the slowest machine.
This was just a way of simplifying my question.
The speed of the game will vary, which may sound confusing.
You can walk around and at certain spots you are "aging" much faster, you
run faster, and in other places you run much slower.
>
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.
In fact, I may only need to send one byte of information per player.
This is very suitable for a direct modem connection, but if adding all
the UDP headers, you'll get much more traffic. ;)
>
Seriously, you need to write your game engine from the ground up with
>
networking in mind.
Yes. The game is already written for another platform, and has been
completely tested.
I find it important to make sure that I get a good low-level networking
on the Mac.
>
Design the physics to cope with latency and errors,
>
and make sure objects move according to absolute time and not each
>
graphical frame.
You could say it's turn-based, but it must be running in real-time.
-So it's not time-based, and it's not display-frame based, but you
*could* say it's frame based.
>
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.
My game is not a first person shooter game, so I doubt that I would be
lucky enough that it suits my needs.
-I would also have problems with porting the library into my game,
because my game is written completely in (portable) assembly language.
Thanks for your suggestions. I will think about if I *can* make a way of
fixing missed/lost packets.
I'm having an undo-buffer with move-prediction in mind. Combining this
with a sliding-window protocol, such as SEAlink, this might improve my
odds. ;)
But I'm not sure yet, whether it would completely solve it.
Love,
Jens
--
Jens Bauer, Faster Software.
-Let's make the World better, shall we ?
_______________________________________________
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.