Have a client server game, need to update realtime position. Should client send position to server and the server then on a scheduled timer send location data of all objects/players to clients to all clients? think of multiplayer asteroids as an example, what logic for the client and server? -Soulice

1) The client takes the input and moves the ship. (Does collision detection, too, etc.)
2) The client takes the current position and velocity and sends it to the server.
3) The server checks for collisions and for "is this new position in the realm of possibilities" based on what the last packet said and when I received it (have a maximum distance relative to time that the player could have moved). This prevents the client from being hacked and teleporting all over the place. If the server disagrees with the client, it tells the client to move back to its last position (or whatever). Otherwise, it sends an "okay".
4) The server sends all the other clients the position/velocities of the client the server just processed.
5) All the clients receive this data and project based on the velocity where each ship will be moving until it receives another packet...

Anything I missed?

-----------------
The Goblin (madgob@aol.com)
-----------------
"Before critisizing somebody, walk a mile in their shoes. That way, when you do critisize them, not only will you be a mile away, but you''ll also have their shoes!"

Your server and your clients SHOULD be multi-threaded.

on the client side

one thread running the game (input,sound,graphics,calc)

one thread checking ports for incoming data

note: you could have a whole bunch of threads for the client
like a thread for windows msging, one for network, one for input, etc.

on the server side

one thread monitoring net traffic, checking for data and sending data from a queue

one thread doing calculations and updating the "out" queue and processing information from the "in" queue.

this could be done with one thread, but with Lots of packets, alot will be dropped if there is alot of commincations back and forth (in the case of fps or anygame with more then 8 or so clients)

As far as when to send data, don''t schedule, only send when reality changes. Well, only when stuff changes that is relevent to the player. If it''s an rts game, you''ll want to send bascially all changes, even if you can''t see a unit dosen''t mean it can''t hurt you, but if your doing an rpg or fps (like tribes) only send data about other players near that player. All of this is based on what your doing, and it might be a good idea to broadcast a global update, or packet(s) that update the client to the entire world even if it dosen''t effect them. Rember, any data you send can easily be picked up by the client and hacked so they can see things not intended (say like the view entire map hack in starcraft) so limiting data has some advantages, but not to a point where you don''t see anything move.



this is one way of doing things, I would recommend sending data based on a units momentum, and there xy cords, so that the client can predict a units location even if it loses a beat with the server. But that means reliable physics and not alot of speacil cases, which can be hard for a starting programmer(s)

First of all, you don''t really need all those threads unless you''re going to run a a server that needs to be scalable (i.e. MMO on multiprocessor machines). They may be nice if done well and might even make some things easier (although they _will_ make some things harder, due to locking), but there''s certainly no inherent need for them (outside scalability reasons of course).

Secondly, in a client<->server context, the server MUST be authoritative. In other words, the clients may run some predictions, but the server always has the final say.

Only send information about objects that are near the player, or otherwise affect the player. Only send information when something has changed. There''s no need to send data about objects that are in constant position/movement/acceleration.

The situation is quite different in peer<->peer setups. In those, you have to do some trade-offs of knowledge cheats vs. rule cheats.

You might have all peers trust each other. In that case, one might easily break a rule (e.g. move too fast).
On the other hand, if the peers are distrusting, and recheck on everything the other peer says, players may reveal additional knowledge (such as map information).

Since RTS were mentioned: In RTS, you usually have a peer<->peer setup (there is no dedicated server). They usually only send player commands, and all the PCs run the entire game simulation, mainly because rule cheats are worse than knowledge cheats, and also because the available bandwidth is simply not enough to send information about all units in the game world.

cu,
Prefect

One line of sourcecode says more than a thousand words.

thank you all, some fantastic info. now if any of you know java???




-Soulice