Whew! Yesterday's big lore push gave the Bards enough momentum for me to step away and focus on code for the first time in a long time.
The topic of the day is mod support. There are two kinds of mod support in Unity - the kind where users can mess with configuration files, and the kind where users can actually write new scripts.
I'm all over the first kind. With the exception of terrain data (which I'll get to later) all the objects in a FRONTIERS scene* are just placeholders with instructions that the GameManager uses to load XML files, which are themselves just instructions for configuring game objects. Meshes and textures for structures, cities, characters and so on are either pulled in directly from Resources or are generated using prefabs / pieces of prefabs in Resources, then configured using the data from the XML file by a set manager classes.
*(I may just ditch Unity scenes altogether and save world configurations as XML too, though you'll still use the Unity Editor to create & edit them.)
Since assetbundles allow me to load scenes from outside the build players can muck about with configuration files for paths and structures and what have you using the Unity Editor, create a new scene where these objects are placed, lump it all into an asset bundle and voila, you've got a mod - everything from paths to cities to quests to dialog will be totally new.
I also think
this will cover texture packs, though I haven't tested this yet. I will have to write a system that looks in a specified folder for texture pack bundles, resolves conflicts somehow, then dumps the textures into the appropriate materials. Loading new models is trickier because I have to load the data myself. But nothing I can't handle especially with all the great scripts out there.
TL;DR: Configuration modding is no problem. It just needs to be filled out. (Ha, 'just!'
The second kind of mod is trickier. If people want to write new scripts for WorldItems - and they will - then they've got to start dealing with managed .NET DLLS, and FRONTIERS has to be able to interface with them. Which isn't too difficult in theory, but like many things on this project I've never actually done it before. And when you start adding tricky restrictions like Unity apparently not permitting classes within a dll to be added to a GameObject unless they derive directly
from Monobehavior - which they won't if they're a WorldItemScript - well... I start to sweat a little.
But I know it can be done - I've seen it done before. And what one man can do, another can do!
Language is to the mind more than light is to the eye.