System to build terrains by combining objects with a floor

[NQNStudios]

Similar to #413, I would like to see all terrains that are statues, runes, dead bodies etc., to be represented by graphics with transparency, and the scenario editor let you composite any floor graphic you want with an upper layer to make a custom terrain graphic.

EDIT: The term I was trying to remember is "Foreground elements"

[CelticMinstrel]

I've definitely thought about this as well – it's a bit surprising if there isn't already an issue about it.

[NQNStudios]

I just saw that in the picture picker, you can choose a bunch of graphics that use baked-in floors and objects:

There's simply no way for us to emulate that without keeping the baked-in graphics in some capacity--because there's no context there to infer a floor from, just a graphic index.

[CelticMinstrel]

I don't understand what you're trying to say here. There's no way to do what exactly without keeping the built-in graphics?

[NQNStudios]

No way to support a scenario which already uses one of those terrain graphics in a special node.

[CelticMinstrel]

Hmm… you actually have a good point there. Using terrain graphics in special nodes would become far more difficult if we implemented this, as you usually need to specify two picture IDs instead of one…

[NQNStudios]

But I think leaving the graphics that already exist alone can preserve the existing behavior, and we just add new graphics for the split/transparent new versions. So old scenarios do things the old way, and new scenarios do them the new way. And maybe new scenarios can also just reference the old sheets in the picture picker until we find an important enough reason to make that more flexible?

[CelticMinstrel]

Well, new scenarios would still have to do things the old way though, since adding a new field to special nodes just for this seems kinda silly.

[CelticMinstrel]

While going through all the terrain graphics, I thought of another possible way to do this. We can do all the auto-tiling in the editor (perhaps with some option to temporarily turn it off) and have the editor insert a "variant marker" into the map to specify which of the 13 graphics (or even 16, or 47, or perhaps more) is to be used.

I also happened across this article which seems very relevant. I also found a StackExchange post linking to an old article that briefly touches on 3-terrain transitions.

[CelticMinstrel]

Further thoughts on this…

Firstly, I'm thinking we should stick to 16-tile auto-tiling (the one called "marching squares" in this article) to begin with, because that's what all our existing auto-tiles conform to. They are all missing the 2 double-corner cases, but I think those could easily be synthesized by mashing two of the existing ones together. If we want, we could later on add support for other types (I'd probably say RPGMaker-styling rather than the 47-tile system, which the above article calls "sub-blob", as it has about the same coverage but only uses 20 tiles, and those 20 tiles fit into 5 slots on the sheet). I think surface water might be a good candidate for conversion to this system, since it has the "small island".

Secondly, I'm thinking we could have a terrain type with auto-tiling enabled look for a graphics sheet with the same number as the graphic itself. For example, if you set a terrain to use graphic 1010 and enable auto-tiling, it will look for sheet1010.png and use that to find the transition graphics. (Built-in auto-tiles would be hard-coded to specific sheet numbers.)

Thirdly, I think making this work well necessitates that terrain types have two graphics apiece – a base terrain which is opaque, and an overlay terrain which is transparent. It could be done without that, but you wouldn't be able to place trees and such on the transition. Or even if you could, the transition would draw on top of the tree.

I'm still not sure whether it's easier to convert a tile to a transition or draw the transitions extruding into the neighbouring tile. I'm still not sure what (if anything) to do when there is a need for a three-way or four-way transition.

I'm not even sure whether it's better to make the transitions transparent or hard-code them to a specific secondary terrain. RPGMaker does the latter, but RPGMaker also has some where the secondary terrain is transparent, and RPGMaker maps have 4 terrain layers, each of which can contain any tile, so it's a poor comparison. If the transitions are stored on a separate sheet, there's no need to worry about space, so maybe hard-coding specific pairs is fine.