Cammin
commented
1 year ago There have been some mentions about this in #15 , but basically, it would be a pretty decent undertaking.
The import code is tightly tied with editor code, and created without runtime generation regard in mind. That said, it's certainly doable with enough time and energy.
Most of the importer code can work outside of the editor space. However, the largest changes would need to be in where assets are being supplied for the project/level builder to get assets like tiles/textures/sprites from. I'll call those, inputs.
The builders are given various inputs supplied through the editor, to create the GameObject product. So, to make it possible to generate ldtk projects in runtime, we need to still supply all of those inputs, but in a different way unlike how the editor supplies them.
Some of the inputs include:
- A deserialized project json + level json if separate levels.
- Tilesets (pairs of sprite/tile), + physics shapes
- Level background textures
- IntGrid value tiles and their correlations prepared
- Entity prefabs and their correlations prepared
When making this feature, I would want to respect the current code as much as I can, so I'd want to have some kind of interim asset provider. Something that supplies all of these inputs but in a different way that can be interfaced by the editor, but also in runtime, whether fully through code or some kind of collection of ScriptableObjects with pieces of data that the level builders simply use without a hard-dependency on a ScriptedImporter of any kind.
In terms of players being able to edit levels and export ldtk files by serializing back to json, It is untreaded territory for me. I'm primarily in an environment where I deserialize the json file and tell the AssetImporter what to do with it. I rarely serialize back; when I've tried to serialize and deserialize json files in the past, the file is unable to be opened in LDtk anymore. It could be my json library. I could be mistaken, and this may work with enough research/digging, but that's where I currently stand.
Rules are its own feature, but also feel attainable in the current editor-strict environment, and I'd want to create support for runtime rules first before tackling runtime building.
I'm currently focusing my free time on personal projects, but if I can have a way to make this an easy and seamless process without groundbreaking changes, then I'm all for it! In all honesty, if I start digging into it, I'll find a lead that I'm happy with, and have something figured out. But, I'm firstly focusing on other work at the moment.
I would say; If you need the feature pretty soon, then feel free to browse the codebase of this repo and see if you can cobble together something that works for your own project's specific needs.
Let me know what you think 🙂
max-critcrew
Hey @Cammin!
We absolutely love your work and we currently try to implement runtime level editing for easy/quick iteration and maybe later on for our players. How hard would it be to get this to work? Or back to work (I read that it was considered once!)
It would definitely require the rules to resolve at runtime, but what else would be required to make it all work completely?
Kind regards, Max