0
\$\begingroup\$

I know it matters but...

i know in networking there are packet size limits. for example, most UDP libraries enforce max packet size of around 65535.

can I write on the network as much as possible until it exceeds the size of this limitation?

my question is about clarity and is less error-prone. most of the network layer source code I see is about reading bytes in order one by one to read the data of floating numbers.

if there is not much data getting transformed in my game can I simply use simple formats like JSON or their adding characters can reduce network speed?

Improve this question
\$\endgroup\$
2
  • \$\begingroup\$ The simple rule the thumb: The more you transmit, the slower it is. But if that is noticeable on your game is another matter. It depends as well what kind of data you submit/ get. JSON just makes it easier for us to interpret the data but that can be a weak point in a final game (easier to manipulate the data when it is easy to understand) \$\endgroup\$
    – Zibelas
    May 20 at 6:19
  • \$\begingroup\$ That looks like it could be an answer, @Zibelas \$\endgroup\$
    – DMGregory ♦
    May 20 at 10:55

2 Answers 2

Reset to default
2
\$\begingroup\$

The simple rule the thumb: The more you transmit, the slower it is. But if that is noticeable on your game is another matter. It depends as well what kind of data you submit/ get.

JSON just makes it easier for us to interpret the data but that can be a weak point in a final game (easier to manipulate the data when it is easy to understand). If you are planning to allow the community to create mods for your game, giving them access to easy to understand JSON data structure can be a plus for your game. If you just use JSON because JSON, you risk into running automation/ bots/ data manipulation.

For some data JSON might be a bonus, usually initial data like inventory data, stats, quest text or monster info.

You as the dev should know exactly what kind of data is coming, parsing JSON from client side is therefore not really needed.

Improve this answer
\$\endgroup\$
2
  • 1
    \$\begingroup\$ One thing you might want to consider: Game data tends to grow during development, so just because the transmission overhead of a verbose format like JSON is not noticeable now doesn't mean that it might not be a problem later. Some early testing with larger data chunks might save a more difficult code change later. \$\endgroup\$
    – MadMan
    May 20 at 21:16
  • \$\begingroup\$ Reminds me of the famous "static memory insurance" pattern in embedded programming. \$\endgroup\$
    – Steve Schnepp
    May 21 at 12:42
1
\$\begingroup\$

So you can technically just write until you hit the max. But UDP is lossy - so there’s a chance that whole packet will just disappear into the ether. In addition the large packet will likely include quite a bit of state. If you’re attempting to send something every 1/x of a second you’re probably not going to have enough things to fill that packet size: at least for things that need to update that quickly.

JSON as a format is fine for human legibility, but the side effect is that it is verbose. As @Zibelas said, if this legibility is important then you absolutely should use a more verbose format.

For a lot of games, however, the sheer number of objects that need to be synced between server/client means looking at less verbose formats. In addition, if inputs/changes are REALLY important - you can send multiple time delta updates in a single packet.

Packet 1 could contain updates 1-6 Packet 2 could contain updates 2-7 Packet 3 could contain updates 3-8

That way if any one packet doesn’t arrive, you still have a lot of data duplicated.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .