4
\$\begingroup\$

I'm programming a 2.5D networked game in Java. The networking works like this right now:

  1. Create new networked sprite object at the client. Send it to the server. Server distributes and saves it. (TCP-ObjectStreams are used)

  2. The Sprite's state is represented by a String that contains its id (Player's name+Index) and values. You can request the state with the method getState():

    return getID()+"|x"+getX()+"y"+getY()+"#";
//Example: "Grimey2|x402y123#"

These states are collected multiple times a second by adding them to a single big String:

zState += spriteArray[x].getState();
//Example: "Grimey1|x752y133#Grimey2|x410y31#Grimey3|x202y13#"

All sprites' states are then saved in a HashMap at the client, sent to the server (Java DatagramSocket) and saved there too.

Is there a more performant way to handle sprite-updating than with Strings?

|improve this question
\$\endgroup\$
6
\$\begingroup\$

Assuming the player index is unique, there's no need to send the name along with it each frame. Send the name + index once, store it in a lookup table on the client, and only send the index in your per-frame updates.

Also, if there are multiple location changes per update, why send the ones that have already expired? Unless I'm misunderstanding the purpose, the client only needs to be aware of the most recent state. If it changed 3 times since the last update, and the first two are completely nullified by the third, send only the third (final) state.

As for string vs other format for efficiency, strings are rarely the best choice for anything other than actual text. Establishing a known binary format could further reduce your update token size. For example:

[player_index](2 bytes)[x_position](4 bytes)[y_position](4 bytes)

would allow you to represent the same data in a guaranteed 10 bytes, rather than the variable length strings you're currently using. With a fixed format, you can remove the tokens that appear to be delimiters, "|" and "#" at the beginning and end of the (x.y) data, as well as the 'x' and 'y' labels.

Edit: though you would need to distinguish between player lookup data and player updates, so an additional byte or two at the beginning to identify the format you'll be reading after that would be required.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Thx for your answer! I already thought about a binary format, but i didn't go for it because i have no experience in working with bytes. This seems like the best way to do it. \$\endgroup\$ – VaTTeRGeR Apr 26 '13 at 15:56
  • \$\begingroup\$ @VaTTeRGeR don't worry, bit level arithmetic sounds a lot scarier than it really is. Just read the wiki articles on bitwise arithmetic and bitmasking and you should have about 80% of the theory you need. \$\endgroup\$ – Tacroy Apr 26 '13 at 16:11
  • \$\begingroup\$ If handling binary is intimidating, I wouldn't worry about bitmasking at first. You can gain a little more memory/bandwidth savings by marking things down to the maximum number of bits for a value (ex: if you will have at most 16 players, you can mask off 4 bits instead of using the 2 bytes I recommended for a player index above), but don't make that the first thing you try to do. Get comfortable just reading and writing standard data types, then you can get fancy with bit shifting and subdividing your bytes, bit flags, so on. \$\endgroup\$ – LLL79 Apr 26 '13 at 17:37
  • \$\begingroup\$ @VaTTeRGeR Note that often the biggest advantage of a binary format is not the size, it is the speed of both writing and parsing data. Java like most modern high level languages have commands that make translation between readable and binary numbers easy to write, but the code behind is really slow. Since modern computers are so fast this slowness is for a lot of purposes unnoticeable, and I guess it doesn't impact this case much. But if you call yourself a programmer you should learn to use binary sooner or later. It is really not that hard, you just have to think with the binary mindset. \$\endgroup\$ – aaaaaaaaaaaa Apr 26 '13 at 21:21
  • \$\begingroup\$ thx for your further attention :) i tried out the Stringbuilder, as Anko said, it already gave me enough performance. If there are any further issues i may go for a handcrafted byte protocol. greets# \$\endgroup\$ – VaTTeRGeR Apr 27 '13 at 13:10
1
\$\begingroup\$

The source of your performance drain is likely string concatenation. There are great answers here on how to concatenate strings efficiently in Java.

Summary: Learn StringBuilder.

If even this performance boost isn't enough, you could design a binary protocol, but think very, very hard about it first.

|improve this answer
\$\endgroup\$
0
\$\begingroup\$

Have you looked at how any network libraries are constructed? For java, I would highly recommend the Kryonet Library. It uses a serialization system called Kryo and is very performant with UDP and TCP...

http://code.google.com/p/kryonet/

http://code.google.com/p/kryo/

|improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.