Data Coordination Between Server & Client
If you're going to encrypt network traffic, do it right (public key systems, preferably on top of an existing SSL style implementation) or don't mess with it. XOR mangling (I wouldn't even call it encryption) only serves to annoy the people you're trying to protect against, and when they get annoyed by your security measures, they tend to redouble their efforts to break those measures.
Author
If you're going to encrypt network traffic, do it right (public key systems, preferably on top of an existing SSL style implementation) or don't mess with it. XOR mangling (I wouldn't even call it encryption) only serves to annoy the people you're trying to protect against, and when they get annoyed by your security measures, they tend to redouble their efforts to break those measures.
Well, I probably wont. Given that I write the server correctly, I shouldn't need to encrypt anything, right?
I wouldn't consider it necessary unless you are transmitting personal or identifying information about your users, including (but not limited to) emails, passwords, billing information, etc. If you transmit anything that your users don't want stolen from them, spring for encryption.
@hplus0603 What exactly do you mean by baseline? I have my data wrapped up for keypresses, but I'm not exactly sure what to do. Do i send a packet every time a key is pressed, or do I simply update every 500ms or so?
Baselining is when you send occasional full state snapshots, and then send input commands in the meanwhile. From the client, you really don't need to send snapshots. From the server, you do, to correct for the unforeseen. Typically, all state snapshots and commands will be tagged with the game step number that they're intended for. Note that sending commands needs that everyone needs to simulate the world at the same rate of steps per second (but can render at different rates).
If someone were to use cheatengine (It's scary stuff for developers) to hack their inventory, and the player tries to use that item, they are dealt a strike. After 5 strikes, the server gives end of stream and disconnects the player. Is that okay?
[/quote]
One strike and you're out, in my book! And a mark is made on your account that you're a cheater. Perhaps even insta-banned. Just make sure you don't have bugs that cause bad-bans :-)
Or perhaps you mark the account for hell-ban. The next time it logs on, it will never find any open servers, or only fake open servers on IP addresses that never actually answer. Or only servers operated by other cheaters -- let them play together!
Author
Alright then, I probably wont.
What would be the best way to handle bullets? I know I need x, y, z, and velocity, but what should I do after that? How should the server handle when somebody is hit? Should the server report to the client that the client was hit, or should the client report to the server that he hit somebody? I've actually seen the second in games --as iffy as it could be.
What would be the best way to handle bullets? I know I need x, y, z, and velocity, but what should I do after that? How should the server handle when somebody is hit? Should the server report to the client that the client was hit, or should the client report to the server that he hit somebody? I've actually seen the second in games --as iffy as it could be.
[color=#1C2837][size=2]Baselining is when you send occasional full state snapshots, and then send input commands in the meanwhile. From the client, you really don't need to send snapshots. From the server, you do, to correct for the unforeseen. Typically, all state snapshots and commands will be tagged with the game step number that they're intended for. Note that sending commands needs that everyone needs to simulate the world at the same rate of steps per second (but can render at different rates).[/quote]
So essentially the client needs to be counting steps? I'm not doing that. What happens when an incoming step doesn't match the current step?
Author
I implemented the base + input as suggested, but it's rather choppy (for both clients) every 2 seconds when the data is sent. Should I be tweening rather than hard-setting? Maybe I should only set it when the expected value and the actual value are far apart.
I implemented the base + input as suggested, but it's rather choppy (for both clients) every 2 seconds when the data is sent. Should I be tweening rather than hard-setting? Maybe I should only set it when the expected value and the actual value are far apart.
Yes, tweening for baseline updates is good. Also, some systems run the displayed clients behind in time, such that you will always have the right data for the simulation of each player. You see exactly what they did, but at some point later in time. If that is implemented properly, there should be no snapping, as each baseline should just send you information you already calculated yourself.
As for "who hit whom," that's an entire sub-genre on its own. There are various trade-offs between complexity, response time, what the user sees vs what happens, and openness to cheating. There are links in the FAQ that talk about how various games deal with this (Source and Quake III among the more prominent).
Author
I read through Quake III and Source (I've played both) and it seems pretty straightforward.
One thing I realized is that TCP was a bad idea from the start (it's slow for this). There's only one problem I have with UDP, however. If two clients are connected to a router, how does the server choose to send data to either one of them given that they're not on the same IP as the server? I followed the Quake III doc and have implemented a random ID generated by each client so that the server can tell their data apart, but I'm not sure how to go the other way. The only thing I can think of is for the client(s) to manually port forward everything on a specific port to their machine, but that's a hassle
and the games I've played don't seem to do that.
Basically, I don't know what happens once the packet gets to a router. If it gets sent to both clients I should be fine thanks to the random ID.
[s]
[/s]
EDIT: Ironically, halfway through attempting to implement UDP, I realized my game must sync large amounts of terrain data, and thus, must have a reliable connection to do so...
Do I need to remain with TCP? Or should I implement my own method for packet-confirmation? Bullets are something that cannot be spammed (packet wise), and yet other FPS games continue to use UDP. I've branched my source at this point, so I can go either way.
One thing I realized is that TCP was a bad idea from the start (it's slow for this). There's only one problem I have with UDP, however. If two clients are connected to a router, how does the server choose to send data to either one of them given that they're not on the same IP as the server? I followed the Quake III doc and have implemented a random ID generated by each client so that the server can tell their data apart, but I'm not sure how to go the other way. The only thing I can think of is for the client(s) to manually port forward everything on a specific port to their machine, but that's a hassle
and the games I've played don't seem to do that.Basically, I don't know what happens once the packet gets to a router. If it gets sent to both clients I should be fine thanks to the random ID.
[s]
[/s]
EDIT: Ironically, halfway through attempting to implement UDP, I realized my game must sync large amounts of terrain data, and thus, must have a reliable connection to do so...
Do I need to remain with TCP? Or should I implement my own method for packet-confirmation? Bullets are something that cannot be spammed (packet wise), and yet other FPS games continue to use UDP. I've branched my source at this point, so I can go either way.
EDIT: Ironically, halfway through attempting to implement UDP, I realized my game must sync large amounts of terrain data, and thus, must have a reliable connection to do so...
An UDP destination is an IP address and a port number, just like for TCP (but UDP port X is independent of TCP port X). Thus, the router can tell the two apart.
You can do your own reliability if you want, or you can use both a TCP connection and a UDP packet stream. The Enet library does reliability over UDP if you want to use that.
Author
You can do your own reliability if you want, or you can use both a TCP connection and a UDP packet stream. The Enet library does reliability over UDP if you want to use that.
Is Enet easily compiled with mingw? I currently cross compile to windows from linux. I'm using SDL_Net.
Do I need variable reception ports on the client? My qualm is that a packet might be on port 2000 and be going to IP 203.53.100.10, but will never make it to 192.168.1.108 like it was supposed to. Each client on the same IP could then have a different reception port and the same sending port, but would have to be port forwarded manually. Maybe I'm not understanding something.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
