Archived

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

Client and Server, conceptually

This topic is 4946 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

Hello, i''ve got a game all ready to be networked. I''m using C++ and OpenGL. I know i''m going to use SDL_net to create the server between the games. The way it''s going to work is each game can either be the server or the client. The one that decides to be the client has to connect to the server. The one that''s the server waits for connection. Pretty typical stuff. There will only be two players. But i don''t know how i''m going to do this. I know how to send and receive packets and all that low level stuff but obviously there will be lag involved. What happens if the server thinks the client is in place x and the client thinks it''s in place y? What if the client thinks it hit the server but the server thinks it didn''t? My game is basically pong with missiles and shields and stuff, i would think it should be one of the easiest games to make a client-server architecture for. But i really don''t know how to decide any of this stuff that i mentioned in the previous paragraph. Is there a tutorial out there that explains this stuff at a conceptual level for me? Or could someone explain it to me here? Thanks

Share this post


Link to post
Share on other sites
Usually when there''s a discrepancy between the client and server game states, the server wins. This is due to the fact that the server ultimately has more trust than the clients, who could be trying to cheat. Then again, if the person hosting the server is cheating, then all bets are off. But usually the server is supposed to be a trusted source. As for lag, you could try to introduce some sort of clientside prediction, which predicts what''s going to happen on the client between data messages from the server, but that can be more complicated. On the other hand, design it well and it could also serve as a validating construct if there is a dispute.

Share this post


Link to post
Share on other sites
i was thinking of doing this: The client only tells the server what it''s inputs are. The client doesn''t tell the server it''s position or direction (directly). The server only tells the clients position and states.

Any big problem with this?

Share this post


Link to post
Share on other sites
The only problem is that you''re now relying on the server to process input for all the clients. Not only is that more computationally expensive, but using UDP mean packets can be lost and the input won''t register. Also, you''d increase network load by sending more information than was needed.

Share this post


Link to post
Share on other sites
quote:
Original post by Zipster
The only problem is that you''re now relying on the server to process input for all the clients. Not only is that more computationally expensive,


How many clients are we talking about here? 1000?


quote:
Original post by Zipster
but using UDP mean packets can be lost and the input won''t register.


That goes for all UDP packets in both directions, and not just input.

quote:
Original post by Zipster
Also, you''d increase network load by sending more information than was needed.


If you want a game with less cheating then it is needed.

Share this post


Link to post
Share on other sites