Hi! I got a network collision problem, client - server, hope someone can help me out: Each player control a small ship that can crash into walls. When a player craches he should lose some life/hull. The server should calculate the amount of damage each player suffers and send it to everyone in the game - so far so god. If the server has low fps and the client is ahead of the server then the client can manage to crash into a wall before the server has calculated it. The client should then bounce of the wall and send a crach message to the server saying "I crached into this wall, add damage to me!". Durning the time it takes for the clients crash message to reach the server, the server might allready have calculated a crash for that client and sent damage to the clients. Then when the clients crash message arrives.. that client will recieve double damage, not that good The only solution I can think of is adding a counter to each crash message and keep track if the message is older - discard it. Seems like a bothersome solution -----------------------------
Sometimes a Guru meditation must be followed by a Vulcan neck grip.

Your client shouldn''t send a crash message, he should just predict a crash (and damage).
When the server see the crash he will send a crash message with the real damage.
Your client can then see if his prediction was right. If yes everything is fine, if no then the client should repredict his position/health using the server information.

As a general rule in client/server games you should assume that the client predicts thing and send his state to the server, the server decides on clients real states and sends them back, the server is always right.

Hope it helps,
Kucek

mm, that is probably the best way of doing things..

But I still got a problem. If the client crashes before the server and he adds damage to himself and changes his speed/direction and sends it to server.. then the server would recieve the new speed, and if the server recieves it before he sees the player crach into the wall and changes the clients direction based on clients movement.. then the crash will never happen on the server, the client might just turn before he would hit the wall (I've had this problem before..).

I just go with my simple solution (it's a simple game ) Players only add damage to themselves (server also). If someone else crashes they will bounce of the wall. When a client localy craches into a wall, he says to the server, "add damage to me". Server recieves the message and adds the damage and sends it to all the clients. Bad idea but it works aslong as nobody hacks my exe hopefully no1 will hehe.

-----------------------------
Sometimes a Guru meditation must be followed by a Vulcan neck grip.

[edited by - Herr_O on April 18, 2002 5:41:09 AM]

The client won''t send the change in direction after the crash, since that''s part of what is being predicted. Once the server send the new direction after it sees the crash, the client might need to adjust itself a bit...

---

codeka.com - Just click it.

As Kucek said the server should control damage, but it should also control the "real" speed so you can''t just let the client do that for you. The clients should predict what the game looks like, but always let the server decide what is right or wrong. Because otherwise you''ll be in a lot of trouble when it comes to synchronizing the clients and against client cheats (though small games rarely is a target for hacking).

My point is: let the server control all movement and physics and constantly send packets to all clients telling them about everybody''s positions and states. The clients can predict collisions, but never do anything about them... sort of speak

All this is more easily said than done :o ugh I''m not getting paid enough! (actually nothing at all). Maybe ill fix it later, hmmm..

Why not use the distributed computing method?
This method does not use the concept to a central server sending updates to a client, rather it relies on the fact that each client calculates it's own movement and reaction while sending this state to other client that are interested in the data.
Using this method means that each client isn't lagged by having to have the server get data and then wait for responses.
I would not recommend the method where the server calculates all physics and updates.
If you want an exmaple of a distrubted system like the one I describe then have a look at:
http://www.replicanet.com/
It's a little something I've been working on at home the last few weeks.


Martin Piper
Argonaut Games plc.


[edited by - fnagaton on April 18, 2002 7:34:33 AM]

Yeah, you''ve really got to plan for these situations when you start, it''s really hard to retro-fit a good prediction system onto an already running game

As long as it works for now, it''s probably good enough. Just keep in mind for your next project...

---

codeka.com - Just click it.

The problem with the distributed model is that it can cause problems on larger scale (more players) for people with low bandwidth, as it''s a peer-peer system, so the client has to send multiple copies of it''s data to each computer that''s interested, instead of the single packet to the server.

I hate peer-peer systems, as I''m connecting to the internet through a firewall/server.. so there isn''t a good way for people to connect to my machine (or for me to connect to someone else behind a firewall/server). This is the case at work and at home for me, so things that rely on peer-peer become annoying :D.


Billy - BillyB@mrsnj.com

ps. A quick hack, would just be a simple counter like you said (one that holds the # of crash that you''re on), so if they crash, you can check if it''s the same crash you just figured out. VERY simple, plenty fast enough, and very easy to implement in your games current condition. Although, for your next game, you may want to just let the server handle everything like everyone else said.