🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

server-client or peer ?

Started by
7 comments, last by djsteffey 23 years, 7 months ago
which is the best way to set up a multi-player game ? I am thinking one of two ways the basic client-server method where I will have each client send its position data and bullets fired, etc.......to the server, then the server immediately sends the data out to the other clients. Each client sends at a rate of 10 packets/sec, so on the server side, everytime I get an incoming packet, I update the positions of the ships on the server side, then ten times/sec I send the information for all the ships back out to all the clients......(later on I will fix it where it is only sent to clients that can see each other). The other possibility I was thinking is this. Have one computer act sort of like a server, where it handles all connection requests. As soon as a connection is requested, it responds to it, assigns it a unique id number and sends it the addresses of all the other clients. Then the server sends the new client address to all the other clients already connected. Now when position data is sent, every client sends it to every other client connected, so information is sent directly from client to client rather then client-server-client and thus reducing lag chich is good. Now as the number of clients increase, this of course puts alot of strain on each clients internet connection. I am developing this on a T3 connection with other nearby computers on a T3 so the connection speed isnt an issue for me. But I would like to someday be able to distribute this so I need to make connection requirements alot lower. So which is the way to go ? classic client-server which is easier on the clients, but higher on lag.........or client-client which is easier on lag, but needs higher connection speed... "Now go away or I shall taunt you a second time" - Monty Python and the Holy Grail themGames Productions
Advertisement
The Server-Client system is normally used because the Server needs to be in control of the game state.
Because of the latency problems, the clients only have a simulation of the ''correct'' game state at any one time. They send their data back, and the Server updates it''s state, and refreshes the appropriate clients.

The way you''re suggesting indicates that no one computer is in total control, which could lead to a lot of conflicts.

I don''t think it''s possible to send ''complete'' information each frame, that''s why one computer has to be in control.
First: Remember that a 56K modem is not a symetric 56K Connection. Upstream speed only hits 33.6 max, so sending the updates more than once will quickly congest the upstream side of things.

Second: When dealing with Peer to Peer setups, there are questions about where logic goes and inconsistancies. If Ship A controled by Player A fires a bullet at and destroys Ship B controlled by Player B, what if after the event, but before Player B receives notification, Ship B shoots at and destroys Ship C controlled by a third Player C? If you thought that was confusing, just wait until you try to code for those kinds of situations. It is nasty.

I''m a big fan of Client->Server is all I think I need to say. It''s much easier to get one server with a large network connection than it is to get semi-large network connections. It''s also a hell of a lot easier to manage.

well, twoflower is right,
peer-to-peer leads to a lot of probs... and overhead. if ur game is planned for a t-3 setting, fine... but then u will have sure trouble on distributing this... client-server is a clean way, where u can synchronize more. u dont have the problem of having to decide which one is peer-server, what happens if the peer-server leaves/lags out of the game, etc.. and it WILL put not only a lot of strain on the connection, it will put a lot of strain on the peer-servers processing (cpu) too, coz this one doesn not only need to process normal game stuff, he has also to process all the server (game-state, syncing, event-handling) stuff also...

so my advice is go for client/server, u will get the most out of it, and peer-to-peer isnt even easier to code...

Ice.
so i am guessing the server-client is the method i will use then.
another question.....
Should I have the server completely separate from the game ? Say I want to run the server from my computer and I also want to play the game from my computer. Now can I run the server and the game in one program ? Or should I have the server and the game running from different programs and just connect to myself ?

another question......
i am sending position update packets 10/sec
i have a max firing rate for each ship around 6/sec or so
how should the finring bullets data be sent. Should everytime someone fires, a data packet separate from the position packets be sent, or should I include it in the position packet and how ?



"Now go away or I shall taunt you a second time"
- Monty Python and the Holy Grail
themGames Productions

i am just getting confused with this now....
i guess I am going to go with the server-client model

can someone suggest what the client should do and what all the server should do

here is another problem I have and was needing some help with.
when a player fires a bullet, it is displayed on his screen and a packet is sent to the server telling where the bullet was fired from and the x-y velocities. The way a collision is determined is this.....when the server/player recieves the fired packet from the other player, it is initialized and displayed on there screen, and from then on, its position is interpolated using the velocities. And if the enemy bullet hits your ship on YOUR screen then a collision is registered and a collision occured packet is sent to the other player letting them know you got hit so they can display the explosion as well.
But of course this presents major problems (as I have seen). when you are shooting at someone, it can appear that your bullet goes right through the player without hurting them b/c of lag. B/c you see on your screen, where the player was X milliseconds ago. and the bullet you fired really appeared on their screen x milliseconds after you fired it............what to do ?


"Now go away or I shall taunt you a second time"
- Monty Python and the Holy Grail
themGames Productions

Have the server perform all of the hit/miss calculations. You send off a trajectory w/ a timestamp *perform some sort of calculation when the clients connect to synchronize time*... and let the server determine those things. You can use a type of prediction on the client to display the correct effect and pre-determine the hit/miss of the shot.

As for seperating the server from the game... A few things I would look at are:

Will people be playing the game single-player without a real client->Server setup? Will they be able to run their own servers? What kind of requirements will your server have? I know you can''t answer all of those until you get a better idea of where your logic will be.
the way i am looking at it now, people will have to connect to a server to be able to play the game. As i wont let the game proceed until the client has made a connection with and the server accepts the connection. People would be able to run their own server if I give them the server .exe. The requirements for the server really depend on what it is going to be doing and how many people are connected. At first I am thinking of no more then 8 people per server, but a usualy of 4 or 5. But a game with just two could be played.
and about the time sync and prediction is this what you mean.
say at time 1000 the server sends a packet that a bullet was fired at 10, 10 with velocities x = 100, y = 100
now the packet arrives on the client at time 1200 (200 ms later)
i shouldn''t start the bullet at 10, 10 but instead i should start it at 30, 30 (which is the starting position + velocities*timeElapsed)
is that what you mean ?
should i do that for ship positions as well ? It seems that if I did something like that........I think that sometimes it would appear that bullets appeared out of mid air........maybe i am missing something still.

BTW......i have already begun to code the server which isnt really that bad. It now runs asyncronously and accepts connects and is able to send data between clients (all since last nite)


"Now go away or I shall taunt you a second time"
- Monty Python and the Holy Grail
themGames Productions

Players should updated on the screen in a similar way as the bullets. Any given client should know that at a time t, player A was at x,y and traveling at dx,dy. You need to sync the time between the clients and the server, so that all the velocity extrapolation works out right.

The really bad thing about sending data from each client to each client, is that the network load on every client increases with each additional client. With a client/server approach, only the server has an increased load.

Edited by - Magmai Kai Holmlor on November 20, 2000 1:12:06 AM
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

This topic is closed to new replies.

Advertisement