Server Hosts
Blitz3D Forums/Blitz3D Programming/Server Hosts
| ||
| So I've been pondering on how servers work. Basically I am going to be making a game with a listen server, then possibly add a dedicated server. My question is what exactly does the host do? So far I have them able to show their server on the lan menu, and when new players connect, it will send them a list of who else is already in the game. When it comes to the actually game, do all of the players send their position info to the server only and then the server sends it to the rest of the players, or do the players send it between each other and the server picks it up as well? |
| ||
| Player position data with a dedicated server would go player->server->player - the dedicated server means that people don't need to mess about with opening ports on their router to be able to connect to other players directly, etc. (and in theory means the game isn't affected by any one player's connection being rubbish). Normally you'd have the clients updating the server at say 20Hz and the server do a world update every say 10Hz and send out the latest world state to connected players at that frequency. Gets a bit more complicated after that in regards to what sort of game your working on and what methods best suit it to keep everything in sync but normally individual clients would run clientside prediction ahead of the server. |
| ||
| Perhaps this library is interesting to you(I think it is) and especially the bit with "Download: SimpleUDP 3.0 inkl. Masterserver". Original German link: http://www.blitzforum.de/forum/viewtopic.php?t=37472 As it is in German you may want to use a translator on the above link, as in here: http://www.microsofttranslator.com/bv.aspx?from=&to=en&a=http%3A%2F%2Fwww.blitzforum.de%2Fforum%2Fviewtopic.php%3Fp%3D410348%23410348 Works great on my home network. |
| ||
| Normally the server would send information to all the players -- player to player is hard, because most of the time the players will be behind a firewall and you won't be able to make a direct incoming connection to them. Having the clients themselves initiate an outgoing connection to the server that they can receive information back over bypasses all the router/firewall problems. Something else to consider: keep in mind that you can't really trust the client computer. The server should have some logic built in to verify that the information it receives is actuall possible in the game: units moving faster than their max speed, # of bullets fired don't exceed a max, number of enemy deaths all add up as well -- without those doublechecks, a player who intercepted & figured our your server communications could easily make a cheater that ruin the game experience for everyone else. |
| ||
| Hey, I want to thank everyone that posted, the amount that I learned from this is crazy. Just a couple quick questions about the world "tickrate" Rroff, I suppose when you are saying the server would make all of the calculations at 10Hz, that means a tick every 10 milliseconds? So then to elaborate on that, the server makes 100 world updates a second, while the client makes 50? So that wouldnt actually limit the players fps, they can still have max fps however the data is only being sent every 20 milliseconds, or so I understand. Would this limit framerate at all, or would you just tell it to send all the info after a certain time? Again, thanks for all the help everyone, this is extremely helpful. |
| ||
| I also just watched a video on server ticks, and saw that most of this applies only to online gaming. I am starting out with lan first then working up to online. Does this change how the server ticks? Since there is no latency, does the world need to be updated in the same way? |
| ||
| I am starting out with lan first then working up to online. Does this change how the server ticks? Since there is no latency, does the world need to be updated in the same way? Generally, on a LAN you have insignificant latency: 1-2 ms. That means you can send/receive LOT of network update packets , and have nbear real-time responses. On the internet, you can have response anywhere from 10ms to 200ms for users on the same continent, and more for thos furrther away. Obviously, that means that whatever network info you receive can be a quarter second out of date anyway, and you'll probably have to use some predictive algorithms to deal with player positions, weapons, damage, delayed deaths, etc -- of a unit is running, you can typically expect them to keep going in the same direction at that speed, but when you receive the network packet with the *real* position, you'd have to adjust for that. (either average the guessed/real positions for a somewhat smooth movement, or jump to unit to its real location -- but doing that can get pretty 'jumpy'. Gernally it takes a bunch of predictions, mixed with the real info to get a visually smooth result. Unfortunately, that also makes it much harder to determinte whether someone has been 'hit' since the unit may -appear- in a different location to an enemy than where the actual player thinks he really is. It's a tricky problem, but if you ignore it you can significantly degrade gameplay fun and 'fairness' on slow networks. On a LAN, it's probably a non-issue for the most part. |
   |