0
\$\begingroup\$

I am working on a multiplayer open world game where you can equip handhelds and armor pieces. In my architecture, there are clients and an authoritative server. Every equipable item is crafted by a user. They can be different in shape, so it's important that I synchronize shape information. This is expensive data to send (basically an outline plus some more info). Together with this, I also want to synchronize any equipment event that occurs, so when a user meets another user, they can see each other's gear.

The easiest solution I've found is to force-send gear on equipment, but it will use bandwidth even when two players are far away.

This feels like a problem that has been solved a thousand times, so I don't want to reinvent the wheel. Do you know of any best practice/known strategy that suits my situation?

\$\endgroup\$
  • \$\begingroup\$ Is the equipment handled differently from the rest of the player in how it's send to the server? \$\endgroup\$ – Mast Sep 6 '18 at 11:11
  • \$\begingroup\$ I'm sorry, can you rephrase that? I don't understand your question. \$\endgroup\$ – Alakanu Sep 6 '18 at 11:32
  • \$\begingroup\$ You say you force-send gear on equipment. I assume you only send this when the gear is updated. Is this handled differently from other player updates? \$\endgroup\$ – Mast Sep 6 '18 at 11:42
  • \$\begingroup\$ The gear shape is never updated.The easy solution I proposed states that when an equipment event happens the information gets resent no matter what. \$\endgroup\$ – Alakanu Sep 6 '18 at 11:57
1
\$\begingroup\$

One way you can handle this is to hash or digest your gear data, and first send the digest to as "have you seen a gear item with this description recently?"

If the party on the other side says no, you reply with the full data.

They associate that gear data with the digest in a cache, so if the player with this gear swaps it in & out frequently or leaves & comes back, you don't need to re-transmit the full data every time.

If you keep the maximum lifetime of an item in the cache low relative to the size of your digest, then your chances of having a collision from two different gear items producing the same digest can be made quite small - the two items would need to be seen within a short time of one another.

You can further reduce the risk of collision by doing a higher-detail check when I'm in direct interaction with someone - if they're one of the 3 players closest to me or we're using game abilities on one another, we can ask for a different/larger digest to verify that we're showing the correct equipment.

This can be combined with a level of detail system. If a player enters the area a kilometer away, the server can send me the lowest-detail version of the gear, maybe just its base colour value.

As the player comes closer, the server can ask me "Have you seen gear item A8675E875EC24A245D0 at medium detail?" and I say "no," so it sends me a medium-detail version of it suitable for display at that distance.

If we enter within a few meters of each other, the server can ask "Have you seen gear item A8675E875EC24A245D0 at high detail?" and I say "no," so it sends the full data. This way we only send as much information as is needed to adequately display the content.

\$\endgroup\$
  • \$\begingroup\$ Hi Greg, every item has an id, so that is my "hash" and there is no collision problem. Is this a popular solution? Is this polling (have you seen this? yes/no) a good deal for bandwidth? I am just asking because I'm unexperienced with this kind of stuff. \$\endgroup\$ – Alakanu Sep 6 '18 at 14:08
  • \$\begingroup\$ If you have guaranteed unique IDs then that's even better, and you can make your cache larger to save even more bandwidth from repeats. It all sounds like it would work adequately for your needs. Sending "player A has entered the zone at X, Y and has gear items with IDs P Q R equipped" is the bare minimum you'd need to send to draw the character anyway if you already had all the assets locally. Letting the client reply back "what does gear item Q look like?" and remember the result ensures you only send the assets when they're needed. \$\endgroup\$ – DMGregory Sep 6 '18 at 14:34
0
\$\begingroup\$

NOTE: I'm missing some info:

  1. What's the number of simultaneous players
  2. How's that crafting system? I understood that a player can craft a piece of armor with whatever shape they want, is this it? Or are there presets and player can simply increase a little the X side up to twice the original size and choose among 10 textures?
  3. Platform?
  4. Powerful server or not? Is the game already runnable and can the server be benchmarked?

You said you have an authoritative server. If that's the case, why would you have to send anything between clients?

You could send everything once to the server, and it would be the one handling distances and sending the appropiate data to the clients who need it.

Example: If you have a brand new armor piece just crafted, you send whatever info (outline, texture, etc.) to the server, which should keep it in a DB. The server will be updating players' positions and will receive a message if you change your gear, but it won't receive this gear's info anymore (just use ID as mentioned in Gregory's answer). Then, IF players can configure their LOD distance, I see two options:

  1. The player sends a request to the server asking for another player's info when he detects a different player entered their LOD distance (bad idea in my opinion, every client always knowing where all other players are? Security threat on sight).
  2. The server holds the distances of LODs for every connected player. As I said, this should be carefully studied since it's obviously not the same to hold this data for 10 players than for 10k. In any case, it would be just an extra integer for each player and it could be inside the Player entity itself in RAM (to avoid performance problems looking up a hash table/vector/map or whatever). If 1 distance parameter is enough for each player and you had 10k simultaneous players, it would take 10000 * 4B = 40kB in the server's RAM, I think it's not that much to the big troubles you're avoiding.

Obviously there are drawbacks as in any solution. If you add the extra info I mentioned, I could allow me to make my answer more accurate and try to help you better.

Regards.

\$\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.