Hi all,
Long time no see, I know. Anyway, some quick info, they use json for the scene data, and probably YAML for particles and atlases. What totally puts me off is, it's a jar, hence some time slow to work with, it's still in alpha though.
A couple of the guys here are working on an editor each as well.
This could have some potential as well. I had a look at the documentation. If the author allowed plugins so we could write config import and export, we could make a plugin to work somewhat natively with orx.
Good to see you too. Indeed it seems interesting. From their site
Make vast level landscapes, puzzles, UI elements, effects and physics environments. Export that all to an open JSON format. And then use any engine or programming language that fits best for your game in order to bring it all together.
Also I could find no plugin but runtime. So they are going Spriter or Spine way, instead of exporting for different engines. They just provide one format, developers then use runtimes based on target engine. Currently only libgdx runtime. Either we use a overlap2d to orx config converter, or load them by code through some helper functions or might generate config on the fly and use that.
I am not a fan of converters tbh. Converters are too specific, adds extra layer of manual work which hampers the work flow imo.
Yep no fan of converters either. I've done a couple for inkscape and darkfunction to orx. But in hindsight, I should have learned the APIs to integrate a plugin.
I wasn't confident at the time.
I noticed talk of various plugins being discussed in their forum so it does seem possible.
Yeah I think that was the reference. Though I am unclear on what a runtime is in this context. I know only enough about java and gradle to be dangerous. I saw this reference:
But really, if it means keeping the output configuration in json format, and a runtime added to an orx app to convert on the fly... not a fan of this approach at all.
But at a fleeting glance, I don't know if this is what is going on.
So in the cocos example, does the runtime to write act as an exporter/importer within Overlap or as an importer for your own application?
There is currently no export or import option in overlap2d, will not be in the future as the developer wants to make it independent of any engine.
So, it's the later case, provide an importer for your engine. Like spriter or spine. They don't export engine specific data, instead engine developers provide runtime/importer for their own engine.
There is currently no export or import option in overlap2d, will not be in the future as the developer wants to make it independent of any engine.
So, it's the later case, provide an importer for your engine. Like spriter or spine. They don't export engine specific data, instead engine developers provide runtime/importer for their own engine.
That's a shame because it will greatly reduce the uptake. Every project that uses orx needs to implement their own runtime to use overlap formatted configuration. I doubt many would bother.
On the flipside, if there was a plugin API, one person could write an importer/exporter for overlap2d and it then becomes available for all to use for all orx projects.
I tried to find their IRC channel to ask about it but it's no longer around. I might make contact with the developer via email and ask.
Got some trouble signing up, but made it eventually
So yeah, Overlap2D does have an open API plugin system that you can use to achieve your goal. The idea would be to create a ORXExport plugin, that will listen for overlap2D export event. And as soon as it fires (user pressed export button) create a data file according to your needs.
You can either, parse our JSON, and re-save it in other format. Or you can take directly the engine entities data and component and save your format from there. Then your engine can take it from there.
Even more awesome would be of course to create a "template export" plugin so that everyone will benefit from it. It will take the data, and then save it to provided template. But, while being the best idea ever, I do not see why you guys would want to take the burden )
Only issue with creating the plugin is that there is no official docs on making plugins yet. But, I can help you out. And most importantly there are several open source ready to use plugins that you can just mimic.
You can copy paste this sources, rename it to your plugin name, then make sure it listens to this event: com.uwsoft.editor.view.Overlap2DMenuBar.EXPORT
Then when it happens retrieve the engine, by calling getEngine on plugin main class. That will be a simple Ashley engine, that allows you to retrieve all entities on the scene and their components which describe all the properties. From there you con save that data in your own format.
Then, you put your compiled .jar file in "plugins" folder of overlap2d and that's it.
Indeed, thanks for taking the time to write a detailed reply here, azakhary!
I haven't touched Java in over 17 years now, so I'm probably not the best candidate to work on such a plugin.
Looking forward to giving Overlap2D a spin soon in any case.
Comments
Long time no see, I know. Anyway, some quick info, they use json for the scene data, and probably YAML for particles and atlases. What totally puts me off is, it's a jar, hence some time slow to work with, it's still in alpha though.
Looks like an interesting project.
A couple of the guys here are working on an editor each as well.
This could have some potential as well. I had a look at the documentation. If the author allowed plugins so we could write config import and export, we could make a plugin to work somewhat natively with orx.
Also I could find no plugin but runtime. So they are going Spriter or Spine way, instead of exporting for different engines. They just provide one format, developers then use runtimes based on target engine. Currently only libgdx runtime. Either we use a overlap2d to orx config converter, or load them by code through some helper functions or might generate config on the fly and use that.
I am not a fan of converters tbh. Converters are too specific, adds extra layer of manual work which hampers the work flow imo.
I wasn't confident at the time.
I noticed talk of various plugins being discussed in their forum so it does seem possible.
http://overlap2d.com/using-new-runtime/
But really, if it means keeping the output configuration in json format, and a runtime added to an orx app to convert on the fly... not a fan of this approach at all.
But at a fleeting glance, I don't know if this is what is going on.
So in the cocos example, does the runtime to write act as an exporter/importer within Overlap or as an importer for your own application?
So, it's the later case, provide an importer for your engine. Like spriter or spine. They don't export engine specific data, instead engine developers provide runtime/importer for their own engine.
That's a shame because it will greatly reduce the uptake. Every project that uses orx needs to implement their own runtime to use overlap formatted configuration. I doubt many would bother.
On the flipside, if there was a plugin API, one person could write an importer/exporter for overlap2d and it then becomes available for all to use for all orx projects.
I tried to find their IRC channel to ask about it but it's no longer around. I might make contact with the developer via email and ask.
Got some trouble signing up, but made it eventually
So yeah, Overlap2D does have an open API plugin system that you can use to achieve your goal. The idea would be to create a ORXExport plugin, that will listen for overlap2D export event. And as soon as it fires (user pressed export button) create a data file according to your needs.
You can either, parse our JSON, and re-save it in other format. Or you can take directly the engine entities data and component and save your format from there. Then your engine can take it from there.
Even more awesome would be of course to create a "template export" plugin so that everyone will benefit from it. It will take the data, and then save it to provided template. But, while being the best idea ever, I do not see why you guys would want to take the burden
Only issue with creating the plugin is that there is no official docs on making plugins yet. But, I can help you out. And most importantly there are several open source ready to use plugins that you can just mimic.
here is the link to a sample plugin: https://github.com/UnderwaterApps/overlap2d/tree/master/plugins/performance
You can copy paste this sources, rename it to your plugin name, then make sure it listens to this event: com.uwsoft.editor.view.Overlap2DMenuBar.EXPORT
Then when it happens retrieve the engine, by calling getEngine on plugin main class. That will be a simple Ashley engine, that allows you to retrieve all entities on the scene and their components which describe all the properties. From there you con save that data in your own format.
Then, you put your compiled .jar file in "plugins" folder of overlap2d and that's it.
I haven't touched Java in over 17 years now, so I'm probably not the best candidate to work on such a plugin.
Looking forward to giving Overlap2D a spin soon in any case.