First draft of hexaworld schema

[andrewosh]

This is an untested first draft of the schema. Right now everything's inside one monolithic object, but the various independent components (basic, geometric, game) should be split up into separate schema files. Also, this is all in javascript using the jsonschema npm module, but for portability it should be a set of actual .json files. That will be a simple conversion.

There are a number of places where I put questions in comments. A few ones off the top of my head:

1. How should we represent textures?
2. This is certainly not the most efficient representation of a hexaworld, but I don't think that's a problem considering the map sizes we care about.
3. How flexible should we be when it comes to specifying shapes/objects? Right now I have schemas for some simple shapes, and then a catch-all polygon definition (using a triangular mesh). Seem good?

[sofroniewn]

Should update to "main": "hexaworld.js"

[sofroniewn]

Shouldn't position be added into transformation too

[freeman-lab]

It might be easier to reason about some of this if you also added a couple example json files that satisfy the schema?

[sofroniewn]

Why have a separate rectangle that is not just a polygon?

[andrewosh]

Just as an example because I imagine it'll be the most commonly used polygon. Think if anything we should add more specific polygons, because it'll make it easier to see what kind of shape there are in a tile.

[sofroniewn]

Ok - I get that. Can this be done in a way that it shares some features of polygon. Maybe want to be able call polygon with a center and a number of sides to generate a regular polygon (pointy top / flat top)

[sofroniewn]

I guess that's not part of the schema though

[andrewosh]

Hmm I guess I was thinking polygon would just let you specify faces if no other shape cuts it. polygon, rectangle, ellipse and any other specific implementations all extend the shape schema, which could have a center (or just a translation, and all shape centers are assumed to be the upper-left corner or something).

[andrewosh]

I'll have some examples tomorrow 👍 . For now, any issues with the high-level approach? Nick and I talked a bit about pros and cons of restricting all objects to be in tile sections (instead of defining a pixel-based coordinate system for the inside of the tiles), but I don't remember that being resolved.

[andrewosh]

Oh, one more thing, all the objects at the top level of the definitions section are just sub-schemas that are there for convenience. When it comes to actually writing instances of the schema, the only fields that will be present are the keys of theproperties.

Nobody is going to be seeing axialCoord or pixelCoord (or whatever we change those to) in any hexaworld instances. Defining those in one place just makes it easier to reference later in the full schema definition