Re: Multiplayer game

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


since I am not a good C programmer

1. It's the smallest problem, wheter you're familiar with C programming or not.

A multiplayer game has several property, which are hard to implement each, and even harder to implement together. They are:
- managing a common scene wich is controlled by asynchronous user events;
- setting up communication infrastructure between a server and at least two clients;
- everything must be pretty quick.

2. Sockets: if the game is designed for LAN, socket is OK. But if your players are using internet, HTTP is a better choice - you can't sure that your players' firewall will enable using UDP, but HTTP is always enabled. It has overhead, and a bit harder to implement.

3. Sync

Also how
can I make the movements of each player atomic since I don't want the system
to interupt one of the player and when it allocates the CPU back to it the
other players have already been moved when the first player had to move
before them.

Yep, you're right, you've found it: it's the most important problem of the multi-user worlds. The solution is not trivial, but it's not rocket science, and I assume there're lot of good documentations on the net in this topic.

The problem is, that say, two players are pressing fire button at the very same moment, but both of them can see that the other player was launching the rocket a bit later than other player. That leads to chaos.

The solution is:
- time sync and
- message queuing.

Time sync: the server and each client (player) as well must have a clock, which are syncronized. It will be quite useful, see below.

Message queuing:
- When a player takes any action, it musn't be handled by the client immediatelly: the event just has to sent to the server. - The server receives and queues the events arriving from clients. The most important: the server assigns a time stamp for each event. The value of the timestamp is some millisecs ahead (it must be enough for sending the message back to the client). - The server sends the appropiate (soon upcoming, useful for the receiver client etc.) events to the clients (even ones which are generated by the same client, they just get back their events with timestamp). - The client receives events, and performs the appropiate action, but not immediatelly, they're firing the action at the moment, which is described in the event's timestamp. - If the time is synced between server and clients, all actions will be performed on each client at the very same moment. Because all clients are running the same code, and all clients has the same data (position of players etc.), every client will do the very same. - It a client can't perform the event in-time, it must be download the actual scene state from the server.

And it's just the top of the iceberg.
Haben Sie Fragen?

To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Index of Archives]     [Linux Assembler]     [Git]     [Kernel List]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [C Programming]     [Yosemite Campsites]     [Yosemite News]     [GCC Help]

  Powered by Linux