Saving assets

[synopia]

For the behavior tree editor I need to save the modified trees somewhere and somehow. After looking into code and some chats on IRC, I came up with the following solution. Just want to talk about its pros and cons.

The behavior trees are normal assets. They are serialized into a hierarchical json structure. Using the ingame editor you can modify every behavior tree asset that is included in any active module. You may even create new trees, that become a new asset.

The worst solution is to overwrite the asset files. We don't need to talk about this, I think But the engine has an asset override mechanism. Using this, you can override any existing asset in your module. All you need to do is place the modified file into a directory below 'overrides' in your module (example).

So, when the editor needs to save a changed asset from module 'foo', a new asset is stored to the correct override directory in a special module (called 'Behaviors' for now).
Completely new behavior trees are stored into the normal asset directory of 'Behaviors'.

Now, if you set this special module as a dependency of your module, the modified assets will be loaded automatically.

To get rid of all modifications, just delete the Behaviors module. Its even possible to use git to have a history of all modifications you made (mh.. even committing changes from ingame should be possible somehow :-D).

The bad thing right now is, the write file to directory in this special module code is "hardcoded", though not very flexible or reusable (its not much code anyways, but it just does not look that good).

To create the special module for the behavior editor use:

./gradlew createModuleBehaviors

All required subdirectories are created on demand, so saving will work without the module.

 

[Cervator]

Clever!

User generated content will eventually span beyond BTs so we probably need a solid option to support it. Other possibilities include custom blocks (user makes a new block of a particular shape in-game, like by shrinking a multi-block structure, and wishes to save it), the idea of creating creatures somehow in-game, perhaps writing actual books, and so on. Maybe a natural first home would be the actual world save, then there should be an easy way to export content from there.

We probably should come up with a formal home for exported content rather than a magic module sometime - thoughts Immortius ?

 

[Immortius]

I actually don't mind a magic module, perhaps with a specific name like "prototype" - I'm assuming the intent is primarily to allow module developers to use in game editors and save their work, before adding it to proper modules. This could be a special module that can be activated for development, but otherwise left disabled (particularly in multiplayer, since clients won't be able to obtain it).

We will need to formalise the management of this module, especially if modules are going to be introducing asset types and the saving of them.

 

[Esereja]

exporting only blocks shouldn't be hard. Even text file whit names of blocks could do. Exporting entities whit them would need data type. But we could create mini save of world of given selected area, and save it in to special directory. Then in other world you culd scan that directory, sellect found save and export content to selected point. Other guestion is how will over writing happen and what if needed moduless are not enable, will content of those nonenabled modules just be ignored.

 

[Mike Kienenberger]

I'm guessing the only reason why we have Behavior Trees in the engine instead of a module right now is because of the asset interaction? I was wondering why earlier this week.