• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Network game design (UDP)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Network game design (UDP)


  • Subject: Network game design (UDP)
  • From: Jens Bauer <email@hidden>
  • Date: Thu, 27 Jun 2002 03:26:16 +0200

Hi all,

I have a question about how I should design a network game, which is not
turn-based (but close to, as it needs to be in sync).

I have an approx. idea on what to send, and I'm thinking about using UDP:

16 bit: cycle number. (increments for each display-update, and everyone
will synchronize using this)
8 bit: number of players
8 bit: player 1 ID
8 bit: player 1 data
[n bit] extra player 1 data
8 bit: player 2 ID
8 bit: player 2 data
[n bit] extra player 2 data
...
...
...
8 bit: player n ID
8 bit: player n data
[n bit] extra player n data

I'd most likely need some kind of "checksum" (eg. CRC) as well, so I can
see if the packet has been received OK.

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.

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.


If we have a built-in server in each client, and we have the following setup:
Client A and B are on the same local network, they are connected to the
internet via a modem.
Client C is connected via ADSL, so it's "fast".
Client D and E are on the same network, they're connected to the internet
via ISDN.

A can send its move to B, which "joins" the (UDP) packets into one, and
thereby saves sending the UDP header twice.
It also saves sending the cycle# twice.
When B receives the "result" from C, it passes on the received data to A,
so that the modem does not have to deliver the same data twice.


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 ?

I worry about lost UDP packets as well.

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.
If using a 56k modem, you usually connect with 43kbaud, so let's assume
we'll always get a good 38k4 connection.
38k4 would be just enough if each game has its own client, but wouldn't
be enough, if using one server and 8 clients.

-So... Is it worth the trouble supporting networks behind modems, or
should I assume that noone is using PPPoE for gaming ? :)


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.

  • Follow-Ups:
    • Re: Network game design (UDP)
      • From: Eric Gundrum <email@hidden>
    • Re: Network game design (UDP)
      • From: Matt Slot <email@hidden>
    • Re: Network game design (UDP)
      • From: Chilton Webb <email@hidden>
  • Prev by Date: Re: ARA Pre v4
  • Next by Date: OT Leaks Memory?
  • Previous by thread: Re: ARA Pre v4
  • Next by thread: Re: Network game design (UDP)
  • Index(es):
    • Date
    • Thread