Re: Multiplayer game

[ern0 <ern0@linkbroker.hu>]

> 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.
-- 
ern0.scene.plus4.amiga.code.muzak
Haben Sie Fragen?