+8 votes

I searched the web for this, but curiously it's hard to find so far:

I am wondering if games made with Godot can offer modding support?

With Unity3D you can do that by several ways, with IronPython or C# compiled on the fly from a special folder that is not "baked" into an unreadable database file.

How would we do that with Godot? Provide a "usermods" folder and be able to throw some .gd, .png, .ogg etc in it to be loaded by some modding system? Do we need to modify the engine? Or is it possible from scripts?

PS: sorry if the answer is obvious, I didn't used Godot a lot yet :)

in Engine by (27,902 points)

2 Answers

+5 votes

You can add mods support really easily because you can use load() function to load and execute scripts from user:// Load will return object of type script I suppose.
Take a look into file system docs

You can also load other resources and even scenes.

by (368 points)
Glad to hear there is a way :)
`preload()` is preferable to `load()` in most cases because it will be loaded at compile time, and thus avoids freezes while loading.
Will preload work with data from `usr://`?
ALSO gd script is interpeted so anything you plug into it will work right away no compiling necessary
+2 votes

(Another, updated answer for 3.0 as this question becomes more commonly asked)

So, this is a common question that comes up. https://github.com/godotengine/godot/issues/7753

Essentially you are limited to...

  1. Throwing security out the window and letting people create their own GDScript code. This is what the current answer to this question would be. Just let people create their own GDScript (or VisualScript, or CSharpScript, w/e), and have it reference the assets and whatnot. Then, just plug the assets and scripts into a folder and write your game content so that it scans for that folder to look for pluggable scripts when it starts up. This effectively lets people run whatever arbitrary scripts they want though, so there is no 100% secure way of letting them execute those scripts (since scripts already have OS and network access, among other things).

  2. Waiting until someone implements some sort of sandbox support to protect the local operating system while the game executes (based on the Issue linked above).

  3. Design your own scripting methodologies for your unique project. Examples include...

    a. creating a custom VisualScript editor using custom GraphNodes and GraphEdits.

    b. creating a custom text-based scripting language.

    c. creating a data-driven game where players can edit the data files (editing JSON data or something) in order to modify what content is available in the game.

...or any combination of the above 3.

Note that most other games with modding tools will essentially have created their own in-house tools for editing game content, but those tools will be for their designers and artists (and you as a modder are using those tools), whereas the programmers deal with an entirely separate layer of more detailed information. If you think of Godot as the programmer layer, you would effectively need to create the entire "designer layer" by creating a new layer of the Godot engine that is exposed to them. For example...

If I create an entirely separate Godot project that is the "modding tools" for my game, I might have a base PanelContainer with a GridContainer, some side-docks for FileSystem access, a Viewport in the middle for seeing the world, possibly having an "edit Script" setup that is VisualScript based, but filled with my own custom nodes, etc. Hmmm....this is starting to look more and more like me re-creating the Godot Engine. That's because you basically are re-making Godot, just in a much more restricted and controlled environment that helps prevent people from mis-using the engine's local access to the operating system and network protocols.

by (100 points)

I think it could be done easier than that. What about building your own version of Godot
(that is basically stripped of some things and contains your own script classes & functions via custom module and maybe most importantly a custom export) and distributing that as an editor? Sounds easier to me than creating a Godot-like editor from scratch using Godot - also less Inception-like ;)

Another thing I don't get is why you would be that concerned about security. This is modding. People find a mod they like in the Steam Workshop, or Nexus or whatever platform, download and apply it. If one of those mods goes out of its way to delete a user's hard drive, that is really not the developer's fault - and won't exactly serve to spread that mod.
I see no problem in saying "we allow people to mod our game, you can do potentially harmful things in a mod, use mods at your own risk". I do not believe anyone using mods regularly would be in any way discouraged or even surprised by that.

The custom version of Godot is a good idea. In fact, it would be great if there were a "mod" edition of Godot repository available for people to use and extend separately. Not sure how you would safely pull from upstream though since you'd have to conditionally accept incoming changes. Does git have a way for you to flag certain files / directories as "check with me before allowing merges to alter these areas"?

I actually agree with you on the modding security side of things. Some people expressed similar thoughts about the security issue on the GitHub issue, but iirc Juan was especially concerned about preserving the security of mods and advocated for a sandboxing architecture. We just need to come to some sort of agreement on what should be allowed.

