Open gsynuh opened 10 years ago
Well, for me it sounds very complicated to make an exporter for everything:
If tomorrow we want to add a new level editor (let say Cadet editor http://www.aymericlamboley.fr/blog/playing-with-cadet-editor-and-awayphysics/), it's already complicated to parse it in as3 & add it as an ObjectMaker. Adding to our air app wouldn't be always easy.
I'm not saying to get rid of the current formats and parsers we have to have only one available "importer", just to have that option ready and the format defined which means if anyone out there doesn't want to write his own ObjectMaker.fromSomeFormat function, if he sticks to the standards of our format he would be able to use the ObjectMaker.fromCitrusStandardLevelData.
sorry if it sounded like I wanted to replace everything
Oh ok, got it! That would be great indeed! (I would go for the JSON format).
Maybe we should define an Interface for the ObjectMaker so that every format can easily be implemented with this interface
@iinoxx this is my point - that requires an exporter or converter to a Citrus specific format but still we'd have a lot more control and less swf loading/parsing.
I've started looking at that as a discussion about GAF is on the starling forums.
a .fla file can be unzipped and all the animation, library, timeline symbols etc... are described in it in xml format. Which makes such an exported "easy" to create as reading a .fla would start with something like this :
using the as3commons Zip class :
var zip:Zip = new Zip();
zip.load(new URLRequest("levels.fla"));
zip.addEventListener(ZipEvent.FILE_LOADED, function(e:ZipEvent):void
{
var file:ZipFile = ZipEvent(e).file;
if (file.filename == "DOMDocument.xml")
{
trace(XML(file.content));
}
});
this xml correctly describes everything in my fla and main timeline - other xml files in the uncompressed fla (.xfl) would describe symbols more specifically, with transform matrices, shapes are described as well if we want to create physics shapes right from drawings for example, and I suppose tweens are described as well though I'm not sure how yet.
the hard task right now is 1.having a simple parser that roughly works for most levels currently designed for CE 2.from that decide on the Citrus level format - in json
such exporter could even actually build texture atlases - this would mostly be the work flump does however because flump reads the .fla file similarly to build its final texture atlases and animation data.
the .xfl file format is 3 years old now, I'm impressed these tools are only becoming popular now - also thinking that actually exporting an entire flash movie to html5 is not that hard considering all the data is just under our eyes and flash pro just becomes a great wysiwyg editor.
wouldn't it be great for CitrusEngine to just load up an xml file or json file with level data in it that would either be extracted from a .swf file, or even come from a level editor - the good thing here is everyone would be using the same structure/format and terminology so that anyone would be able to build an editor or a little air app that would transform a .swf level into xml/json with the correct format so that one would not have to load and parse a swf at runtime.
One could also transform the .xfl file format into a CitrusEngine readable format - thus needing only one object maker, and opening ourselves to simple level editors as well (its not the point here, I just find that loading a swf and parsing it just sounds like a bit hackish and CitrusEngine deserve its own data format for a lot of good reasons)