Jump to content
  • Advertisement
Sign in to follow this  
Icefox

Client/server architecture decisions

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

Greetings! I am making a multiplayer, top-down space-shooter game. While I am fairly familiar with network programming, it is mostly in the context of doing interesting things with existing systems and protocols, and I really don't have much experience with designing entirely new systems. So, I'd like some advice on how the thing should be designed. This is NOT an MMO game, there will be maybe 16 players at a time. However, levels will be fairly large, and quite a few objects (up to maybe 1000) could be flying around at one time. So, my question is basically, what do I do on the server and what do I do on the client? I recall that everything should be calculated on the server, for security, and that leads to the pretty simple model of just having the client be a display, taking all it's data from the server each frame and not doing any calculation of it's own. However, even if the server only sends the client information on nearby objects, trying to do that 30 times a second... well, that will take a LOT of bandwidth. The first two optimizations that come to mind are this: One, don't send the data to each client 30 times a second. Instead, each client does some of the calculation on it's own, and sync's it's data with the server when it gets the chance. However, this would make the client MUCH more complicated, and having the client and server get out of sync could be a problem, since the game is pretty fast-paced and skill-oriented. Two, only have the server send updates on a few of the objects at a time... so all the objects close to players would get updated 30 times per second, but some stray rock floating out away from everyone will only get it's information sent to the clients 3 times per second. Any advice? Suggestions? Criticism? Am I moving in the right direction here? Any specific places I should be looking for documentation, or shall I just keep browing gamedev.net for appropriate bits and pieces?

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Icefox
Greetings! I am making a multiplayer, top-down space-shooter game.


Greetings! I like spaceshooters. :)

Quote:
So, my question is basically, what do I do on the server and what do I do on the client? I recall that everything should be calculated on the server, for security, and that leads to the pretty simple model of just having the client be a display, taking all it's data from the server each frame and not doing any calculation of it's own. However, even if the server only sends the client information on nearby objects, trying to do that 30 times a second... well, that will take a LOT of bandwidth.


It really boils down to how much precision you DO need. In many fast-paced online games I've played, movement/positional updates only come about 3-4 times per second. That might sound like a longshot from 30 times per second, but players can't maneuover too much in 250ms. ;)

Quote:
One, don't send the data to each client 30 times a second. Instead, each client does some of the calculation on it's own, and sync's it's data with the server when it gets the chance. However, this would make the client MUCH more complicated, and having the client and server get out of sync could be a problem, since the game is pretty fast-paced and skill-oriented.


Try sending (in your movement/positional packet) the X/Y(/Z) of your player/object and the direction that it's heading in. That way the client will assume the player is continuing in the same direction as he was when it received the packet -- in many cases, the players does move in the same direction anyways. ;) Then when you get the next packet of data about that player/object, correct its position by some subtle method, like quickly sliding the entity over to where it should be, which shouldn't be too far off. They shouldn't be able to get too far in 250ms!

Quote:
Two, only have the server send updates on a few of the objects at a time... so all the objects close to players would get updated 30 times per second, but some stray rock floating out away from everyone will only get it's information sent to the clients 3 times per second.


As I said above, you can get away with significantly less. Objects in the direct vicinity of the player could work fine with 3-4 updates per second, and objects way out and not ever near the player would only require 1 update every 5 seconds or longer. The keyword is 'change'. If something doesn't change or its change isn't relevant to the client, then don't bother updating it. Be as vague as possible. :D

Quote:
Any advice? Suggestions? Criticism? Am I moving in the right direction here?


You're definitely moving in the right direction, you just need to be a bit more packet-depriving. :P

(Keep us posted on your game's status: I'd love to take it for a test drive when you get something function going!)

Share this post


Link to post
Share on other sites
Fast paced game?? Not sure what you mean by that???

Using state prediction is not dictated by the pace of the game, but by the type of actions that the typical user does. Games with tanks, ships, and other vehicles are much easier to replicate their movement patterns with predictive techniques.
In collaborative virtual environments where the entities do not typically follow linear paths there remains questions if predictive techniques work well. Typically the movements in games are less complex(ie run down the hallway, turn right..run some more) and are easier to do with predictive techniques.

Share this post


Link to post
Share on other sites
If you limit yourself to 16 people you don't have to keep a client/server architecture. It is probably easiest to do so, but you could explore other techniques such as using a mutlicast overlay network. You have a lot of flexibility with different ways to forward packets when the game size is kept small.

Share this post


Link to post
Share on other sites
Quote:
Original post by Caced
It really boils down to how much precision you DO need. In many fast-paced online games I've played, movement/positional updates only come about 3-4 times per second. That might sound like a longshot from 30 times per second, but players can't maneuover too much in 250ms. ;)


Hmm, if you say so... My biggest inspirations for this game are Star Control and Inner Space, and in both of those split-second fingering tends to be rather vital. It seems likely that, in such a game, taking a quarter of a second for one player to notice it's been shot at by another could be a big deal. However, it's definately worthwhile to actually test in terms of gameplay.

Quote:
Try sending (in your movement/positional packet) the X/Y(/Z) of your player/object and the direction that it's heading in. That way the client will assume the player is continuing in the same direction as he was when it received the packet -- in many cases, the players does move in the same direction anyways. ;) Then when you get the next packet of data about that player/object, correct its position by some subtle method, like quickly sliding the entity over to where it should be, which shouldn't be too far off. They shouldn't be able to get too far in 250ms!


I'm skeptical of this tactic... it's certainly viable, but as I said, in the gameplay I'm envisioning, a half second of latency can mean the difference between life and death, and I'm reluctant to "fudge" that one way or another. It would be pretty much on the same level as, say, a multiplayer racing sim where it's possible to drive through objects, then suddenly crash when the server notices and corrects it (or not!). I suspect I won't have a choice though.

Quote:
Original post by stake
Fast paced game?? Not sure what you mean by that???


I mean that, as I said, it's not some tank or ship sim where things are going in fairly predictable directions at fairly slow and steady speeds. Hopefully, at least, it's going to be able to get pretty chaotic, with ships and missiles flying every-which-way. I'm not saying it can't be done, I'm saying that introducing even a fairly small and stable amount of imprecision makes me antsy. Maybe I'm just paranoid.

Quote:
If you limit yourself to 16 people you don't have to keep a client/server architecture. It is probably easiest to do so...


...which is exactly why I'm doing it. For such a small number of players, there's not really any reason to do otherwise. And since my knowledge of building networking systems from scratch is very limited, I have a very good reason to keep it simple. Especially since I WILL over-design and over-engineer anything I can get my hands on, if I give myself the chance, and then end up unable to actually build it.

Thanks for the replies. I plan to toss a copy of it online sometime, complete with source code, but all I have right now is half-prototype code. I haven't even started on the networking stuff yet; I wanted to work out what I was going to do with it before I tried. Ask how far I've gotten in the fall, perhaps.

[Edited by - Icefox on June 20, 2005 2:25:27 AM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!