Isometric and some questions

[MannyC]

I've been looking into adapting phaser-tiled to support isometric tiles. I've hacked in some changes which have been working so far. I was looking into doing it using Phaser's implementation but the way this plugin did its rendering made more sense to me.

My general thinking is to just adapt the various points to cope with isometric tiles/coordinates. Generally this consists of:

• When placing a tile that at MX,MY (map x, map y) project that tile onto the world via a function (currently it just multiplies the MX by the map tile width etc).
• Update the render region to support an isometric region. This seems like the iffiest bit, but I think it can be done by changing the render region from x,y,w,h to a set of four coordinate pairs. Orthographic would assume it's a standard rectangle, isometric would do its own calculations.
• I think the _renderRight etc functions can be adapted, in so far as if you're scrolling right then there is a limited set of tiles that will be scrolled into view, they just won't be as simple as grabbing a map column. The pool size might be tricky to size using the current method, as the number of edge tiles can change, but it's easy to work out how many can possibly be on the screen + buffer.
• Map width in pixels etc will have to support iso, this is quite simple.
• Render order will probably have to be supported, as 2.5d is very common in iso games. I'd plan on doing a basic approach at first, assigning a number to each tile as they're put on the screen and letting the groups sort function sort it out from there. It seems likely that this can be improved seeing as we can work it out during the _renderRight etc functions but I'd consider that step 2, and might not be necessary. If sorting turns out to be slow it could be opt-in.
• I haven't considered physics at all yet.

Thoughts on the above strategy and its sanity?

Also, while reviewing the code to get to grips with it, I've come across some things I don't fully understand yet. It seems that this was originally based on Phaser's Tilemap implementation, and it seems to still have some leftover code. Mainly this seems to be some overlapping of functionality between the classes. For instance, I'm not sure what the Tile class is doing. It isn't used by the Tilelayer class, only by the Tilemap.putTile method, which isn't actually called by the plugin itself. There seems to be some very similar looking code in the Tilelayer class and the Tile class, and it feels like the Tile class perhaps should be there at all (or should be used by Tilelayer instead of it using Sprites). I don't want to make too many potentially far reaching changes around this, particularly when I don't understand all of the plugins uses, but if we're implementing iso then the less code that has to be considered the better.

I know that performance is a concern. Do you have a base tileset/map we can use as a benchmark?

Also, is the general thinking to support Tiled maps + additional features, or to be a general Tiling engine that happens to support Tiled maps?

Anyway, just starting a conversation about all this.

[englercj]

Cool thoughts, I think this seems reasonable.

As far as testing I generally use this set of test Tiled maps: https://github.com/englercj/phaser-tiled-tests

It seems that this was originally based on Phaser's Tilemap implementation, and it seems to still have some leftover code.

Less based on, and more "trying to emulate". I think I will abandon that in v3 because it causes a lot of confusion and isn't really helpful.

For instance, I'm not sure what the Tile class is doing.

Not much, it was used previously but I forgot to remove it in recent versions :P

is the general thinking to support Tiled maps + additional features, or to be a general Tiling engine that happens to support Tiled maps?

Great question, I think I have been going with Tiled maps + additional features. Generally it is more specifically: Tiled maps with extra property support to be able to configure Phaser features from within Tiled.

I'm planning v3 which will remove the "sprite-per-tile" mentality in favor of a custom renderer for each type. A single shader for webgl and some custom tile placement for canvas (probably similar to current method but with some buffers). Also will abandon the "drop in replacement for built-in phaser tilemaps" and just do a better API that makes more sense for this plugin and its use-case.

[MannyC]

That's great. I'll write more as things move along/I investigate more.