Archived

This topic is now archived and is closed to further replies.

Client <-> server collision problem

This topic is 5745 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
I suggest that the client to send to the server just user input controls status, not changes in position, speed, etc. The server should handle the input and send back to server the pos, speed, etc...
The client eventually can do prediction of what the server will send, but should not send back to server the predictions...

Hope you understand this.
Pet.

Share this post


Link to post
Share on other sites
Thx for the replies everyone.. but I can''t modify everything now that I got it working feels like doing the entire project allover again. Maybe if all fails with my simple approach I''ll do the changes and only send user input from client..

Share this post


Link to post
Share on other sites
I''m aware of the problem with distributed models with multiple messages and problems with firewalls. That is why I adopted my own varient on the scheme where the underlying XPSession class. This class deals with maintaing the network session.

The class nominates at least one session, which is usually the one creating the session to start with, to be a packet router (in effect a server for messages). Connection to this session is not a problem for firewalls becaue it can be thought of as a normal client to server connection. Even if one peer fails to connect directly to another peer due to problems with a firewall then messages still get through as they get routed through the nominated packet router session. So this beats the normal problems you have iwth firewalls and distributed systems.

The other problem that was mentioned is sending messages to multiple machines. I solved this problem by also having the nomited packet router able to accept messages for groups of peers and to sort and process broadcast messages. This beats the problem of producing more bandwidth than normal. A session can send one message to the packet router and then this message gets broadcast to the specified list of sessions.

So really the system I engineered doesn''t have the problem with firewalls or multiple message bandwidth while maintaing the advantages of a distributed system.

Thanks for bringing up those points though. It''s good to know other peoples thought processes.



Martin Piper
Argonaut Games plc.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
But if you have a "nominated packet router" how is this any different (with regards to latency) than using a client-server connection. I''d also be interested to know what sort of game you are using this system for, i am guessing it is either not real-time (then why would you worry about latency), or it is a game where it is the exception, rather than the rule that a client would need to know about more than one other client at a time...

Share this post


Link to post
Share on other sites
The difference comes from the way packets are routed around the system. Each machine can try to use a direct connection to another machine or use the backup method of routing through a router session if the direct connection method fails. Basically the fastest and most reliable route for packets is used in preference to longer routes.

The games I'm currently testing this on are a flight sim type game, a car racing game and a first person shooter. Latency is a really big problem for these types of game so that is why I chose this method of bulding a network session as it works better than a straight client-server arrangement.

At the network layer each session definitely has to know about the other active sessions in the game. At the game object level everything is referenced by using the ReplicaObject class which doesn't need to know about which session it came from. In the simplist form each obejct in the game is controlled by the object that allocated it and this object automatically pushes updates to every session that may need an update for that object.

This process of pushing updates to the client is automatic so the game writier doesn't have to worry about when or how to build data packets to send.

For the types of games mentioned above this method is a lot more efficient on network bandwidth and also processor time than using a normal client-server model.


[edited by - fnagaton on April 19, 2002 6:05:46 PM]

Share this post


Link to post
Share on other sites
Ok hi again.. I''ve modified the network so that the server sends out clients positions and speeds (clients send only input). But now I get alot of latency problems for the clients. They do a small jump every time they recive the real positions from the server. I thought I could correct this small jump by adding speed*playerlatency to the position that the server sends. The position that gets sent would then look like this:

sendpak->position=(serverposition+speed*playerlatency);
sendToClient(sendpak);

But I didn''t see any diffrence, still jerky movement Is this right or should I be doing something else?

thx!

Share this post


Link to post
Share on other sites
Are you remembering to take in to account the time difference from the client sending the input to the server?

Share this post


Link to post
Share on other sites
yes I am (using playerlatency*2). The client seems to jump forward when it recieves a position I''ve tried both with and without *2.

Share this post


Link to post
Share on other sites
Don''t forget to account for latency when the client send it''s input data. By the time the server gets it, the client would have changed positions playerlatency units ago.


codeka.com - Just click it.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You need to correct for the latency between the client and server. You''ll need a more accurate timmer algorithim, such as NTP. Look on www.codewhore.com for all the informaiton you''ll need.

Good Luck

-ddn

Share this post


Link to post
Share on other sites
One thing I always do when writing any networking app is to have a unified time system that is shared between all machines. This system is quite easy to set up because each machine can send a series of pings to find out the latency over a connection.
Once you have machines that are able to report the same synchronised time, down to a couple of milliseconds, then lag compensation becomes a lot easier as you know who sent messages when.


Martin Piper
Argonaut Games plc.


[edited by - fnagaton on April 21, 2002 10:43:07 AM]

Share this post


Link to post
Share on other sites
NTP seems to be a little bit overkill for my app.

Dean Harding, I don''t move the player until I get an answer from the server.. so I shouldn''t have to account for that delay.

I''ve also tried interpolating the client side between the servers true positions and the clients predicted positions, but I couldn''t make it work. But this shouldn''t even be acquired since the latency on the network is only about 5-15ms. I''m considering going back to my old simple network that the clients send positions to the server.. It''s stupid but it looks alot better, no jumps or jerky movement. If I go back to the old routine i''ll add a server check when it recieves the positions and see if they are correct to prevent cheating.

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

Share this post


Link to post
Share on other sites
Hmm I just had a thought. Are you using a TCP or UDP connection?
My thinking, if you are using TCP then you may be getting all of your packets coalesced which would produce an effect that looks like jerky movement.
It might not be this at all but without looking at all of the code I can't really help more.


[edited by - fnagaton on April 22, 2002 5:08:27 AM]

Share this post


Link to post
Share on other sites
Im using dplay (doh) both guaranteed messages and non gauaranteed, mostly non guaranteed.

Share this post


Link to post
Share on other sites