Provide assets for modders

I am building a game with mod support in mind. That will propably be achieved by using assetbundles. The Problem I'm facing is, how to provide assets for modders for creating maps, so they don't have to do everything themselves. I cannot just hand them an assetbundle with the assets I used for creating the existing maps, because I bought some of them on the asset store and can't just hand them out (they could be used anywhere) and it would propably lead to duplicate materials, textures, prefabs, etc.

So I thing I might have to build a modding tool for creating maps. How would I do this? The approach with assetbundles is just so easy, because modders would just use Unity. Now I would have to build a 3D level editor myself, or does Unity have options for that?

p.s.: I don't know if it fits in this subforum, but I didn't find a better fitting one. Sorry if this is the wrong one

 

I'd build a MapEditor app, I did once actually. But you will need a pipeline in your game that works with this, such as loading heightmap data rather than mesh/terrian data. Storing a set of transfotmation data with an AssetId so you can resolve which assets to instantiate on runtime.

When users add custom meshes and textures than you need to find a way of loading these. My Idea would have been a converter where users load their OBJ/FBX and Texture files and I can then serialize the Mesh and Texture2D results. CitiesSkylines I think does that.

Alternatively you can of course use the UnityEditor to do the same, especially when scripts are necessary. But when you export UnityAssets with AssetBundles, then overlapping GUIDs by different users can be an issue, but I am not deep into the topic and how these are generated.

 

If the mod is to be created within the game at runtime, your main focus will be building up the modding tool, and you will need to be its first user when creating your own game. None of this is will be too bad if it is just manipulating existing assets in the unity game.

Importing OBJ/FBX files at runtime is no small feat, it is almost impossible. The only way I've managed to work around this was converting the OBJ/FBX into GLTF, then streaming the GLTF into the built unity game.

This problem compounds on itself if you intend for modders to be able to do their own scripting, since just like the difficulty of importing OBJ/FBX at runtime, compiling C# scripts at runtime is equally impossible. Your options there are to adopt a non-compiling language like LUA or Python, or a visual scripting tool that can be manipulated and run at runtime.

Building a comprehensive modding tool is approaching close to building Unity itself, especially if you intend for users to be able to import/create their own assets. You really need a good reason to be doing that at all. If you are willing to fork out some cash, this might be an option. Even then you'd probably still need to add on top of it for custom tools

 

Its not at all, it's just a set of data that you have to read and generate Meshes, Textures and Materials yourself.
As I said CitySkylines (Unity game) does it: https://cslmodding.info/asset/building/

Random find: https://forum.unity.com/threads/free-runtime-obj-loader.365884/
There is probably ton of these. Just as a hint FBX can be exported as Text/ASCII files so it's easily readable.


And just as I said, you can alternatively share a UnityProject that has editor scripts to export the data in a format that you need it, it will do the asset import already.

 

Hello, and thanks for the fast replies, sadly I didn't get an email so I missed it.
As far as I know it is not really that bad to load scripts at runtime or assets for that matter. It can be done using the asset bundles/pack system that unity provides. There is an asset in the asset store called mod tool. I used it a little, but it got rather useless to me, since I can do the same as it does and it uses an old version of the Mono.Cecil library, so I got a bunch of version conflicts.

To build a 3D Level Builder is the thing I am trying to avoid, because it would be so much effort to do so and I have absoultely no idea where I'd have to begin. So thats just a thing I'd do only if there is no other option.

I had an idea the other day: I could just provide dummy materials and dummy prefabs that get changed out at runtime. So modders can use the assets I payed for without me having to actually hand them out (which I cannot just do). The problem with that is, that I have no idea how complicated this will be and that the level a modder build does not represent what it will actually look like in game. So I don't know how convinient this is.

 

The type of mod building tool you eventually make is going to depend entirely on the nature of your game, which no one can predict. Maybe give more detail on what the game is about and what you hope for players to be able to build/edit, and later repliers can advise better.

I have no idea about the methods @McDev02 has mentioned, so I will just assume @McDev02 will be able to fill you in on that when you need it. In my own experience, putting 3D files at runtime, Trilib has its limitations, taking far longer than is comfortable or even crashing if the model is complex enough, forcing me to find alternatives. With that said, Trilib will be able to do the job in an overwhelming majority of cases, but comes with the upfront cost of getting it in the first place.

For importing scripts, it might not be as simple as you think. Again in my own experience, you can certainly store a script as a TextAsset, but you won't be able to use it in that form without great effort. The scripts have to be built into a DLL, and the platform you use needs to able to make use of DLLs. If both of these conditions cannot be fulfilled, you do not have much hope of getting player written behavior into your game. And this is for people building the mod in the Unity engine and passing it to the game. If your own experience has been different, then I can only hope you have a secure method you have tried before.

Again, will depend on your game and what you want players to be able to influence. That would suffice for something like Mario Maker I imagine. An empty scene, a save format on what prefabs to load, where they should be, and what their initial values should be, and an interpreter to read said save format.

 

Yeah you are right, I could have been more clear about what kind of game it is and what modders should be able to do.
It is an FPS game where modders should be able to build levels and register Items, etc. The target platform is windows.

The modding process I imagine is: modders get a template unity project from me with a library I built, so they have access to the code they need to have to register their stuff and dummy assets they can use, which I replace at runtime with the correct assets.
Each mod has to have a class that derives from the "Mod" class (similar to minecraft modding where you have to have a class with the "@Mod" annotation). A mod is exported as a unity assetbundle (or assetpack, I don't know what's what) with a dll file in it. Each dll file in such a assetpack is loaded in the runtime via c# reflection and searched for a class that derives from the "Mod" class and then instantiated.
A map would just be a scene that is registered from a "Mod" class and then loaded.
I already got that to work with the "Mod Tool" (https://assetstore.unity.com/packages/tools/integration/modtool-75580) from the asset store.

So the question that remains for me is the title of this thread: how to provide assets for modders. Because the way I described it earlier could be pretty inconvenient for modders, I just don't know...

 

Well, I kinda missed this point

Does anyone know if the GUID overlapping could be a real issue. If they are proper GUIDs the collision chance should be fairly low I think, but I don't know a lot about that eigher

 

It feels like you are at the stage where you should try something, anything, to narrow down your unknowns. Even if it is an attempt telling you everything you did was the worst possible way to do it, it will still be a valuable attempt that narrows down unknowns.

With that said, what you mentioned does not narrow down the complexity of the modding. You need to get more detailed in thinking what you want the player to be able to manipulate. Are they able to manipulate terrain? Are they able to spawn enemy and ally AI? Even with manipulating terrain, is there a max and min limit to the terrain size? is terrain manipulation done with height map, or full on marching cube voxels? and alot more, as said before can the player import their own models and animations, can the player write their own behavior. If you cannot do something, are you able to get by without it, and make it a limitation?

Of course for our sake you will not need to go into that much detail, but they must at least cross your mind when thinking about how your player creates their mod. It will give insight into what tools you will need to provide, then how complex your modding tool needs to be, and finally what you need to make/aquire to make it possible.

 

Well they should just be able to use everything unity offers to create scenes if I just use Unity as the modding tool, right? Or is there a limitation in the asset bundles?

But because I did not yet build that asset bundle loading approach I cannot say the specifics. Of course I need to think about limitation and what they should be able to do, but that was not what my question is about (maybe that comes later though).

What I would do right now is getting the game to a state where it is kind of playable (the earliest alpha you can imagine) and then think about how and in what way I will limit the modders. I just stumbled upon this problem in my head when I thought of how modders should create maps.

I just looked up a thread on stackoverflow in which they say:

(https://stackoverflow.com/questions/184869/are-guid-collisions-possible)

 

If this is what you are going for.

Then this is exactly what you will be ending up with. Unless your modder is a game dev themselves, getting Unity for modding might not be commonplace. If you think that, consider that you might be residing in an echo chamber.

Therein lies the problem, you have yet to try out anything to narrow down both your approach and your unknowns.

And you cannot narrow down your approach and unknowns because you lack the direction to go in, since your game itself has not yet solidified its design. Once your game has solidified in design, can you know what players might want to mod, and more importantly what you will allow to be modded. When you can answer that question, then can you answer what tools you need to provide, which leads to what complexity your modding tool needs to be, and finally leads to what you need to make or acquire for your modding tool.

 

Do you think it might be a problem if people needed to install Unity to mod the game? I mean yeah Unity is intimidating on first glance, but in the end, so is a highly capable modding tool...

And in minecraft for example it is super complicated to build mods and yet a whole lot of people are doing it...

 

Fair point. I guess one potentially good side-effect to having Unity3D as the modding tool might be incidental introduction to Unity3D, if said modder has not installed it. Even so an in-game modding tool remains more accessible than an external one, let alone a full fledged game engine. As a fresh product, it will be vying for attention, and the more accessible something is to do, the player is more likely to do it. There is also benefit to branding even an external modding tool, keeping in your players mind this is for your game.

 

Yeah you're propably right. I just think no matter what I programm as an ingame modding tool, using unity would be always more powerful and flexible. I have to think about it, maybe I will even go hybrid and do both

 

Unity will always be more powerful and flexible than any modding tool, caveat being for the purpose of modding an existing game.

Unity's power and flexibility will be a strength and weakness, since no one will not know what they can or can't do to integrate their mod into your game. Giving an exhaustive list of do's-and-don'ts will not be appealing either.

One advantage to making your own modding tool, be it built-in or external, is your promise and their impression that what is built with it will work in your game, leading to a more likely adoption to use said modding tool. Caveat, assuming it's usability is decent.

Regardless, based on what you ask and discuss, you are not at the stage to worry about a modding tool. Make your base game and find the fun there first. You will most likely need to re-build that game anyway for the sake of moddability, assuming you remain inspired enough at that point.

 

Depends on what you want to be edited and what your game systems look like. I had my custom terrain and made a custom terrain editor of course for that purpose.

It limits the possibilities, but there are good arguments:

1. A custom tool is much easier to use for modders as they only need to learn your tool and not how to deal with Unity.
   
2. when working with Unity they can mess up a whole lot, even introduce maleware or code that breaks peoples savegames if you just read and execute their assetbundles. This may not or much harder happen when you have a tailored pipeline of your own. *a
3. Finally, this is much easier to handle. You know exactly what users can do and can't and you don't have to worry about all the possible troubleshooting that might occur. The data that comes from your own pipeline is much more likelier to be valid and error-free.

*a This is why I would rather allow for instance token scripts or the like. This is only data that you add to objects which you will replace with the scripts of your own. They are just indicating what these objects to and the parameters to use.

Finally, although I think that for modding it is important to think about that right from the beginning. Because once you have your spaghetti-code mess you won't add modding support I guarantee you that. But also, you may end up working on tools only and not the game itself so you should sort out your priorities. And with no (good) game there are no mods.