Discussion User generated content & database handling best practices

Hello, while I have some idea of how to load a file during runtime (perhaps mod it -change colors etc) and save it onto a server then load it in later as needed, I understand this to not be the best system due to high memory cost. And perhaps storage space in firebase storage (temp solution until I move to a different platform like AWS.)

My users will be adding their own custom models, audio, text, and images to build out scenes and I am wondering the best method to handle this... (audio, images, text, video, etc are easy, but models are a lot more complicated) I am staying away from asset bundles and addressable as they won't really work with UGC easily unless I run a virtual version of unity and setup a secondary converter in the background to grab stuff in from the database and convert it and send it back out or something but that sounds like a lot of work and I'm not sure if it's worth it... I've heard addressable are extremely broken so I'm leary about using them. What are some common practices to tackle USC? I'm currently handling everything through runtime but I fear that I will run into long-term issues doing so.

 

Asset Bundles and Addressables both work fine but don't apply in your case as the user would need a licensed copy of Unity to build them.

You can stream files of any kind you like up or down to any server you create or control.

What you propose sounds like making a cloud version of Unity itself, so beware of the scope of what you contemplate.

If you want an idea of what you're up against, make something that lets users upload simple models in a .OBJ file to your own web server, and then another user can index it off your webserver and download it to see it in Unity.

That alone will show you all the technical parts involved.

Keep in mind that does not even begin to touch upon security and authentication and data privacy.

Not only that, give some thought about how to protect yourself when some user starts uploading models of Master Chief and making Youtube videos to show other people how to put it into your software, or uploading content that might make your grandmother blush.

 

The users won't be sharing content with each other easily, only users that qualify from winning creation competitions will have their works on display with their permission. Winning competitions gives them free service on their subscription for x amount of time. Also, there will be a paywall to help discourage some users from just uploading garbage and wasting my server space.
It will be extremely limited too, and they won't have any code options. Users can change colors and change materials to some preset materials available but they won't be able to upload their own textures though I may add an option down the road to allow them to create some sort of texture. Probably not though.

Anyway, I think I found a better way to do this with some of the game mod tools available for unity.
I understand that users may upload copyrighted materials and it will be against our terms of service and they will be banned if they are found to be doing so. It won't stop bad players, but the limited access, paywall, and lack of visibility should certainly help. I do intend to use a fair amount of security but that is something I will need to brush up on a lot more.

It was posts like this that made me worry about how useable addressable were link

 

Interesting. My gut instinct is they are way overengineered but I refrained from posting because I haven't truly used them in earnest / in anger. Our company uses them a little bit but my project does not.

To me the hugest win for late asset delivery in Unity is simply Asset Bundles with Scenes in them.

This is by far the sturdiest "it just freakin' works" solution that I've seen. Coupled with clever additive scene loading, perhaps routed through a "current most up-to-date-scene" datastore, and you have an amazing system that can accommodate just about any granularity of update / late delivery.

 

That's their experience. I only had issues at the start of addressables. I did bug reports and they fixed the issues. To me it became more and more stable and haven't really had any issue since.
I had a few gotcha's but worked around them.

I use them in production on various platforms without problems.
I disagree with them saying it is "unusable" or "broken beyond repair".

I have not used them to mod a game (or application) externally yet. I've only pushed content updates / fixes.
This saved me quite some time fixing non code related issues. Especially for platforms like iOS where you have review times which can take days. Making hot fixes this way saves a lot of time. But when you have code related issues you need to upload a new binary anyway.

Whether you want to use them for your use case is up to you.
There is no tutorial by Unity to mod externally as far as I'm aware.

 

iOS review times are just weird. Sometimes updates take under one hour to approve and go, other times it is three days...so rando.

Thanks for chiming in Masked. I know our company thinks moderately of them, as in they work, but as I said, I felt intuitively they were a space shuttle worth of complexity, especially when I was happy with Resources.Load<T>() and asset bundles most of the time.

 

asset bundles themselves isn't an easy system. Due to the creation, loading, unloading and caching. Before addressables existed I spent quite some time writing my own managing system around them. Which became complex very quickly. This is why there was a demand for addressables in the first place. Because it is complex to manage it.

I'm not saying addressables is perfect, but it does do the job for me as well and I haven't ran into issues as of late.
I find them quite easy to use out of the box.

 

Well it certainly works for modding. I've successfully loaded a spinning cube built from a separate project.

What I did was set up 2 unity projects both with addressables installed and set up.
The base project contains a scripts folder with a Game folder that contains an assembly definition file and a script that rotates the

GameObject

on its Y axis by a given value.

With an assembly definition, Unity builds it into a dll.
I copied the .dll from the

Library/ScriptAssemblies

and pasted it into the modding Unity project under a ThirdParty folder.
In the modding project I created a cube and added the rotation script. I also created a material and applied it with a blue color.
I then dragged it into the project hierarchy to make a prefab.
I added the prefab to the addressables group. I've set the group to a custom build and load location.
I renamed the load key of the prefab to its own asset guid (saving that guid for later use).
I set the addressables build location to a Mods folder in the project folder, but it could be set to build anywhere local at your own convenience.
The load location I set to

{UnityEngine.persistentDataPath}/Mods/CubeRotationMod

.
I enabled building the remote catalog in the addressable settings.
Built the addressables and copied them into the

persistentDataPath

location where it should be loaded from according to the addressables profile load location.

Now inside the original project again I've created an additional script

CubeModLoader

.

Code (CSharp):

1. using UnityEngine;
2. using UnityEngine.AddressableAssets;
3. using UnityEngine.AddressableAssets.ResourceLocators;
4. using UnityEngine.ResourceManagement.AsyncOperations;
5.  
6. public class CubeModLoader : MonoBehaviour
7. {
8.     public string CatalogLocation = "CubeRotationMod/catalog_2023.01.15.00.38.54.json";
9.     public string CubeKey = "0f1cc9ea4fb7c2d4686243e48c497419";
10.  
11.     void Start()
12.     {
13.         var loadContentHandle = Addressables.LoadContentCatalogAsync($"{Application.persistentDataPath}/Mods/{CatalogLocation}");
14.         loadContentHandle.Completed += LoadCustomContent;
15.     }
16.  
17.     private void LoadCustomContent(AsyncOperationHandle<IResourceLocator> obj)
18.     {
19.         Addressables.InstantiateAsync(CubeKey);
20.     }
21. }

This is a very very crude implementation but it does the trick.
I call the

LoadContentCatalog

to load the catalog. But I noticed it needed an absolute path to the catalog json. Not just to the folder.
So I made it a public variable, if I had to rebuild the addressables, the catalog name would change.
After loading the catalog you can use its assets.
I instantiate this cube async using the GUID of the asset that I set as loading key before.

The key elements are clear.
- You need dll's for your users in order to put the necessary scripts on their objects for whatever they want to do. They cannot create and attach their own C# scripts, it has to come from the dll's that you provide. (I have never tried VisualScripting, but it is worth a try to find out if that works for user custom scripts)
- You need to define a location where you want to load the catalog from and make this dynamic in-game.
- You need to define a way to identify the thing you're trying to load.

Content loading can be done locally or from a server.
I.e. you can have your users download it manually and put it into their Mods folder manually.
Or you could make a mechanism that downloads a list of available mods from your server which contains all the information it needs to download the catalog and load the assets. Acting as a remote catalog.

Building a framework for this will take time. But it is possible.
Caveat is that you need the application build to preserve a lot of code through a link.xml. If code is stripped but is used in a modding build it would not exist. i.e. box collider being stripped because unused. Modder uses box collider. It won't work.

 

Thank you for that example it's helpful. I will need to experiment further to see what is the best use case for me. Things like box colliders and such I will need to generate on my own as users will be able to mod that down the road (to define what is clickable) so I won't be as focused on things like that for a little while. I'm making that fairly simple for right now. I do think I will in the end need to build out at least some type of framework for parts of this.