Sign in to follow this  

Few questions on basic networking

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

I'm a newbie to networking and have done only one joke of a network for a game so far. That game has only 4 objects to sync so it wasn't much of a problem. This time I'm suppose to do networking for a game that possibly has up to 100(enemies) object in total to sync (up to 4 clients so 4x the packets). So just how big of a packet is too big for a game like this? Currently I have 28 bytes (a struct of positions and rotations) to send per object. This is meant for LAN network btw, I don't dare to try internet yet. My second question is about the mouse. How do you send the mouse movement from the client to the server? with keyboards you can just send key up and key down to reduce the number of packet needed to send, but with the mouse I'll probably have to send every frame since it's likely to be moving anyways. Is there anyway I can reduce the number of packets I need to send for the mouse? Any tips and answer is appreciated (even if it's a "go read that link, noob")

Share this post


Link to post
Share on other sites
The Forum FAQ actually has reasonable links.

In general, you should be looking for ways to optimize packets. For example, mouse movement probably doesn't need more than, say, 12 bits per axis, meaning 3 bytes per frame of mouse input.

You could also look for ways to optimize simulation. If you require that all entities are in sync each frame, then you only need to forward input between the players for each frame, not actual entity state. You might need to come up with some smarts to deal with packet loss in that case, though.

Share this post


Link to post
Share on other sites
I haven't realy worked with bits before, I'm used to use just predefined variables. Any tutorial written on that kind of stuff? As in how do I rip the bits I want from a float varaible.

Share this post


Link to post
Share on other sites
you could just cast from a float to an unsigned short if the position is < 65536... this means using 2 bytes instead of 4 for a position... you probably wont notice any difference in accuracy... you could even just cast your position to a short and then back on your simulation so that it is 100% in sync

Share this post


Link to post
Share on other sites
Why do you want to send mouse positions to the server? Generally you send actions, not raw inputs. e.g. you'd send a single message saying "I've selected entity #1452" instead of "I've moved the mouse to <330, 186>, then <332, 190>, then <338, 194>, then <343, 199>, then <348,195>, then pressed the right button". This also means that if you have some other means to select an object you don't have to change your wire protocol.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anon Mike
Why do you want to send mouse positions to the server?

It's actually quite common for looking around so that other players can see you looking up, etc. Otherwise playing an FPS it would look like everybody is just looking straight ahead eye level. Granted you don't send them every frame.

Share this post


Link to post
Share on other sites
to get more into details, you should NEVER send ANYTHING every frame, no matter what.. first of all, every frame is way too much, unless the person has 10 FPS..

secondly, what about FPS? a person with a faster computer will send much more packets... hell, someone with a really fast PC could bog down your machine... not to mention it would be impossible to check to see if someone was spamming your server with packets just to piss you off / ruin the game..

when doing network programming, always figure out how to send the smallest number of packets possible. taking from Saruman's example, you wouldn't even have to send mouse positions, and definetly not each frame. instead, when the clients orientation _changed_, you send a packet to the server saying "my new orientation is X", where X is a byte in a lookup table mapping to something more meaningfull... something like this is a better way to handle it.

Share this post


Link to post
Share on other sites
exactly. Treating it as an event driven model is what you want to do so that you aren't sending packets and information for no apparent reason. You don't want to keep sending orientation packets for a guy looking straight for 5 minutes.. you only want the data to be send when his orientation has changed. Good post gf.

Share this post


Link to post
Share on other sites
Quote:
Original post by Saruman
Quote:
Original post by Anon Mike
Why do you want to send mouse positions to the server?

It's actually quite common for looking around so that other players can see you looking up, etc. Otherwise playing an FPS it would look like everybody is just looking straight ahead eye level. Granted you don't send them every frame.


You still don't want to send raw mouse positions. What you do is send head orientation updates when the orientation changes. Not only is it less bandwidth (you don't have to send it every frame), it's also resolution and input-method independent.

Share this post


Link to post
Share on other sites
"I'm a newbie to networking and have done only one joke of a network for a game so far."


I just wanted to say that it's no joke - writing a networked game is tough, very tough. So don't feel bad about what you have written - it's all part of the learning process! You've probably gotten further than a lot of people on these forums. :)

My positive support post for the day!

Share this post


Link to post
Share on other sites
Thanks for everybody's tips and help, the project is now done and done with.

Sadly we end up just take out the problem rather then fixing it, there just wasn't enough time left to code a proper client and server. There is networking, it's just not quite as smooth and glorious as originally planned.

Share this post


Link to post
Share on other sites

This topic is 4593 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this