Default Build Now 0.987b, Plot Work, and Mod Managing

Since it has been relatively stable, I've just finished updating the default builds to 0.987b on all sites. The "test" links are no longer necessary, and have been removed for now. This updates the following builds:

The changes included in 0.987b can be seen in this news item. The biggest feature is modding support!

Apart from build traffic control, today was spent working on plot and mod management.

The plot work continues on the next encounter, and I've given Harald the go-ahead and plans to start speccing that out now. It involves a new location, new clues, possibly new creatures, items, and even factions. Should be some fun stuff to discover, and I think it'll be worth the wait!

In the meantime, I've decided to make mod-management my top priority. As new builds get released, all modders' work is going to get clobbered by my data overwriting theirs. What's more, when two modders use the same IDs for data, their data will overwrite or be overwritten by the other mod. While I could ask that modders re-index their mods every time, this is far from ideal.

In order to give the modding community a fighting chance, I want to see if I can make mods play nicer with each other, and be shielded from the blast of new IDs in each new build.

I've had some really fruitful discussions with players about different ways to handle this, so I think I can see a way forward. It looks something like this:

  • All game data is referenced by ID. Usually, this is a number, like ID=132, or ID=547. Items are referred to by ID=12.7 or 104.0, etc.
  • A new ID system will look like the above, except it'll have a new prefix. E.g. ID=9:132, ID=0:547, and ID=4:12.7
  • The prefix will likely be a number, or may be a string (i.e. string of letters/numbers), and refers to what mod the data can be found in.
  • If no prefix is specified (e.g. ID=547), the game will assume the data is base game data.
  • There will probably need to be a new table some place that lists which ID prefix corresponds to which file. E.g. 1=TommysMod.xml. Or maybe folder names, so TommysMod is just a subfolder that contains its own neogame.xml.
  • There will need to be some way to specify data that overrides base game data (TBD).
  • There will need to be some way to specify loading order, so modders and players can control which mod overrides the rest.

The last two points are a bit tricky, and I'm still looking into it. First, though, I'm just going to see if I can make the game load different data sets and merge them at runtime, rather than requiring the data merged in the XML (as it is now).

Modding seems to have really taken on a life of it's own, and I think it'll do amazing things for making the game not only a tool for me to share my ideas, but also a tool for players to share stories and worlds with each other. So I want to make sure it has a healthy foundation upon which to build.

Hopefully, we'll make that dream come true! Have a good night, all!

Comments

Aiden_Hoyt's picture
Aiden_Hoyt

This sounds like it might be more easily solved by external software. Some kind of mod manager that merges the mods, using markers used by the mod community to recognize how and where to merge things into the main NEOGame.xml. I understand this might be a big chore, but considering the modding community around here, I think you might be able to source the solution to this out to the community.

dcfedor's picture
dcfedor

It might be possible to have modders write their own merging app, but I see two barriers:

1 - Writing such a tool would probably require considerable time for a modder. (Heck, it would take me a while, and I designed the data format!) There would be a period of time before the software was done, when modders might lose interest in constantly rebuilding their work each new build.

2 - New players would have to download an untrusted app onto their computers and run it. Some players are okay with this, of course, but many won't be. This problem disappears if the mod merger comes with the game, since they already made that choice by downloading the game.

If the mod merging solution on my end looks like it'll delay other work too much, I may still have to rely on modders to fill the gap. But so far, this might not be too bad on my end.

Dan Fedor - Founder, Blue Bottle Games

Aiden_Hoyt's picture
Aiden_Hoyt

I was more thinking of a single Mod Merging Application, that recognizes both the Neo Scavenger format, and a smattering of symbol sets that signify the start and end of modded sections, and the ID locations to interconnect those sections to each other, it would ignore normal ID codes, allowing those to be used where the main program already has the ID for the needed function or item. intercompatibility between mods would be kind of, sideways, you could have six mods with flour, and each instance would exist separately, creating six instances of flour in the game, one thing that is a life saver, modders could be encouraged to create new scavenge hexes for the loot for their items, encouraging thought about how the items fit into the world. It would also make the game more interesting having a lot of new kinds of places to find nifty stuff.