The default Sphere map engine, even with the enhancements made to it in minisphere, is beginning to get a bit long in the tooth.  It's not object-oriented, and extending it often requires awkward hacks.

I would like to introduce a new map engine with minisphere 4.0, one coded in JavaScript from the ground up which is designed from the start to be extensible but nonetheless includes a great deal of functionality out of the box (in order not to sacrifice Sphere's biggest strength of being easy to pick up and start programming).  So I'm posting this thread to gather ideas and see what people would like to see in a map engine.

I'm in favor, though I do have some concerns.

Let's assume that there will be some ability to convert, either implicitly or explicitly, Tiled-format maps to Sphere or otherwise write in treating Tiled as native somehow. How do we handle things like per-tile obstructions (especially if we implement a thing like entrance/exit obstructions), possible terraforming, and such if the format ends up so wildly different in implementation than the original Sphere map format? Do we attempt wrappers or bridges, or do we force Tiled hexagonal pegs to fit into Sphere's square holes?

What will be the approach, and how much of it will be C/C++, how much in script?

Theoretically, the whole thing can be done in script, provided the engine has sufficient API surface area to do so--and thanks to things like Galileo and the FileStream API it should.  Responsibility for loading resources like spritesets, tilesets, etc. can also easily be moved to script since deep down they're just collections of images.

As for Tiled, your point is well taken, and is one of the big reasons Tiled support hasn't made it into a release yet: It supports all different kinds of tile shapes, customizable render order, etc. that I would either need to support or just take a hardline and say "Nope, you can't use that feature, sorry".  For some features this is reasonable: Few would complain if we said we don't support hexagonal maps, but on the other hand placing restrictions on more superficial things like render order (to, say, RightDown-only) to ease implementation might come off as somewhat arbitrary.  So it's a fine tightrope to walk.

As for terraforming, it was my understanding that that's something typically handled by the map editor, not the engine?

An alternative to Tiled support directly in the map engine would be to implement a converter in, say, Cell, which converted Tiled maps to a more Sphere-friendly format.  If we do it that way, then any restrictions on which Tiled features are supported might be a bit easier to swallow--the compiler would tell you ahead of time your map is unsupported, rather than not finding out until the game actually tries to load it.