Making your game moddable.

Please make a mod tutorial quick , i have search long time on the web, but only find some outdated info about modding.Tom looman 's tutorial seems not working on UE4.14, when i package the DLC, UAT always failed to update some resource, i searched the answer hub,the only answer is tell me to use github version engine. This is wired! Why can’t the Launcher version can’t properly package DLC? I need a real good toturial on this topic.

Any updates on this?

Bump… Been waiting literal years for this lol

Any updates?

Yeah it’s been literally two years now. Is this going to be another bold promise that never actually happens ?

Would this be related as to why my game won’t find any assets that are added after packaging? I made a function that reads uassets in a folder, and it gets the files that are in the game when I made the editor. But after packaging, uploading to steam and downloading, then adding 2 extra assets to the location (Without ticking Use Pak File), the game won’t read those 2 extra assets.

Hey [MENTION=8]Alexander Paschall[/MENTION] are there any updates on this in light of the recent activity with Conan? It seems like Conan gives access to the entire game contents and an essentially unmodified editor. Personally, my major concern here is how to do this safely, without the end user being able to easily migrate my assets to their own project, or introduce c++ code that accesses the file system, or dish out steam achievements, etc. Currently, afaik we would have to release the source for any editor changes we make, which would immediately invalidate any security measures we could take on our own, not to mention the fact they could simply open the (apparently unpackaged?) .uassets in the standard editor

I can’t really check the custom editors from the launcher, my pc will explode.

I hope we have some news at GDC, regarding modding.

But then again, it is still complicated with licensing of certain assets.

But anyway i would love to have mods support for my games, even if they are not in the same caliber/budget of Conan Exiles, Ark etc.

But for smaller teams or one man projects, better support/documentation, from Epic, regarding custom editors and modding would be extremely helpful.

In regards to this Bioware did this with a few of their games (mainly NWN1 & 2 <= Obsidian modified for NWN2) and there were not many issues with art assets being pilfered. The game hobbyists simply wanted to make content and paint their adventures in the toolset provided. You could say similar things of Skyrim and Fallout 4. Indeed there are the lowlifes that steal art for their own uses but there is nothing that really can be done about that…they will always be present and making something so locked down only inhibits the modding process in the first place.

Modding has been on the palette for my designs in both Unity 4 and 5 (extremely difficult to implement and very fragile) and now in UE4 (wiki shows how it can work => but it is definitely not the smooth process Bioware had with HAK and 2DA files. Yes combining 2DA files was a pain and NWN2 did some things to make HAK files much easier but in general the system is really amazing.

The UE4 dream would be to have 1 folder dedicated to modding…built in…call this Mods. Then under this modders can make 1 folder per mod. Everything associated with that mod goes into that folder. Mods would be specific to the developer so getting each mod to work in that particular game would need to be done in that game project and not in a general UE4 made project.

Now as to exporting the mod so that it will work in the actual game play (or available from Nexusmods or Steam for Free) could be a PAK or DAT file that is nothing but binary data inside that is useless unless imported into the UE4 game project it was made in. In fact if UE4 was enabled for Modding (which it kind of is already) could create a Content PAK that could be loaded into the UE4 editor so that modders can play away with the game project and create mods but are unable to export the uassets from the engine. Perfectly acceptable and keeps all but the most stalwart lowlife out of the original files.

NWN1, NWN2, and Skyrim among others are still going today because of excellent modding support. I have played a lot of hours in ARK but not many in the un-modded version…there are excellent mods for it but ARK is far too rough to mod in. Having a universal UE4 export mechanism that game devs can follow that is simple enough for these devs to create their specific workflows from would make UE4 projects with modding intent a real haven for the modding communities.

With the recent Robo Recall modding videos I think is time to bump this thread.

Yey! +1 it’s really difficult to reverse engineer Robo recall

Hey, I put together some example code for modding in Unreal without engine customization: Functioning UE4 Modding Example Code - No Engine Customization Required - Modding - Unreal Engine Forums I’d love some feedback if anyone has a chance to take a look.

I also found this guide somewhere on the forum.

Edit: Loading Assets at Runtime - Community Content, Tools and Tutorials - Unreal Engine Forums

I, too, have been hoping to let users create levels for my current project once it ships. It seems like if we could distribute an editor build that didn’t allow exporting of assets (to protect our own assets, and the marketplace creators whose assets we’re using) we’d be most of the way there. I guess also a way to restrict which editor elements modders could access would be good too - e.g. if I’m only allowing creation of levels there’d be no reason to give users access to blueprints (other than level blueprints). Different games would want to restrict differently, I guess.

Looks like the community stepped up to the plate on this.

Howdy folks, apologies for the longest of all waits on updates here… We’ve been working with partners and on our own games (Robo Recall, specifically) in order to take the right approach to building out a reusable framework for making UE4 games moddable, and I wanted to wait until we had more to share to follow up. I think we made some great progress for Robo Recall, and a lot of that code should be heading your way in future releases (thinking 4.17 right now). I know that’s still a little ways out, however, I felt it important to point to a couple areas of Robo Recall in which you can have a look at to get an idea of what we did in the meantime:

There are three core aspects to building a moddable game and editor - Editor changes, Engine changes, Gameplay changes. I’ll point out how we approached each and where you can look to get reference.

**Editor Changes
**In the Robo Recall Mod Kit, the main things we did were add new buttons for creating and packaging mods, new menus that helped make subclasses of our moddable base classes, and built a set of subclasses (mod templates) that are referenced by those menus. You can find all about how we built the buttons and what packaging scripts we used, where the mod templates and everything live by checking in Engine\Plugins\OdinEditor. Mods are essentially content plugins that are packaged into .paks and mounted at runtime. We’ll be able to cover this more extensively in a livestream in the future :cool:

If you’re using our approach here as reference, it is imperative that you force cook the Mod Templates folder when you package your game, as they probably won’t be referenced by anything and will get culled from the list (something we ran into).

**Engine Changes
**Taking a page from the Unreal Tournament book, we leaned on the AssetRegistry as a pretty big crutch when working with asset look ups for mods. Since we’re using .pak files for mods and each .pak has it’s own AssetRegistry, we needed to automate the process of appending these manifests so they can be accessed easily without having to check each individual package (UT did this as well but manually, you can check their code here, look for AssetRegistry [GitHub login required]). This is something that will be coming in a later build of Unreal Engine, but the manual UT process works today.

**Gameplay Changes
**For the gameplay side of Robo Recall and making the game ready to consume new info, we moved some of the code that UT has in UTGameEngine into our GameInstance class to ensure it happens after the mods are mounted and the AssetRegistry files are combined. Basically, we look for all new mods found by their package path, check to see if they’ve got content that we care about (subclasses of our base classes, maps), and register them up when they’re proven to be valid. OdinGameInstance.cpp and BP_OdinGameInstance.uasset have all the base code for the mod registry and handle most of the work here.

Robo Recall mods work by registering two classes together and returning the other when one is requested. When a player selects a mod, OdinGameInstance does the following:

  • Checks each moddable type in that mod (players, enemies, etc)

  • Checks any valid assets that are in that type (Catgun, RocketLauncher, etc.)

  • Casts the assets to base class, checks value of Class Overrides (Which is set in the actor when making a mod) and registers that class with the class found in the list (assuming it’s found).

Once the pair has been registered, you can call GetOverrideForClass from Blueprints (or code) as we do in the Holsters (or maybe HolsterComponent?) and OdinCharacter (how we spawn enemy guns). If there are no overrides registered for the class, it just returns the same class so the game functions as usual. Maps are referenced by string and opened by name.

A few other things we’re still trying to sort out:

  • How to handle content that you can’t redistribute in your own editor (like Marketplace content). We had to do some work-arounds for this for Robo Recall and our partners like Wildcard and Funcom have done similar, but we don’t yet have a formalized process for making this smooth and easy. What we ended up doing was cooking the assets and then replacing the editor ones with the cooked versions (often to fun, new crashes :D). A build server that can strip files or automate some of these things helps greatly here.
  • Engine content referenced by mods. We spent a lot of time tracking down what was going on with specific materials on some mods only to find that there were Material Functions being used that were referenced by the mods but not by the vanilla game due to them being in the Engine directory instead of Game directory. IIRC, we ended up just forcing those to cook as well.
  • Other things I’m sure I’m forgetting… but I’ll add here as I “recall” them :wink:

I hope that gives some of you some insight into our approach and a little bit as to what to expect next. Apologies again on the mega-delay in getting back with you all, I’ll be checking back in more regularly and preparing to cover this in more detail in live form soon!

Thanks Chance! Awesome to hear.

So how about allowing us to redistribute the editor with the game on Steam ? Because that’s the one thing we really need.

Thank you Chance that’s great, I’m especially excited about this:

We’ve discussed the explorations of other distribution options but have no plans at this time. Will update if that changes!