Does anyone have any advice for adding mod support to a commercial project? I figure most developers started out as decent modders, but I wasn't one of them. I've done some tweaking and playing around with games like GTA and Morrowind, but it was only intended for myself. In other words, I could use some advice from modders with more experience. Especially those who have been let down by a lack of access or overwhelmed by too much access in other games. My current plan is pretty simple: All of my game's files are accessed from one compressed datafile. Modders are not expected to mess with it. To apply a mod, a player would simply define a directory at the title screen. When the game looks for anything within the original datafile, it will check in this directory first, loading resources from there whenever possible. First, does it seem like a bad idea to have the player browse for directories? From what I can tell, Microsoft seems to default to hiding bare directories from users (an option I'm sure most GameDev-type users change immediately). Should I or do I need to use the "My Documents" system for this? Or should/can I place mod directories in the game's install folder? What would be the problems associated with that? Second, from a modder perspective, what would be the biggest problems with this system? As a modder, you would need to know the filename of any resource you wanted to change. In many cases, you would need the original files to make modifications to. I would freely distribute obvious mod-worthy files like objects, armor, weapons, materials, and other parsed-text files through a website download. Since most of my game is defined through parsed text, they would have access to just about everything, other than data defined through the map editor, which I would also supply through the website. Finally, I haven't decided how I'm going to handle the distribution of my game, but if I go with a typical publisher, they'll probably have some say in what I can do with the modding system. I'm not sure what lines will need drawn for this. Hopefully, they'll at least allow it. I think that covers it. Any opinions or information is appreciated.

Personally I found Unreal (Tournament) to have a very nice modding/scripting system, from creating mutators for matches to full conversions. Due to the huge wealth of mods available for this game I'm inclined to think that many people would agree.

I'm not sure if a single compressed datafile makes this kind of system very easy to implement - I'd like something akin to "modules" which can be compressed/compiled, contain/reference their own media and "hook in" (by events or some kind of callback system) to various parts of the game engine to allow modification of the way the game works (scripting), replace media with its own and so on. Perhaps a module could even completely replace a default pre-packaged one, rather than just being imported "on top" of the existing data.

A command-line argument, "plugin/mod manager" GUI (or both) allows these modules to be "imported" and activated/deactivated. Even if you do go with simple directories, a single "master package/mod/plugin file" containing references to the actual files might be nicer conceptually than the player selecting a directory. This file might also contain some data to define the order of precedence when ambiguous filenames are encountered, and so on

Personally I don't like the idea of replacing a media file by the simple existance of one with the same name. In fact, I would argue that the filenames should be largely meaningless and the content of the files/content of the "master file" determines what is what.

Quote:

Original post by WavyVirus Personally I don't like the idea of replacing a media file by the simple existance of one with the same name. In fact, I would argue that the filenames should be largely meaningless and the content of the files/content of the "master file" determines what is what.

Any parsed text file can use #include directives to include any number of other parsed files. Likewise, the map editor would scan the directory to find any lose objects, like item or character files. Resources like models, textures, and sounds are referenced in the parsed text files, so you could simply change the filenames there.

If the game tries to access a file (through an #include, map editor insertions, or textures/models/sounds that are referenced in parsed files) that isn't included in the original datafile, that would work fine as long as it exists in the directory.

Is this what you meant?

With your system, could a mod be created to override a HUD image for example, with its own image of a different filename?

My real problem with the idea is the implicit over-riding of a resource file by virtue of the existance of another in a mod folder with the same name. To me, this seems like it should be an explicit operation. For example, I'm sure accidentally creating a file with a conflicting name and breaking a gameplay element is unlikely, but not impossible.

EDIT: Also, I think that rather than scanning the directory for loose files, having some sort of master "index" file would be my approach.

I do see some of the advantages, such as never having to bother with the concept of "compiling"/"indexing" the mod (even though this might be a very simple and quick operation). This takes a step of complexity out of creating or debugging a mod.

However, the index only needs to be updated when a new file is added, and allows more flexibility in referring to resources based on what they *are*, rather than their filename.

Quote:

Original post by WavyVirus With your system, could a mod be created to override a HUD image for example, with its own image of a different filename?

No resources are hard-coded into the programming, so just about anything can be re-reference to another filename by modifying the parsed text file of the object that uses it.

Quote:

My real problem with the idea is the implicit over-riding of a resource file by virtue of the existance of another in a mod folder with the same name. To me, this seems like it should be an explicit operation. For example, I'm sure accidentally creating a file with a conflicting name and breaking a gameplay element is unlikely, but not impossible.

Yeah, that's possible. I could require modders to type all of the files they want to replace into a list, but it seems like it would be easier for them to just prefix or suffix files they don't. IE: smod_Faces.png or smod_LibraryEntrance.txt. I can also guarantee that filenames starting with lower case won't replace anything.

Quote:

EDIT: Also, I think that rather than scanning the directory for loose files, having some sort of master "index" file would be my approach.

Pretty much only the editors scan directories for loose files. Everything else is globally indexed (as you describe) or referenced from other parsed files. For example, a character file will define which items to include in inventory or equip. The item file (such as a weapon) will define which models and textures to use, as well as which particles and sound effects to use when it's fired, etc.

Quote:

I do see some of the advantages, such as never having to bother with the concept of "compiling"/"indexing" the mod (even though this might be a very simple and quick operation). This takes a step of complexity out of creating or debugging a mod.

Only a few types of elements are globally referenced or indexed. Things like materials/defense specs, particles, character skills, etc. Almost all of them are globally loaded from a single file named _WORLDREF_Header.txt, whose contents look something like this:

#include "REF_ItemFlags.txt"#include "REF_DefenseSpecs.txt"#include "REF_CharacterStats.txt"#include "REF_SkillSchemes.txt"#include "REF_Particles.txt"

Modders can do the same thing with any parser files. For example, they can have this in REF_Particles.txt:

#include "particles_sparks.txt"#include "particles_gore.txt"#include "particles_water.txt"#include "particles_explosions.txt"

It seems like this system works for you then, and you're right in saying that any naming conflicts can be avoided with minimal effort on behalf of the modder.

I guess the most important thing for moddability is simplicity and smooth workflow. As long as your editors tie these resources together nicely then most of this is acedemic, and you'll do well with this system

Quote:

Original post by Kest Does anyone have any advice for adding mod support to a commercial project? I figure most developers started out as decent modders, but I wasn't one of them.

Been having some good results using Lua to store data & moddable code in a mod folder. I have one folder called [game]/mods/Vanilla, which is the basic game -- so the regular game IS a mod. Then other mods are other folders just like mods/Vanilla.

If a mod is only going to make a few changes, the first thing it can do is call the Vanilla settings, then over-ride and add to it. Or it could be a total conversion and do everything itself. It also makes it easy for one mod to incorporate several other mods.

And the only thing the game engine needs to know is which mod to start with, which is a variable in settings.lua in the main game engine directory. Could be a commandline arg, or environment variable too.