Moving to two-letter terrain codes

[Eleazar]

An artist might even decide that a certain terrain type would never change with climate...

Trust me, we would.

[hands]

LOL

I figured as much, and I did give one probable example.

One of the things that I really like about Wesnoth is that creative methods and tools are fairly straightforward. It seems to facilitate the largest possible number of people to collaborate effectively. I think that's shown by the sheer number of ideas that have been and are being implemented.

My suggestions might be out in left field compared to what everyone decides is the best way to retain the ease-of-use while implementing new features. But, I think we agree that proactively finding a solution sooner is better than later. Now is the best time for people to create a wish list of what they would like so that it is more likely to happen when changes are made.

[Noyga]

If we switch to two letters, i think it would be nice that in most cases one of the two letters would tell the terrain type.
For exemple for forest ('f'): 'ff': normal forest, 'sf' : snow forest, 'df' : dead forest, 'mf' : misty forest, 'tf' : tropical forest, ect...

So let's make a first proposal for the new terrain letters :
- 'v' for villages
- 'c' for castles
- 'p' for plains (grasslands, ect...)
- 'f' for forests
- 'h' for hills
- 'm' for mountains
- 'd' for deserts
- 't' for tundra
- 's' for swamps
- 'w' for water
- 'u' for underground (ie caves)
- 'C for canyons
- 'i' for impassible terrains (cavewall)

# A' human (snow) hill village -> 'Hv'
# 'a' human hill village -> 'hv'
# 'B' desert village (adobe) (0.8.9) -> 'dv'
# 'b' human mountain village -> 'mv'
# 'C' castle -> 'cc'
# 'c' shallow water, "coast" -> 'sw'
# 'D' underground village (cave, village), "dungeon village" -> 'uv'
# 'd' sand, (old desert) -> 'sd'
# 'E' desert road (0.8.9) ->'Dp'
# 'F' forest (snow) -> 'sf'
# 'f' forest -> 'ff'
# 'G' savanna (grass) (0.8.9) -> 'sp'
# 'g' grass -> 'gp'
# 'H' hills (snow) -> 'sh'
# 'h' hills -> 'hh'
# 'I' desert (0.8.9) -> 'dd'
# 'i' ice (tundra) -> 'it'
# 'J' desert hills (0.8.9) -> 'dh'
# 'K' keep (castle) -> 'kc'
# 'k' river ford (grass, shallow water) (0.8.12) -> 'fw'
# 'L' tropical forest village (savanna, village) (0.8.9) 'fv'
# 'l' lava (canyon) (0.8.12) -> 'lC'
# 'M' desert mountains (0.8.9) -> 'dm'
# 'm' mountain -> 'mm'
# 'N' ruined castle (0.8.12) -> 'rc'
# 'n' encampment (castle) -> 'ec'
# 'o' dwarven castle (castle) -> 'dc'
# 'P' desert oasis (0.8.9) -> 'od'
# 'Q' sunken ruin (0.8.12) -> 'wc'
# 'q' ruin (swamp) (0.8.12) -> 'sc'
# 'R' road (grass) -> 'rp'
# 'r' dirt (grass) -> 'dp'
# 'S' tundra -> 'tt'
# 's' deep water -> 'dw'
# 'T' forest (tropical) (0.8.9) -> 'tf'
# 't' village -> 'vv'
# 'U' desert village (tent) (0.8.9) -> 'tv'
# 'u' cave -> 'cu'
# 'V' snow village (tundra, village) -> 'Sv'
# 'v' human village (village) -> 'Vv'
# 'W' cavewall -> 'ci'
# 'w' swamp -> 'ss'
# 'X' canyon -> 'cC'
# 'Y' swamp village (swamp, village) -> 'sw'
# 'Z' mermen village (shallow water) -> 'wv'
# '/','|', bridge (grass, shallow water) -> '/w', '|w','\w'
# '~' fog -> '~~'
# ' ' shroud -> ' '

[scott]

The system you propose is MOD - BASE
where MOD is the modificiation (snow, dark, misty, deep, shallow, ruined, etc.). That's good.

However, one big benefit of a binary system is to treat some terrains as object overlays. These include forests, all villages, and bridges.

So, in your examples you start to also use an OBJ - BASE model where the object is the village or bridge overlain upon base terrain

The problem arises when you want MOD-OBJ on top of MOD-BASE:
snowy/ruined/normal human village on top of snowy/normal hills.

At some point you're going to have to burn letters to either handle different modifications of the same object or to handle different objects of the same modification.

In other words my choice is between
1. MOD-BASE
letter 1 is the condition modifier
- a= snowy
- b= normal
- c= ruined
- etc.
letter 2 is the base+obj
- a= human village on plains
- b= human village on hills
- c= human village on mountains

2. OBJ-BASE
letter 1 is the object with a modification
- a = snowy human village
- b = normal human village
- c = ruined human village
letter 2 is the base terrain
- a = hills
- b = snowy hills
- c = plains
- d = snowy plains
- etc.

I think only the first method allows mass global variations that people are chasing after: seasons, evilness, ruinedness, etc.
You lose the flexibility to place any overlay onto any terrain.

However, the second method (I think) will end up being more efficient. The flexibility is there to place a bridge over shallow water, deep water, swamp, or chasm without adding terrain letters.
But, you can't switch over a large amount of terrain to a new season by changing a the first letter of every hex.

In the words of whoever wrote HTTT, A Choice Must Be Made.

[hands]

The problem arises when you want MOD-OBJ on top of MOD-BASE:
snowy/ruined/normal human village on top of snowy/normal hills.

At some point you're going to have to burn letters to either handle different modifications of the same object or to handle different objects of the same modification.

I think the original idea of moving to a two-letter terrain system was simply to allow for more variety in terrain tiles. Layers and climate seem to be afterthoughts more than anything else. The idea of adding layers already existed, but I don't know how they had planned to implement it.

I think only the first method allows mass global variations that people are chasing after: seasons, evilness, ruinedness, etc.
You lose the flexibility to place any overlay onto any terrain.

I'm not sure that people have really weighed in on whether or not they like the idea of global variations. I like it as an option. If it's not planned for now, it might be a difficult option to add later. So, I think it makes sense to discuss it. One of the benefits that I thought of with this option is the possibility of having a "climate" brush in the map editor. You could make a basic design for a map and decide later that part of it should have snow while another part should be very dry.

In the words of whoever wrote HTTT, A Choice Must Be Made.

Not necessarily. Or, at least not in the way that you mean. There haven't been any hard decisions made about how these features might help/hinder Wesnoth. Those kinds of decisions will be made, but since none of the code has been written, there is much more flexibility now. Both ideas could be used. The ideas discussed to allow for two-letter systems don't preclude three or four-letter systems instead. Perhaps the first letter could refer to a "climate," the second letter refers to what is in the top layer, and the third letter refers to the base terrain. The climate could affect both layers wherever applicable.
I edited my example of different lettering systems over here. I didn't bother to make the letters match any of the existing tiles. So, just consider it a somewhat visual example of what I'm trying to describe.

Maybe three letters will be considered too much. I don't know. It doesn't seem like a horrible thing to do though.

[Eleazar]

.....
I think only the first method allows mass global variations that people are chasing after: seasons, evilness, ruinedness, etc.
You lose the flexibility to place any overlay onto any terrain.

However, the second method (I think) will end up being more efficient. The flexibility is there to place a bridge over shallow water, deep water, swamp, or chasm without adding terrain letters.
But, you can't switch over a large amount of terrain to a new season by changing a the first letter of every hex.

In the words of whoever wrote HTTT, A Choice Must Be Made.

I'm not sure i understand all of scott's post. But if he's saying that one letter should indicate the overlay, and the other letter should indicate a base, that IMO won't quite work.

I agree with Scott in that I strongly support a way for the map WML to indicate a base terrain (i.e. what kind of water is under the bridge) indpendently from the terrain graphics cfg. Using such a system would free up 10-15 letters from our current "terrain alphabet" -- but that's not enough.

But we need 2 letter definitions weather or not we get a better way to do overlays It's resonable that we'll eventually generate more than 52 types of "plains" (once we include interior floors)

I think Noyga's post is in large part on the right track, except for the part of haveing to define every dual-layer tile in the terrain WML. (This especially breaks down with villiages. If you have 20 kinds of villiages and want to be able to put each one on 10 different bases, that would take up 200 dual letter combinations )

Also i think the function of a terrain shouldn't be controlled by one of the 2 letters. First of all, that would limit us to a subset of the possible letter combinations. Second of all, that might box us into a corner where a terrain that would logically go with a bunch of other terrains, can't because it has a different function.

So the terrain functions (of which we currently have 14) should be abstracted from their the typical terrain type. In otherwords, there would be about 14 terrain archetypes defined at the top of one of the terrain cfgs. They would have names like "impassable" "unwalkable"(canyon, lava) "villiage" "flat" "sand" etc. These would be displayed on the movement and defence tables. Each visible in-game terrain would be (in the current terminology) an alias of one of the terrain archetypes.

Of course there should be some overarching, comprehensable, and flexable system for assigning the dual letters to each set of graphics. I'm just not sure what that should be.

hands, the layers issue is not an afterthough. The drive to better handle layers existed before we were worried about running out of letters. (over a year ago) The need to address layering is just as important IMO as the need to get more terrain letters. Hopefully we can solve both at once.

I feel i've rambled. This is a broad and complicated topic.

P.S. my comments here are simply meant to deal with the layers/overlay aspect, and not as a replacement for expanding the terrain alphabet.

[Darth Fool]

It seems to me what is needed is a transition to a comma seperated map. Each hex would be delimited by the commas, which would allow both multi-letter terrain definitions as well as layering ala eleazer's suggestion. For example:

Code: Select all

a,f,sv+/+xc,g
d,m,m,v+m 

This would easily be distinguishable from the current map and so backwards compatibility for old maps could be maintained at least for a while.

[hands]

Of course there should be some overarching, comprehensable, and flexable system for assigning the dual letters to each set of graphics. I'm just not sure what that should be.

That's the crux of the matter. I think that if nothing else, this thread has led me to the conclusion that backwards compatibility and easy text editing are relatively simple issues that are easily solved. First, we have to reach that overarching, comprehensable, and flexable system. If after that system is found backwards compatibility and/or easy text editing aren't feasible for some reason, it won't necessarily mean that the solution is wrong.

hands, the layers issue is not an afterthough. The drive to better handle layers existed before we were worried about running out of letters. (over a year ago) The need to address layering is just as important IMO as the need to get more terrain letters. Hopefully we can solve both at once.

I apologize for my use of the word "afterthought." What I meant was that according to my (admittedly limited) understanding, using more letters for terrain was applied to the idea of layers after it was applied to the number of terrain tiles available. I agree with you that both issues are important, and that we should attempt to solve both with the same solution if possible. I think what I was trying to say was that we shouldn't sacrifice the ability to have more terrain tiles by limiting the solution to only deal with layers.

P.S. my comments here are simply meant to deal with the layers/overlay aspect, and not as a replacement for expanding the terrain alphabet.

It is one of the more defined ideas about how to make layers work though, and so it is also relevant in trying to find one solution that fits both problems.

[hands]

It seems to me what is needed is a transition to a comma seperated map. Each hex would be delimited by the commas, which would allow both multi-letter terrain definitions as well as layering ala eleazer's suggestion. For example:

Code: Select all

a,f,sv+/+xc,g
d,m,m,v+m 

Could you please give a little more detail about how you think both issues would be resolved? I'm not sure that I understand what the "sv+/+xc" refers to in your example. My guess is that "sv" refers to a tile or tile definition of some kind, "/" is simply the current bridge as the top layer, and that "xc" refers to the base tile as a two-letter terrain. Please tell me if I am wrong. If I'm right, please explain what the "sv" actually refers to.

[Darth Fool]

It seems to me what is needed is a transition to a comma seperated map. Each hex would be delimited by the commas, which would allow both multi-letter terrain definitions as well as layering ala eleazer's suggestion. For example:

Code: Select all

a,f,sv+/+xc,g
d,m,m,v+m 

Could you please give a little more detail about how you think both issues would be resolved? I'm not sure that I understand what the "sv+/+xc" refers to in your example. My guess is that "sv" refers to a tile or tile definition of some kind, "/" is simply the current bridge as the top layer, and that "xc" refers to the base tile as a two-letter terrain. Please tell me if I am wrong. If I'm right, please explain what the "sv" actually refers to.

ok, so comma seperated items refer to a single hex. sv+/+xc would therefore be a single hex. Following the convention proposed by eleazer in his thread, it would be broken up into layers split with the + sign. Thus, sv+/+xc would be an sv tile layered above a / tile layered above an xc tile. (or perhaps the other way round, it doesn't matter as long as it is consistent) what sv, xc, and / stand for is not particularly relevant.

One problem with this approach is the question of how transitions work when you have multiple layers. But basically the comma seperated map enables both layering and multi-letter terrain definitions.

[Disto]

What would be really good, when the two-letters come into play, would be if someone made a bot which automatically changed all the the one-letters into two.

[ILikeProgramming]

Could you please give a little more detail about how you think both issues would be resolved? I'm not sure that I understand what the "sv+/+xc" refers to in your example. My guess is that "sv" refers to a tile or tile definition of some kind, "/" is simply the current bridge as the top layer, and that "xc" refers to the base tile as a two-letter terrain. Please tell me if I am wrong. If I'm right, please explain what the "sv" actually refers to.

ok, so comma seperated items refer to a single hex. sv+/+xc would therefore be a single hex. Following the convention proposed by eleazer in his thread, it would be broken up into layers split with the + sign. Thus, sv+/+xc would be an sv tile layered above a / tile layered above an xc tile. (or perhaps the other way round, it doesn't matter as long as it is consistent) what sv, xc, and / stand for is not particularly relevant.

One problem with this approach is the question of how transitions work when you have multiple layers. But basically the comma seperated map enables both layering and multi-letter terrain definitions.

I think this would be a great idea because it not only allows terrain modifications, but also can be used for 3-or-more letters per terrain without any changes. It'll be a while until this happens, but what if someone makes a completely new tile set?(like space tiles)

[Eleazar]

....It'll be a while until this happens, but what if someone makes a completely new tile set?(like space tiles)

Outer Space tiles (if thats what your referring to) would belong to a different game. That game might be a fork off of Wesnoth, but i don't see why the current tiles and space tiles should both be in Wesnoth.