Jump to content
  • Advertisement

roadkillguy

Member
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

100 Neutral

About roadkillguy

  • Rank
    Member
  1. roadkillguy

    Data Coordination Between Server & Client

    I don't think it would be that bad... but you would still need to be able to disregard duplicates given that the server keeps sending them until it gets a reply. (A message could make it and it's confirmation doesn't) and pressing BUILD[/quote] See that's why I LIKE makefiles. I know exactly what's going on. In a makefile you can even write tar and publishing commands. I have setup so that when I compile for windows, it prepends every .o with windows-. (Even in subfolders) That way, I don't have to completely recompile when I want to test the windows version. I guess it's a matter of preference.
  2. roadkillguy

    Data Coordination Between Server & Client

    Should bullets be acknowledged? So far I have a "packets to be acknowledged" list. When a package should be acknowledged, it is added to this list, and a thread keeps sending the data until we get a packet confirmation back.
  3. roadkillguy

    Data Coordination Between Server & Client

    I see.. do you delta-compress everything? I have a class entity with x, y, z, dx, dy and dz that should be sent in a baseline packet right? There will be a whole bunch of these entities that will need to be coordinated, and I'm not sure if I should store them in a list (Delta checking might take a while given that we need to check for every combination for a duplicate) or if I should just leave the packets always the same size (some entities would be empty data and bandwidth would technically be wasted). Should I bother delta checking this list? It will probably be changing every time, and there will be a different number nearly every time (Bullets and players are both entities). Terrain modifications would be the same way. So far I'm seeing it this way (Server Side): Check for acknowledged packets. Update inputs. Update tick. (Simulate) Send baseline packets. --Based on the difference between the acknowledged packets we've received from the client (Their current gamestate) and the current server side gamestate. Do I need to be keeping track of all the clients' gamestates? It seems to me to be the only way to delta compress data.
  4. roadkillguy

    Data Coordination Between Server & Client

    That's actually pretty cool. Do you use a received packet buffer or something? In my game, the client needs to know about the terrain data as soon as they join. Unfortunately, waiting for a packet to be accepted (by waiting for the ack) would not only block, but would also destroy any other packets coming in (They're ignored and have no other place to go). I could solve the blocking with a thread or two, but I'm still limited by my getData function. My other question is, how do you/should I send my packets? It sounds like you send gamestates? from the server, and input from the client. I'm not sure how to organize a gamestate packet. How do you determine whether data is or isn't needed? Right now, I send individual packets and messages. (It's kinda left over from when I used TCP)
  5. roadkillguy

    Data Coordination Between Server & Client

    Ah okay then. Is there a specific way I should be coordinating network ticks? Should all packets have a tick in the header? Waiting on a network tick packet would be kinda laggy. In other words, how should I compensate for a faster client than server? If the client gets ahead (if the ticks are on a timer say) how would they know they're ahead and that the server data isn't just outdated?
  6. roadkillguy

    Data Coordination Between Server & Client

    Subconsciously I was being told that there was data being lost.. I guess I'll just have to trust the routers then? I'll definitely read more into that. I've now designed a pretty cool packet checking system using a list of packets and a pthread. I resend packets every 2 seconds if no response is seen from them. Is that a good number? I think I'll remain with UDP. Also, I'm really liking makefiles and command line g++. I run Ubuntu on a netbook, so VC++ would be rather difficult to install and use (I have used it before). I'm not really one for windows . I think I have a pretty good Idea of what to do now. Thanks to everyone who answered my questions.
  7. roadkillguy

    Data Coordination Between Server & Client

    Hmm I didn't know there were different destination and host ports. Either way, how does a packet tell the router which local ip address to send it to? Does it send it to every local ip? In SDL_Net, there is a UDPpacket struct. It has two destination fields --Address, and port. You then call SDL_Net_UDP_Send(UDPsocket socket, UDPpacket packet) to send the data (which is also in that struct). Unfortunately, a UDPsocket is basically a port binding, and I'm not sure where else a local IP address would come into play.
  8. roadkillguy

    Data Coordination Between Server & Client

    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.
  9. roadkillguy

    Data Coordination Between Server & Client

    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.
  10. roadkillguy

    Data Coordination Between Server & Client

    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.
  11. roadkillguy

    Data Coordination Between Server & Client

    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. [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?
  12. roadkillguy

    Data Coordination Between Server & Client

    Well, I probably wont. Given that I write the server correctly, I shouldn't need to encrypt anything, right?
  13. roadkillguy

    Data Coordination Between Server & Client

    [color="#1C2837"]When clients do something they shouldn't, log it, and discard their input. Then, patrol the logs periodically. You can even write tools to help with this. If you see a particular client doing suspicious stuff consistently, then you can think about taking action. Until then, the best policy is to just ignore things that shouldn't be done. That way, people can't tell the difference between sending garbage to the server (which should do nothing) and sending legitimate but "illegal" input to the server (which, if they knew it was legit but illegal, could tell them how to further exploit your system). [color="#1C2837"][/quote] [color="#1c2837"]Sort of like Darwinian Evolution... [color="#1C2837"]That's what I do essentially. Maybe after x number of strikes the server should start making warnings to the admin. [color="#1C2837"]Should I consider basic packet encryption, such as XOR?
  14. roadkillguy

    Data Coordination Between Server & Client

    I apologize for the long delay.. I actually got distracted working on my game @Kazzahdrane No, it's not peer2peer, I believe server-client works better in my situation. I currently send packets every 500ms, and it seems to work ok. I'm not sure if this is fast or slow compared to the industry standard. @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? @ApochPIQ Thank you, I'm rather new here. @Sappharos I've always tried to follow Never Trust the Client. Sometimes I feel as though I'm a bit paranoid. For example, can the client ignore packets? I currently implement a strike system. 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? Also, that algorithm is exellent.. I cant believe I didn't think of that.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!