# “Industry Standard” JSON formats for game assets [closed]

This question is inspired by my venture into the Phaser game engine but seems to apply to any engine that uses JSON for its asset format.

Phaser relies on PhysicsEditor to export and create the JSON data for its physics bodies and TexturePacker for its sprite atlases. When I learned this I found some free alternatives that look like they might do the job.

So here's the problem. These JSON creators claim their output works for a slew of different engines, but how can I be certain of that when there can't possibly be such universal collaboration between the creators of these engines? It's especially dubious considering I can't find a standard anywhere. I don't want to rely on a solution only to encounter a glitch I don't understand. I want certainty.

After a lot of searching I finally found this thread, in which a couple of posters also expressed these frustrations. The final post appears to come from the horse's mouth, explaining that there's some "industry standard" that everyone uses, but the poster doesn't seem to know where the industry standard comes from either.

So I'd really like to know, is this specification actually documented anywhere? Does it have an origin or did it just... accrete?

If there's no good answer to this question, can I at least trust the claims of, say, Physics Body Editor and Shoebox, that their exports will work anywhere?

## closed as too broad by congusbongus, Vaillancourt♦, Kromster says support Monica, Josh♦Feb 8 '16 at 16:40

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

• It looks like the answer to your question is present in the post you mention: "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!" - ie. this doesn't appear to be a documented official standard, but rather an emergent convention of using the same format as other software already on the market. – DMGregory Feb 2 '16 at 0:11
• But the poster doesn't know for sure. Anyway, where do engine developers get the spec? Do they reverse engineer it from TexturePacker / PhysicsEditor? – MackTuesday Feb 2 '16 at 0:31
• Too broad? My questions are pretty much yes/no. – MackTuesday Feb 12 '16 at 2:38

I am Andreas Loew - creator of TexturePacker and PhysicsEditor.

We define the export formats for our tools depending on the needs of the framework developers - in most cases we simply adapt to formats that are already available.

Most of TexturePacker's data formats are template based - you can adjust it to whatever you need.

We also have 3 generic data formats: XML, JSON Hash and JSON Array.

I currently don't remember which framework we created the format for but it was it 2011-02-14 - TexturePacker's 2.1.5 release that contained the format.

In case of Phaser we've also created clones of the JSON format "Phaser (JSONArray)" which export the same data format but do restrict the features that are available in TexturePacker. Phaser does not support polygon packing and pivot points - features that are recently available in the generic exporters.

We also work close with the framework developers to add new features - which might also extend the format. E.g. TexturePacker 4.1.0 next update will contain a pivot point editor - so the format has to be extended. We'll also make sure that the new extension is used by as many frameworks as possible.

This is how a basic entry looks like:

"Blue Key.png":
{
"frame": {"x":1,"y":1,"w":117,"h":207},
"rotated": false,
"trimmed": true,
"spriteSourceSize": {"x":70,"y":46,"w":117,"h":207},
"sourceSize": {"w":256,"h":256},
},


frame: The position of the sprite's data in the texture (in pixels) rotated: If the sprite is rotated in the texture. Clockwise by default. Might differ for some frameworks which rely on counter clockwise rotated sprites. trimmed: True if transparency was removed from the original sprite. spriteSourceSize: The non-transparent part of the sprite that is used in the frame. Additional space around the sprite is transparent. This value unfortunately contains redundancy because the w and h value is identical with the frame's w and h. sourceSize: The original size of the sprite including the transparency.

pivot "pivot": {"x":0.5,"y":0.5}

The pivot or anchor point of the sprite - relative to the sprite's size - 0.5/0.5 is the sprite's center. Might also be outside of the sprite. This value is optional.

polygon mesh data

    "vertices": [ [178,118], [215,168], [200,237], [159,256], [97,256], [64,218], [56,167], [86,124], [124,111] ],
"verticesUV": [ [799,54], [836,104], [821,173], [780,192], [718,192], [685,154], [677,103], [707,60], [745,47] ],
"triangles": [ [5,7,8], [5,6,7], [3,5,8], [3,4,5], [1,2,3], [1,3,8], [0,1,8] ]


Contains polygon mesh data of the sprite, split in triangles. vertices contains the vertices in sprite coordinates, verticesUV the vertices in texture coordinates and triangles index triplets which build the triangles.

Polygon meshes will most likely not be adopted by HTML5 game engines too fast - at least not as long as they have a fallback on Canvas sprites (which are rectangular) but will work well with WebGL renderers.

... so much for the data format.

But I agree: We should document the format so that people can rely on it.

Best Andreas