Wish: Explicit kind of object field.

[badquanta]

Just as a wishlist item, I was thinking that it could be nice if Objects explicitly stated their "kind".

At the moment it seems to me in order to detect what type of object something is, I must detect what it is not.

For instance, in order to determine an object is a Rectangle, I must first determine it is not an ellipse or a point, that it has no polygon points or polyline points, and that it does not have any text and does not have a GID.

So my (psudo) code for handling objects right now is, it seems to be working:

if(obj.gid) {handleTileObject(obj);}
else if(obj.ellipse) { handleEllipse(obj); }
else if (obj.point) { handlePoint(obj); }
else if (!obj.polygon.empty()) { handlePolygon(obj); }
else if (!obj.polyline.empty()} {handlePolyline(obj); }
else if (!obj.text.empty()} {handleText(obj); }
else { handleRectangle(obj); }

It just seems to me it would be more straight forward if the "kind" of object was explicitly stated in a field instead of trying to "deduce" what kind it is. At the moment if any new kids of objects are added in the futre, my deduction logic could easily break... and there is no good way for me to tell if the type of object something is may be a type I do not (yet) support.

[bjorn]

Hmm, this is indeed a shortcoming of the JSON file format, though the situation is similar in the XML format, where we need to look for the presence (or absence) of certain child elements.

In the scripting API, we have the MapObject.shape property, which tells you whether an object is any of these shapes. The only object type that still requires an additional check is the tile object, since it's a rectangle object with a tile set on it (even though it also behaves rather differently).

The main reason a "shape" property does not exist in the JSON and XML formats is because Tiled grew dynamically and there was no real need to add such a property. If we add it, it would certainly not be possible for Tiled itself to rely on it, given that it needs to stay backwards compatible. But we could consider adding it to make life easier for other parsers.

[badquanta]

I understand the need for backwards compatibilty. It would be nice if the object's shape were more clearly communicated. I would hope that extra information would be both easy to emit; and easy for parsers not supporting it to simply ignore. Perhaps that is a foolish hope. :)