Format of the JSON files Phaser uses for loading?

[ForgeableSum]

I've encountered this problem before where I want to create a JSON file and pass it to a Phaser function, like addPhysicsData in P2 physics or the JSON for a sprite atlas, but there is no where in the docs which indicate how the JSON should be structured. I'm left piecing things together from the examples.

 

I realize that most devs use physics editors and sprite editors, and it would be ludicrous to not rely on those tools which have Phaser export options (like Texture Packer), but I still think the format should be documented somewhere. It somewhat implies Phaser is reliant on third-party software. 

 

In my particular case, I'm experimenting with generating data on my own from an in-game editor (it's complicated, I won't go into detail) but I'm sure a lot of devs like me want to build their own tools instead of relying on third-party generic software.  Even just links to example JSONs would be better than nothing. Does anyone else feel this way or am I the only one?

[rich]

Phaser is entirely reliant on 3rd party software for these files. I've never seen an official definition of the structure of either the Lime/Corona physics files or Texture Atlas JSON files, but as all packages seem to export in the same way I guess it exists somewhere.

[ForgeableSum]

Phaser is entirely reliant on 3rd party software for these files. I've never seen an official definition of the structure of either the Lime/Corona physics files or Texture Atlas JSON files, but as all packages seem to export in the same way I guess it exists somewhere.

If all the packages export in the same way, why does Texture Packer have a JSON format specifically for Phaser? I mean, to create the export feature they must get their info from somewhere. 

[MikeT]

If all the packages export in the same way, why does Texture Packer have a JSON format specifically for Phaser? I mean, to create the export feature they must get their info from somewhere. 

 

I think this is more of a UI, ease-of-use decision since the output is identical to non-Phaser JSON Hash and Array exports.  The Phaser options are labeled as "Phaser (JSONHash)" as opposed to just "Phaser" like the other options which also hints towards it being a re-labelled Generic JSONHash and Array export.

[AndreasLoew]

We've added Phaser exporter to TexturePacker because it makes it easier for users. Who would search for "JSON hash" when using Phaser?

The format is the same...

Btw. you can either use Hash or Array - it should not make any difference.

[ForgeableSum]

I suppose "formatting" isn't the right term for what I'm looking for. Let me explain by example. Say you have the following your sprite's JSON:

{"frames": {"attackE0001":{"frame": {"x":528,"y":101,"w":36,"h":47},"rotated": false,"trimmed": true,"spriteSourceSize": {"x":49,"y":26,"w":36,"h":47},"sourceSize": {"w":107,"h":138}},}}

If I didn't have a tool like texture packer to create this JSON, how would I know that the properties need to be labeled: "frame," "rotated," "trimmed," etc. After doing a bit of digging, I deduced that these properties closely parallel Phaser.Frame and are interpreted internally by Phaser to create the frame data collection, but the actual naming of the properties in the JSON is very implicit. If you wanted to put these files together manually or with your own tools, you'd have to study Phaser's source code or the output of third-party tools such as Texture Packer, correct? 

 

Do other libraries use the same naming scheme to create frame data? The JSON Hash format I could see but the actual naming of the properties - I'm thinking that's specific to Phaser.  I understand why it's not documented though - it would be a pretty rare case where someone would have to manually assemble these files. 

[mibel76]

I too, I'm trying to find the specifications of these files, unfortunately seems that it is a the most well kept secret in the world, I guess if the NSA know something about it... or maybe even the program's authors don't know what they means and simply mimic the ouput of some other program.

 

About the format, I deduced, by trying things, that the "frame" property is the only required entry. The meaning of its properties is really easy to understant, they are the coordinates and dimensions in pixels of the tile inside the image, with x=0 y=0 being at the top-left corner. "spriteSourceSize" and "sourceSize" seems redundant and so far I saw them being equal to each other, maybe they are related to the "trimmed" property altought it isn't clear what it means (trimmed, what ? I gave you the exact dimension, what more trim you want to do ?). Also rotate isn't very clear, rotate respect to what ?

 

In your case:

{"frames": {  "attackE0001":  {    "frame": {"x":528,"y":101,"w":36,"h":47}  }}}

Should be enough to make it working and save a lot of typing.

 

 

 

it would be a pretty rare case where someone would have to manually assemble these files

 

Maybe it isn't clear that any program who want to be compatible with these files needs to know how to create them. Writing these files by hand is just an option, what if I want to write my own texture packer or game programming environment and want to write these files ?

 

Hope this helps.

[rich]

Do other libraries use the same naming scheme to create frame data? The JSON Hash format I could see but the actual naming of the properties - I'm thinking that's specific to Phaser.  I understand why it's not documented though - it would be a pretty rare case where someone would have to manually assemble these files. 

 

No it's not specific to Phaser at all. The property names used in Phaser were chosen because they match the JSON format that software like Texture Packer exports to. It's not just Texture Packer - Shoebox, Adobe Flash CC and various other tools all use the exact same JSON structure. We just adopted it because it's the "industry standard" way of defining a texture atlas.

 

It's entirely possible that it was Texture Packer that was responsible for creating this json format in the first place (and thus creating the 'standard' themselves by being the first to define it) - but as everyone else appears to have adopted it that's good enough for me!

[Dave Newton]

Hello,

A simple description of this json format in the Phaser documentation would be a great help for third party animation software developer wanting to export for Phaser.

Having to reverse engineer Texture Atlas is a bit rough :-)

[rich]

It's not a format we ever devised though. You should find one on the Texture Packer site, but if not, then I'm not sure where it'd be.

[Dave Newton]

I'm very confused, when I go to the Texture Packer website, it seems that these JSONHash and JSONArray were made... for Phaser!

Sounds like a egg and chicken problem :-)

[rich]

Nah I promise it wasn't. JSON Array / Hash existed long before Phaser did. What you're seeing in that screen shot is just that the Phaser export is based on those (if you scroll down further, you'll see JSON Array / Hash are listed on their own too, under 'generic')

[Dave Newton]

Either way, I found the starling xml format description ( http://doc.starling-framework.org/current/starling/textures/TextureAtlas.html ). Not sure, it's the best, but at least it has a serious documentation.

[rich]

Yeah Starling created their own format, so had to document it really. Where as I used an already existing one, and had to figure it out from the exports. And when it changes which it sometimes does we update the Loader code accordingly.

[rich]

If you look at the Phaser.Frame class source code you'll see nearly all of the json mappings explained. Adobe Animate exports in the same format too, they may have docs.