   package size/sending frequency for mmog?
  Hello everybody!I'm planning on writing an mmog in which, at some occasions, fast-paced combat is to occur. The action is to be top-down 2D space combat and always limited to a small arena.Now I want to tap on your experience:- Is a package size of 8 bytes for transmitting all information about a player too large? Any good articles on optimisation?- How often should I send updates for smooth gameplay? 10/sec? 15/sec?- Bulltes will only need information sent when something changes. Over UDP this means spamming the client with packages till it sends an ACK. At what rate should this happen?- Any good tutorials? I've read a few on UDP and UDP vs. TCP/IP, but they just scratch the surface... is there something that tells you: "A million people before you did this mistake, so don't do it, better go that way"?Thanks a lot in advance,-Wojtek   
  I think you'd greatly benefit from this FAQ here: http://www.gamedev.net/community/forums/showfaq.asp?forum_id=15Has answers for all your questions and is stickied on the "Multiplayer on Network Programming" forum if you ever lose it. FYI, maybe post your request there next time. Anyways, good luck with the project! :)-Etyrn   ;  Disclaimer: I am not a network programmer, by any means. I rather hate it, but I do know a (very) little, so I might be able to help a bit.Quote:Original post by grayFalcon- Is a package size of 8 bytes for transmitting all information about a player too large? Any good articles on optimisation?It really depends on what "all information about a player" entails (but 8 bytes seems a bit large). Will you just be sending position/velocity/timestamp data in most of your packets, or is there more information you need to send? Really, the correct packet size is the smallest one possible.I would also recommend having different packet structures set up for different things. Position updates should be as small as possible, and will make up most of your traffic. Since you'll be sending so many, you can send these unreliably using plain old UDP, without much of a problem.Fire/Hit packets are another story. Firing a bullet or hitting an enemy is a major event, and youll want to send it reliably. Note, However, that reliable does not mean TCP. I recommend writting a reliable UDP layer on top of UDP, with things like seuqence numbers, ACKs/NACKs, message queueing, etc. For these reliable packets, they will probably be a bit bigger, but hopefully not by much. When the player fires the bullet, you'll need to communicate the players position, orientation, the fact that they are firing, what they are firing if you have multiple weapons, and possibly the players velocity depending on your physics model.To summarize: I don't think there's any set in stone "optimal packet size", just make it as small as possible (don't send a DWORD when a bit will due).Quote:Original post by grayFalcon- How often should I send updates for smooth gameplay? 10/sec? 15/sec?Definitely not every game loop, I would say betwwen 10 and 15 per second for position updates is a good ammount, but once you get the network architecture in place, this is an easy value to change. I'd start at 15/sec, and tweak it based on how smooth the game runs and how big an issue latency and bandwidth consumption is.Quote:Original post by grayFalcon- Bulltes will only need information sent when something changes. Over UDP this means spamming the client with packages till it sends an ACK. At what rate should this happen?Well, once you figure out the round-trip latency, it will take half that time for the packet to reach its destination, some ammount of time to process the message, and then half the round-trip latency again for the ACK to reach you. Round trip latency can be found pretty easily when the two players connect to each other, and how long it takes to process the message is dependant on how efficient your game is, but presumibly, that time is far less than your latency.One thing I would think about is NACKs over ACKs, as long as reliable messages will be sent fairly regularly and close together. With NACKs, you assume the packet went through fine and only send it once. If it didnt go through, the server will see that the next reliable packet it recieves is out of sequence, and will send a NACK telling you which packet in the sequence it is missing.Another optimization would be "passive ACKs", where in your packet header, you include the last sequence number you recieved. Then, if you keep all your reliable messages in a queue, you can send the entire contents of the queue (ie, multiple message at once) each time you send a reliable message. Every time you recieve a message from the server, you chack their "passive ACK" number, and discard all messages up to and including that number from your queue. This way, if a packet gets lost, the next reliable packet sent will include both itself and the lost packet, so theres no need to wait for a NACK, find the missing packet in your queue, and resend it.Quote:Original post by grayFalcon- Any good tutorials? I've read a few on UDP and UDP vs. TCP/IP, but they just scratch the surface... is there something that tells you: "A million people before you did this mistake, so don't do it, better go that way"?None that I'm aware of offhand, sorry, but check out (if you haven't already) the Networking forum and the articles here on Gamedev.Long story short, if I were you I wouldnt make an MMO, but, to each his own.Good luck.[Edited by - Driv3MeFar on June 13, 2006 6:03:18 AM];Quote:Another optimizations would be "passive ACKs", where in your packet header, you include the last sequence number you recieved. Then, if you keep all your reliable messages in a queue, you can send the entire contents of the queue (ie, multiple message at once) each time you send a reliable message. Every time you recieve a message from the server, you chack their "passive ACK" number, and discard all messages up to and including that number from your queue. This way, if a packet gets lost, the next reliable packet sent will include both itself and the lost packet, so theres no need to wait for a NACK, find the missing packet in your queue, and resend it.Thats a good point you make there. I should have a look at my networking code to see if I can use this instead of the NACKs. Thanks!EDIT:On post should be enough :S   