[Uh-user] New Tile system

[Thomas Kinnen]

Andreas wrote:
> The transition sets currently contain 3 types (straight, outer curve,
> inner curve) with each 4 directions; makes 12 images. This allows a
> basic retangular layout of islands. For a more sophisticated layout we
> would need 7 more diagonal types; makes 40 images for one transition
> set. I am still not sure if extending the sets makes sense, because we
> would then be forced to extend the path sets with diagonal pathes as
> well. Your input, please!

Generally i would say this is not needed. Having the the normal 3 types
is enough for me and also makes building the rectangular buildings
somewhat easier.

> Another interesting question is if ground tiles could be animated?
> Somebody told me it would be nice to have animated water tiles, but
> unfortunaltly I have currently no idea how to successfully synchronize
> the small transition tiles (e.g. beach-shallow or shallow-deep) with
> the bigger water tiles. Nor do I know if it is possible to make such
> an animation look good at all when using small tiles only. Should we
> take this into account for the new system or not?

I don't know how easy it is to make these kind of things look good, but
generally my first feeling tells me that having animated ground tiles,
would not be the worst idea. Especially for water that seems useful. I
don't think we should lay off this option just to save us a few
sub-folders. Why do you think this is a bad idea?

> Basic ground tiles:
> /base/climate/basic_set/set_no/4xdirect.png
> (Having 4 directions for basic tiles would allow having small details
> like a little rock or something. Maybe it could be possible to tell
> the loader to use only one image for all directions if only one
> existent?)
> E.g. /base/moderate/grass/0/225.png
>
> Transition ground tiles:
> /base/climate/transition_set/set_type/set_no/4xdirect.png
> E.g. /base/moderate/grass-beach/straight/0/225.png

Do we really need to make this distinction between transition and basic
set? Isn't it basically the same, just with the basic tile being a
special case of the transition_set?

> Last but not least we have the issue with the ground properties.
> Actually I can just see 3 properties: land, coast, water. Having a
> property like "buildable" makes not much sense to me, because
> generally  most buildings could not be build on something else than a
> land tile. Except for the coast buildings (e.g. fisherman) which then
> have a requirement of at least on coast tile. A coast tile with
> property "unbuildable" would then create a conflict for the fisherman
> building.
>
> Ok, but let us pick up this issue and carry it a bit further.
> Actually it was planned to have a terrain layer for certain objects
> like streams, ponds, swamplands and so on. This obviously would mean
> to have a lot of additional tiles on top of the ground tiles. We could
> surely save a lot of loading when also putting them on the ground
> layer. Disadvantage would be that we would have to create such terrain
> objects for all climates individually.

I don't think this is such a good idea. For lakes this could be an
option, but other stuff like mountains, ponds and stuff should be
external objects like trees i think.

> The properties should be put into the database. Using YALM or
> something else for this ends in having loads of different file types
> to check for changes. We introduced the sqlite databases to avoid
> this. Another option perhaps would be to use prefixes or suffixes in
> the naming conventions for the image files:
> prefix_direction.png; e.g. for grass l(and)_225.png
>
> This leaves still a lot of space for discussions. Personally i would
> prefer something in the database.

After giving it some further thought I agree with putting it into the
database. All the other tile and animation information is in the ground
database, so it's the place that makes sense.

> And one more question. Do you think we can make the map editor work
> with such a system? It is now broken for quite some time and the sad
> truth is a new tile system will not help much if we do not have an
> editor to test it.

Yes, we can make that work.
>
> Finally, the last question. When using multiple images per tile object
> for more randomness when should they be saved as a fixed image?
> Already in the island.sqlite and only random selection of tiles in map
> editor or first when the game is saved?

Can you elaborate on the idea of multiple images per tile? You mean
something like the action_set for buildings? If yes then we can do that
on first map load if need be. But maybe it's enough to have it during
map creation (editor)?

A lot of answers and a lot of questions :)

So long,
Thomas