Sharing custom level data over Unity services (or another way)

I am building a muliplayer game where players can create their own levels, I would like players to be able to share and play these levels with other players. If possible I would like a player to be able to host a lobby and send the custom level data to players that join. Does Unity multiplayer services offer something that could accomplish this? If not does anyone have an outline of what the best way to accomplish this would be?

 

When player can create their own levels, it means you have some sort of data structure with which you save that level data, eg. position of objects, height of terrain and whatever. That's the data you need to serialize and transfer to the host, and forward it to the other clients.

There's no built-in feature that does this, since it's essentially just custom data that you need to transfer and store.

 

Thanks for the response. Could you provide me with a rough architectural outline on the tools to accomplish that? if it's not part of unity multiplayer services I feel like the scope of options is pretty big and I'm just not sure where to even start. Would Unity web requests be able to accomplish this? Does this mean I would need to work with some sort of network system totally outside of Unity in general? Any additional input you have would be greatly appreciated.

 

It depends on your data size. If it's just a couple KB you can send that with an RPC message. Not sure if Netcode still has per-tick RPC message size limit but if it does, you'd have to split it up into multiple messages.

 

Do you have a suggestion for if the data amount is more? throwing together a mock up using my current data structure as a minified json my rough estimate is that it would be somewhere in XX KB unless I really limit the size of levels. Any recommendations for that? I imagine I could use a more compressed format and do the multiple RPC calls idea but it just seems kinda hacky. Additionally that estimate is based on if I don't allow the user to set colors for each piece of terrain, which I would like to do, but that would mean sending at least a little data for every piece instead of just the unique pieces, of which there are far fewer, but still on their own make up the XX KB estimate, and at that point it would seem like a different approach would be needed.

 

How much is XX? If it's two-digits it should be fine. I think recently the Unity Transport has increased or fixed an issue that limited message size per send (tick) clost to 32 kb. It should be more now, just give it a test.

If you have Json best idea is to zip compress it into a byte[] array. C# supports it natively and json is highly compressible and the byte[] can be sent natively via RPC.

And now, it's not hacky, it's the regular procedure for any TCP/IP transfer, eg every time you download a file you get a small piece of data and your computer sends an ACK back to the server to let it know it got the entire packet and to allow it to keep on sending more packets.

 

My Man, thank you, this is exactly what I needed to get a sense of direction.

I have 1 more question. This might be expanding the scope a little too much but I am curios if you have any input. Another person I talked to mentioned that it's a tricky to deal with security risk to have users just sending custom data to each other. Intuitively this makes sense to me but I have no idea how valid this concern really is or how extensive the solution would need to be. the data would immediately be deserialized into a levelData game object at which point its harmless but I don't know if there are security concerns related to simply receiving and deserializing that data, also if I am using RPC then it's going through unity services so maybe there is security measures already there? Like I said I get what this person is saying but sending custom data seems pretty fundamental to multiplayer game design.

 

Well, you always have to expect the data you receive not to be the data you expected. For example be prepared that decompression may fail because somehow you received incomplete or corrupt or purposefully tampered with data. However the security risk is minimal if the server is well programmed to handle all possible cases where things could go wrong, and you aren‘t executing that data. Of course someone might still create levels that crash the server by inserting invalid objects or simply too many.

A bigger concern is the custom level data itself. You can hardly prevent users from constructing levels that express offensive thoughts, racism, sexism, slurs, defaming or reconstructing some realworld structure that in the context of your game might be seen as offensive.

 

However the security risk is minimal if the server is well programmed to handle all possible cases where things could go wrong,

Well if I am transferring data via unity RPCs then the server would be the unity relay servers and I assume what they have done would be sufficient.

 

No, Relay isn't ever your server. Your server is your server, the relay just exists to, well, relay communication between server and client. And if I understood correctly, the relay server actually takes itself out of the communication process in cases where a client can directly communicate with the server and vice versa.