Mod compatibility

[bitbrain]

Games like Rim World allow for modding where modders can setup an XML file (e.g. in MyModName/Defs/**/*.xml) that magically turns on new items. Data in Pandora is usually stored inside the res:// folder and when running Pandora as part of a game on initial load, data gets loaded from the data.pandora file only.

ModLoader Autoload

For such a mod to properly work, data could be created at runtime by accessing the Pandora GDScript API:

# some autoload script called 'ModLoader'

const DATA_DIRECTORY = "usr://Defs/"

class EntityPropertyFromFile:
   var property_name:String
   var property_value:Variant
   var property_type:String
   var category_id:String

class CategoryFromFile:
   var category_name:String
   

class EntityFromFile:
   var entity_name:String
   var category:String
   var properties:String


class EntityDataFromFile:
   var entities:Array[EntityFromFile]
   var categories:Array[CategoryFromFile]
   var properties:Array[EntityPropertyFromFile]

func _enter_tree() -> void:
   # lets load the mod data from disk into GDScript model
   var entity_data = load_all_from_directory(DATA_DIRECTORY) # Array[EntityDataFromFile]
   # register categories
   for category_data in entity_data.categories:
      var category = Pandora.create_category(category_data.category_name)
   # register properties
   for property_data in entity_data.properties:
      var category = Pandora.get_category(entity_data.category)
      var property = Pandora.create_property(category, property_data.property_name, property_data.property_type)
      property.set_default_value(property_data.property_value)
   # register entities
   for entity_data in entity_data.entities:
      var category = Pandora.get_category(entity_data.category)
      Pandora.create_entity(entity_data.item_name, category)

While this would work kinda fine, every developer trying to pull this off would need to do this extra step and figure out a good standard to parse/save/load entities themselves.

Designing in Pandora to export as mod

An idea I had was that someone could e.g. design items and other data inside Pandora and then simply "export" their setup into a mod-compatible file. Pandora then could provide functionality (maybe even a mod loader coming out of the box?) being able to parse these files.

Entity ids

Pandora currently generates unique IDs based on auto-increment for entities. The problem is that depending on the current maximum ID inside the data.pandora file, the entities created by a mod file may have different ids each time. When e.g. in a save game we store a reference to an entity loaded with a mod, the id of the modded entity can change and thus not finding the entity any longer! Also, persisting modded entities somewhere also does not help, as the data.pandora file may suddenly contain entities with the same ids, leading to even worse issues.

One way to solve this could be to move away from auto-incrementing ids to something like UUID - @eth0net suggested using NanoID - for mods we can also introduce namespaces/ID prefixes.

EDIT this has been addressed in #100 and Pandora now supports both integer ids (default) and nano ids.

Q&A

Q: What is multiple mod files have conflicting setup

A: Pandora is build in a way that it would create duplicates - so conflicting setups would just work alongside one another.

Feedback and ideas weldcome!

[eth0net]

Thanks for opening this up!

I think moving over to unique IDs would be a good idea regardless of modding support, perhaps NanoID might be interesting if there's a Godot implementation 👀

You could also look at name-spacing
IDs, so each pandora bundle could be assigned a bundle ID or name and then each resource ID only needs to be unique and consistent within the bundle.

I'd envision a path something along the lines of usr://mods/mod_name/data.pandora for a default mod/data path. It may be nice in the future for game devs to be able to specify paths for their mods directory and data files, though the default would be a good MVP.

It could also be worth adding a secondary path such as usr://dlc/dlc_name to facilitate data files for DLCs released for the game but not included in the base code 🤔

I really like the idea of being able to create the mod data files inside Godot using Pandora as this should make it nice and easy for modders to get it right. Though I may look into what it would take to create json specs for Pandora/games and the like so people could do it inside any code editor that supports those if they wanted.

Sounds like a great feature to be added, once it's all planned out 🚀

[eth0net]

So I ended up making a nanoid implementation for fun today 👽 https://github.com/eth0net/nanoid-godot

[eth0net]

Working on proper docs and refining it, but feedback welcome!

[bitbrain]

One problem is the way addons load at the moment. Ideally, we want to copy-paste that code into Pandora as having other addons as dependencies is not possible due to the lack of package management in Godot.

[eth0net]

Ah interesting, that's fine though, I'm making it MIT same as the original nanoid ^^

[eth0net]

I realised it doesn't even need to be a plugin, just a script in an addon directory - so shouldn't be an issue with load orders now. I'm still happy for the code to be pulled into Pandora though :)

[eth0net]

#84 could help out here as well, if game devs could export their types so that modders could import and build upon them in their own bundles of pandora data

[eth0net]

It would be worth ensuring compatibility with Godot's PCK export system, which allows developers to support mods and dlc inside the Godot engine already.

I now suspect content pack loading (mods + DLC) would need to be a wider implementation than Pandora should take ownership of, leaving a lot of the implementation to the developer.

However, I would envision most games having something like res://dlc/ and user://mods/, loading files in, and passing them to Pandora etc.

The flow could look something like this:

1. Game checks for dlc and mods
2. Game opens PCK files in each
3. Game loads each file, passing data to Pandora as appropriate
4. Game finishes init and is playable

With that kind of flow, Pandora needs to support loading Pandora files at runtime via the API and merging it with existing data.

This approach leaves mod implementation down to the developer, allowing them to handle things like load order, compatibility checks, directories, and much more.

Personally, I'd expect to see it look something like this:

res://dlc/
\ dlc1/
  \ dlc1.pck
user://mods/
| mod1/
| \ mod1.pck
\ mod2/
  \ data.pandora

With an open implementation, you can create any content structure and load Pandora files from both PCK files and directories depending on user preference, without extra complexity in Pandora.

[MargoMoska]

👍