Talk:Optimizing Your Online Game Bandwidth

From GPWiki

I decided to put this in discussion, rather than on the actual article...

Critique

This guide was written long after a similar guide was posted on the Mirage Source Community Forums. Since the original article (on Mirage Source), it has been found that it is simpler to store strings in your byte array without a length. Rather, do it like C does, and use null-terminated strings. (Add one 0-byte to the end of the temporary byte array that holds the non-unicode string) This allows for having a string stored in the byte array of virtually any length rather than having a separate function to store/retrieve strings longer than 255 bytes.

To figure out the length of your string inside the byte array, simply declare a kernel32 API function: lstrlenA, and use it to find that null-termination, and return the length.. thereby allowing you to easily retrieve the entire string from the byte array.

[Public|Private] Declare Function lstrlenA Lib "kernel32.dll" (ByRef lpStr As Any) As Long

Example Use:

Private Sub Main()
  Dim b() As Byte
  Dim sLen As Long
 
  b = StrConv("This is a test string stored in a byte array.", vbFromUnicode)
 
  'Add the Null-Termination here:
  ReDim Preserve b(LBound(b) To UBound(b) + 1)
 
  sLen = lstrlenA(b(LBound(b))) 'This will return a length of 45.
End Sub

This critique section, and the original guide (on Mirage Source Community Forums) were written by Verrigan. Feel free to use this information to optimize your game development. :)

• Verrigan
• Find me on Mirage Source Community Forums
• http://www.miragesource.com/forums/index.php

Reply from Spodi:

I noticed that guide on there a little while ago, and it was pretty close to the same as this but not quite. The reason I dont like using the terminating character is because you simply can no longer send that character. In vbGORE for instance, most every byte has a use. You never know when one of those bytes will sneak into the string you want to send. Also, I believe this method is a bit faster since you grab the value right out instead of looking for it. Take into mind, though, how often are you going to send a string > 255 characters? So far, I have only found use for a string > 255 characters when using my in-game mailing system. Though for that rare occasion, the extra byte to mark the length as an integer wont hardly make a difference. ;)

Re: Spodi's Reply

Obviously it's a matter of preference... larger packet, or a microsecond of latency.. I can send a book with my method.. You can send an e-mail.

As for the slowness of my method.. It took a string of over 1 million bytes to even display a non-zero millisecond latency using the GetTickCount api (10).. (in the Visual Basic IDE) And that was still more consistantly displayed at 0.. So the latency is definitely minimal. :) Both ways work, obviously.. so it's back to preference. :)

• Verrigan

Suggestion: by sickbailey21@hotmail.com

you could simply make an encryption algorythm to encode the data you store with the client. this way you can store all the data with the client and its extremely difficult for anyone to get all your data especially in the way its meant to be read. You can also use 2 different encryption methods one for received data and one for sent data so that the people trying to get data from your gain for cheating wont be able to edit any data which will have significance.

Re: Suggestion: by sickbailey21@hotmail.com

That is very true, but this article doesn't really cover encryption since that is a totally separate huge category. ;) If you want to see how to encrypt your packets, you can check out how it is done in my engine vbGORE. I recommend RC4 or XOR encryption, unless you are having security issues. The other algorithms can slow you down quite a bit (especially the CryptAPI).