[Uh-user] New Tile system

[Andreas]

Moin,

generally Thomas already summarised the main issue with the current 
system. It is all about the automatic registration of objects to allow 
easy addition and testing of content.

For creating a new system there are pretty much things we will now have 
to take into account. Two of them already mentiones by Thomas (naming 
conventions and ground properties).

Currently we have two kinds of tile sets:
1. basic set (e.g. grass and beach)
2. transition set (e.g. grass-beach)

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!

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?

Personally I do not like the idea of animated ground tiles (paths will 
not be animated anyway). We could rather try to achive something like 
animated water by using a randomly appearing animations on top of the 
water layer faking the swell. But that again is another discussion.

Naming conventions and directory structure should not be to complicated.
For action sets we used an own directory for each direction, but this is 
because it it very likely that most of the objects will be animated. 
Originating from NOT animated ground tiles I would suggest to resign the 
direction folders and put all 4 images into one folder naming them with 
the according directions - e.g. 225.png. My suggestion would look like this:

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

The naming convention for set_type could be straight, curve_in and 
curve_out. If using diagonal transitions additional straight_dia, 
curve_dia_in, curve_dia_out, curve_in_dia, curve_out_dia, curve_diain 
and curve_diaout. Still a lot of folders...

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.

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.

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.

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?

Ok, this was a lot of stuff to read and I have not talked about path 
sets. Basically, those should work pretty similar to the tile sets.
Directory structure could look like this:
/buildings/increment/streets/ps_pathtypeno/4xdirect.png
E.g. /buildings/sailors/streets/ps_trail0/4xdirect.png
Just get rid of the direction folders, they will not be animated anyway.

That is it.

For the time being,

Andreas