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?
--
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 http://vger.kernel.org/majordomo-info.html
