   Game Network Model
  Hi guys, I was going to post in the networking section but I saw the beginning section just in case its a 'been answered 100 times' before question i'm asking.I am just learning xna and making tcp or udp comms in c# via a dll. I have no problems using xna (it has no networking support at present), or c# and making a comms dll for use in xna works fine. The problems I am having are more design in nature.I have been reading this forum on and off and have created a few versions of my test app, all just one server and one client, running on the same machine. just moving a 2d sprite about.I first went for what I have named model one, both sides blast the other with location data everytime they move. I believe this is called location spamming or something simular. This was very jumpy and not good at all.model two, the server is in control, the clients (well I have only one at the moment) can't actually move anything. They send a packet to the server every time a control has been pressed or depressed and the server handles the location update and sends it back to the client. Now this idea as I know from this forum is better as all clients are treated equally. but sadly is still very jumpyI have read (yes you guessed it from this forum) that the server sending an update beat/tick of 5 times a second should be enough, is this true?model three, bit of a hybrid where the client updates itself and accepts the servers beat as the correct one should it differ to the local one, kinda somewhat erractic.model four, which I have not managed yet and not at all convinced is a good idea. Each side runs everything locally and predicts (basic interpollation i guess) where the other clients are and uses the server beat to correct any mistakes. So if client A thought client B to be at pos x,y and the server told it, it should be at x,y-10  then the client could maybe alter the speed of the other client locally to allow quick correction. This can not be a good idea lolPlease shed some light onto how this sort of thing works best? Remember i'm not trying to program quake and don't need advice on languages or libraries. My first step is to going to be rather like 2d tanks (we all start somewhere lol)Any help would be great :)   
Quote:I have read (yes you guessed it from this forum) that the server sending an update beat/tick of 5 times a second should be enough, is this true?Depends on game and network.For internet, you need a way to handle 250+ ms latency. For LAN, updating 10-50 times/sec might work. How fast are client connections? If you have clients over dial-up, then you'll have about 3k/sec downstream.   ;Thanks for your reply.The type of game i'm aiming at is probably 4 players, one server and three clients. All running from separate machines over broadband connections.Getting back to my 'models' I did start a new idea errr model 2.5 i guess. The server is in control and sends locational update packets to the clients on the beat method. But with the locational data it also sends directional data (etc...) so the clients know where everything was heading. The idea here is that the clients can update the the players inbetween server beats, and makes corrections if the server beat diffs. Again i'm not sure this is a good idea.;Anyone have any ideas on what sort of model/system I should attempt to code?pleeeeeeeeeeeease   ;  You already have the right idea - sending positions and directions and interpolating accordingly is pretty much all you need for a reasonably smooth game. Typically the client moves everything in the way it expects them to move, and amends those positions when the server tells it to. Just make sure you're sending frequently enough to accommodate how often the direction and speed changes so that client predictions don't get too far out of step with reality.  Consider damping the corrections down as well so that movement is smoother, at the expense of a bit of accuracy.   ;  Ok then so the model is rather like this.The clients send the server infomation on the users keypresses/wishes to do things, in this case start moving up/stop moving up etc...The server on a beat system sends all the clients everyones positon and direction (speed is contanst)The clients update the players locally, moving them in the direction supplied by the last beat.When a client receives a beat it will use the new location info and direction for all players and snap them to the correct place if its incorrect.Now here comes dampening to make the changes from the position the client thinks a player is in to the actual position less harse.Have I missed anything? I'll have a go at coding it later :)   ;  That's a perfectly good starting point. With constant speed you shouldn't get many times when you need to noticeably snap someone back into position though. Make sure you're sending updates frequently enough to catch direction changes early. In theory, you don't need a 'heartbeat' style update, you just need to update any time a player's travel velocity changes. (That includes direction changes plus start/stop changes.)   ;Ok, I have found that my largest problem was my hardware. Running the client and server on the same machine was useless and it turns out that my second test machine isn't up to the job. Very odd an amd 3200, 1.5gig, geforce 6600GT. can not move my 2d texture about the screen smoothly. No doubt due to having less frequent update cycles than my newer machine. Whatever XNA is doing behind the scenes it sure needs a decent comp to run properly. Don't want to start debating that though.Swapped my second machine for a new laptop and things are starting to look better :)I have stripped it now so the server is the only one with a sprite to move and the client just shows that sprite (start small etc...) it moves quite well. I have added like an offset so that if the clients pos doesn't differ much from the actual pos then don't jump it. I have noticed that quite often the client gets ahead of the server slightly and when the server stops telling the client to move the sprite the sprite will end up in slightly the wrong place. It suddenly dawned on me thats what interia (is that spelt right) can do for me? right?When the client sends the stop moving command to the server, the server actually instead sends a final place command (or something) that tells the clients where the character will stop. This gives the clients time to stop the character all at the same place. On the right lines?;Quote:Original post by ScarySproutRunning the client and server on the same machine was useless and it turns out that my second test machine isn't up to the job. Very odd an amd 3200, 1.5gig, geforce 6600GT. can not move my 2d texture about the screen smoothly.This will be down to how you've coded it, one way or the other. It's not your hardware and I seriously doubt it's XNA either. It might be how you're doing the networking, or the rendering.Quote:I have noticed that quite often the client gets ahead of the server slightly and when the server stops telling the client to move the sprite the sprite will end up in slightly the wrong place. It suddenly dawned on me thats what interia (is that spelt right) can do for me? right?Communication takes time. By the time the client has been told to stop moving an object, chances are high that the object is past that point on the client. One solution is to ensure that the client is always rendering slightly behind the server, so that such messages always effectively arrive in time. This isn't really my area of expertise however.   ;  Also... you may find some help in the Multiplayer/Networking forum's FAQ, specifically question 27 (though it's all worth reading, even if you don't take it all in immediately).   