proposal for new terrain system.

[Darth Fool]

Here is my current proposal for updating the way terrain graphics are determined. Please constructive discussion only. Posts that are not contributing to the discussion of the proposal will be moved or deleted without explanation.

The idea is to bring a more obvious order to the way in which terrain graphics are determined. There are three elements to this. The first is to bring the definition of transitions into the definition of a terrain and not seperate into its own list of rules. The second is to Eliminate the distinction between flat and vertical components. The final is to create a unified definition of layer.

To achieve the first goal, graphics will be divided into the main hex, the edges between the hex and individual neighbors, and the vertices between the hex and two neighboring hexes. All graphics for hexes will be centered on the hex, graphics for edges will be centered on their center, and obviously, the graphics for the vertices will be centered on them. Obviously, for each edge graphic, there could be two competing graphics defined, and for each vertex up to three. This will require resolution of this degeneracy which will be defined in the layer section.

Currently graphics are broken up into vertical and flat graphics. This causes a certain amount of confusion as to the interaction between horizontal and vertical elements. By eliminating the distinction, it will simplify understanding what the engine is doing.

To resolve the order in which graphics get applied, every terrain graphical element will have a layer number. All graphics will be drawn in order from lowest layer to highest. Graphics that are on the same layer will be drawn based on the location of their center, going from left to right, top to bottom. The lowest layer in the main hex graphic will be called the base layer. Now, it is possible that you might want to have different edge graphics based upon whether the neighboring hex's base layer is is at a higher level, think grass on water vs grass on hills. To deal with this situation, it will be possible to define different edges based upon the difference in base layers between the main hex and the neighboring hex. This will replace the current system of defining transitions based upon potentially complicated rules matching terrain types. For example castle walls on adjacent hexes at higher levels (mountains) might be different from those at lower levels(grass), which might be different from those that are much lower(say deep water). Typically, transitions would be defined to layers that are lower then the terrain-base.

For those few cases where it is necessary, allowing a definition based upon the neighboring terrain type could be made possible (e.g. castle to castle or castle to keep.) but this should generally be frowned on for the general case, since using the base layer difference will allow for automatic transitions to new terrains (say a new type of water). With careful choice of layers, it should be possible to avoid using terrain names for the transition definition. To make this possible, layer # should be a floating point.

There is a similar problem for the vertices, but now you have two different differences that must be used for the determination of what graphic to use. Again, if necesary, it will be possible to define the choice base upon what the neighboring terrain types are.

Any individual image used in any graphic can have variations at a fixed %. Alternatively, variations on the rule set can be defined at fixed %.

Finally, the one graphic element that is in the current system that is not possible with the proposed system is the definition of multi-hex graphics. To replace the current system which is based on matching patterns of terrains, a similar system will be implemented. Instead of the current system which depends on the generic matching criteria and attempts to place the graphic on terrains that match, it will be possible to define a terrain that sets the terrain type for neighboring hexes. This will enable map designers to specify the precise placement of a multi-hex graphic without depending upon random matching chance.

As far as maps go, they will be defined by comma seperated lists. Eventually, it will be possible to overlay terrain types on top of each other with, for example 'aa+bb' meaning that the aa and bb terrains are combined with best mv and defense.

[freim]

Lots to take in at once. Let me see if I got it right. I will just trow out a bunch of thoughts and edit the post later if something is way off.

I tried to make an illustration for this new system (blue == edge, green: vertex):



This seems to allow for some nice new ways of doing transitions. It will also allow us to get rid of some ugly transition glitches we have atm (especially between different trans).

Atm trans are just drawn into one of two adjacent hexes. This allows for it to be used against a lot of terrains. The new system seems to center such transitions on the edge, but still be based on having trans->transparency so it's potentially 1 to many transitions. Could it also be set to overlap both, so one can make special transitions that are decoupled from being base terrain specific, like fx a cliff, which be a trans between several base terrains by overlapping both?

The new system can't cope with multihex the same way. Manual placement would give greater control for the map maker allowing for potentially better maps, but it also would be a lot more "micro-management" in the map editor (which would need substantial changes), especially if terrain/buildings placed with the castle macro's need to be placed manually also.

Typically, transitions would be defined to layers that are lower then the terrain-base"

I don't get this. How will transition show if they are under the base terrains, or do you mean under their "own" base terrain (+ any base terrain above it in the layering) only?

As far as maps go, they will be defined by comma seperated lists. Eventually, it will be possible to overlay terrain types on top of each other with, for example 'aa+bb' meaning that the aa and bb terrains are combined with best mv and defense.

How does this system cope with terrain like the forest which is a base terrain + transitions with a partially transparent overlay on top which is larger than the hex boundaries? I would think support for this should not get in "eventually", but right away or it will break a lot of stuff

I welcome the effort to make the system easier to understand, since the current one is very powerfull, but also awfully complex and hard to understand.

[Jetrel]

The new system can't cope with multihex the same way. Manual placement would give greater control for the map maker allowing for potentially better maps, but it also would be a lot more "micro-management" in the map editor (which would need substantial changes).

We should avoid such micromanagement at all costs. This follows from my principle that "any time a game engine can create content for you, it should". It should because it multiplies, not adds to, the rate at which people can create content.

That said, I think we can do so by having a function in the map editor that automatically places these terrains when people lay out strips of mountains - it will have to understand that the multihex tiles are special visual replacements of the mountain tiles, and treat them as such, but the game engine itself wouldn't have to. Just the map editor.

[Darth Fool]

Atm trans are just drawn into one of two adjacent hexes. This allows for it to be used against a lot of terrains. The new system seems to center such transitions on the edge, but still be based on having trans->transparency so it's potentially 1 to many transitions. Could it also be set to overlap both, so one can make special transitions that are decoupled from being base terrain specific, like fx a cliff, which be a trans between several base terrains by overlapping both?

Allright, I am trying to understand your precise question. Hopefully this will answer it.

The transition for an edge graphic is centered on the edge, so it can overlap both the neighboring hex and the original hex. An edge can have two sets of graphics, one from each hex. Imagine, if you will, a hill-forest transition. The hill might have a hill-graphic at layer 10. The forest might have a grass base at layer 5, and a tree graphic at layer 15. The graphics would be drawn in the order: grass, hill, tree. Now imagine that you instead have a hill to deep-water transition, with deep water being at -10. This large difference in base-layer (20) could trigger in the hill transition a "hilly cliff" transition. The same hilly cliff transition would be automagically used if there was a new terrain, ocean, with a base layer -25.

The new system can't cope with multihex the same way. Manual placement would give greater control for the map maker allowing for potentially better maps, but it also would be a lot more "micro-management" in the map editor (which would need substantial changes), especially if terrain/buildings placed with the castle macro's need to be placed manually also.

The castle macros would be replaced by well defined transitions that are slightly different from the current form. For example, there would be transitions for the edges (walls) and transitions for the vertices(towers). Placing castles and keeps would be the same as usual, just put castle hexes where you want them.

Typically, transitions would be defined to layers that are lower then the terrain-base"

I don't get this. How will transition show if they are under the base terrains, or do you mean under their "own" base terrain (+ any base terrain above it in the layering) only?

By this I mean, from the example above, typically you would define transitions for lower terrains, so you would define a transition from hills to terrain that has a lower base layer(<10), whereas, you typically would not define a transition going upward, so for example, deep water would not have transitions defined for terrain with base layer > -10.
There would be exceptions. Forests(5), for example, might define a transition for base-layers as high as its highest graphic(15). Similarly, castles may want to define a graphic for walls that are against a hex that is higher than the base terrain. I imagine that the more precise rule is that you would not define a transition to hexes with base layers higher than your highest graphical layer, but you probably want to define at least one transition for hexes that have a lower base-layer.

As far as maps go, they will be defined by comma seperated lists. Eventually, it will be possible to overlay terrain types on top of each other with, for example 'aa+bb' meaning that the aa and bb terrains are combined with best mv and defense.

How does this system cope with terrain like the forest which is a base terrain + transitions with a partially transparent overlay on top which is larger than the hex boundaries? I would think support for this should not get in "eventually", but right away or it will break a lot of stuff

Well, first off, note that nowhere did I specify the size of a graphic. It is possible to make a hex graphic larger than the hex, which is what you would want to do for trees where the roots where in the main hex, but the tops extend into the next hex. You might, in addition, have a transition defined which would add a few trees with roots in the neighboring hex.

How I imagine graphics from combined terrains working is a simple interleaving of layers.
So imagine a hill+forest. This would end up layered just like the transition between hills and forest: grass(5), hill(10), forest(15). For roads, imagine that the road graphic is at 7. Then when placed with grass and dirt, it would appear above them. When placed with hills, it would probably not be visible because the hill graphic is at layer 10. When placed in forests, the road would be visible through the trees. Clearly some of these kinds of combinations would benefit from a custom graphic and terrain rather than the auto-combination that would be done using + symbols.

I welcome the effort to make the system easier to understand, since the current one is very powerfull, but also awfully complex and hard to understand.

Part of the point of this proposal is to keep individual elements of terrain in a single graphic so it can be easily edited. Buildings would be a single graphic placed at a particular layer. Castles would be constructed from individual elements, towers, walls, and ground, instead of the current tower-wall combined graphic. Multi-hex graphics could be placed in the defining "central hex", with the children hexes associated with it having no graphics, just movement definition and possibly transition definitions.

So, your questions have caused me to realize a few problems with the proposal that I will need to resolve.
1) What happens if a multihex defines a neighboring hex that already has a definition. My initial guess is that it would combine the two with say a default '+' that could be configurable. This would force the implementation of '+' and the like as soon as multihex graphic was done. I will have to think about this a little more.

2) When combining terrain that has graphics at the same layer, what order does one use. Initially I would say do it in order of the combination definition (left to right). So aa+bb would result in aa graphic at layer 10 being drawn before bb graphic at layer 10.

3) when combining terrain with two different base-layers, which base layer to use? My initial reaction was to think that one should use the lower of the two, but this could cause problems. Imagine a shallow water(0) + hills(10). The hills graphic would make the shallow water graphic invisible, but cause transitions from other graphics to be triggered against the shallow water, but you might not want that. Perhaps some form of mixed combo will need to be done. I will need to think about this.

4) There is a problem with the ordering of graphics that I have defined. For example, a forest might have tree graphics at 15 while the mountain graphic might be at 20. For forests south of the mountain, there would be the possibility that tree tops mysteriosly get cropped by the mountains bottom. One solution to this is to change the ordering so that graphics are first drawn according to their position and then according to their layer within that position. This would actually probably also be easier to code. The problem with this is that you want, for example the transition of the mountain bottom to be above the grass to the south of it. The solution may be that one does have to reinstate two sets of graphics, horizontal and vertical. Horizontal graphics would be drawn first according to the layer then by location. vertical graphics would then be drawn, ordered first by location then by layer. This would mean that all "vertical" graphics would be displayed above all horizontal graphics, which might or might not be a good thing. Again, I will have to think about this some more.

[Eleazar]

Manual placement would give greater control for the map maker allowing for potentially better maps, but it also would be a lot more "micro-management" in the map editor (which would need substantial changes).

We should avoid such micromanagement at all costs. This follows from my principle that "any time a game engine can create content for you, it should".

I'm not sure i object to manual placement in the map editor, but i have a hard time imagining how it could be accomplished with easily legible map CFGs. There would have to be a slightly different identifier for each multihex tile of the mountains (for instance). That's currently 26 files of different shapes that would need to be referenced off some chart to correctly be placed in a map CFG. That would be half-way to abandoning the concept of map files that can be edited by mortals with any text editor.

...The idea is to bring a more obvious order to the way in which terrain graphics are determined.

*Applause!*

...To achieve the first goal, graphics will be divided into the main hex, the edges between the hex and individual neighbors, and the vertices between the hex and two neighboring hexes. All graphics for hexes will be centered on the hex, graphics for edges will be centered on their center, and obviously, the graphics for the vertices will be centered on them. Obviously, for each edge graphic, there could be two competing graphics defined, and for each vertex up to three. This will require resolution of this degeneracy which will be defined in the layer section.

* Umm, can we just call the "vertex" the "corner"?

* With "Edge" transitions, currently only one (if any) of two adjacent hexes gets to draw a transition. I can't think of a reason to do otherwise, unless a "tall" graphic would draw it's transition outward, while a neighboring "flat" terrain would overlap the base with it's transition. Currently overlay images seldom if ever have transitions, though they often exceed 1 hex is size.

* While the (as part of the same transition) north 3 and south 3 Edge transitions sometimes need to layer differently, i cannot think of a reason to assign different layers to individual edge transitions of the north or south side. To allow that would probably be overkill.

* with the current system the major distiction between edge and corner transitions is that corner transitions can (and usually do) overlap the source hex.
I haven't thought it all out, but it is possible that since your proposal allows standard Edge transitions to overlap both the source and adjacent hex, that Corner (vertext) transitions will no longer be neccesary.
Or course that would mean re-chopping the castle graphics, but you are proposing to redo some of them anyway.
If we could (as i suspect) achieve the neccesary results without any corner transitions, life would be simpler.
There also may be a valid distinction between corner transitions that are merely "tall" but don't otherwise overlap their source hex, (like castle) and wider corner transitions (like cave wall) that exceed their hex on most sides. It should be much simpler to judge which transition gets precedence in the first case.

...Currently graphics are broken up into vertical and flat graphics. This causes a certain amount of confusion as to the interaction between horizontal and vertical elements. By eliminating the distinction, it will simplify understanding what the engine is doing.

The flat/vertical dicotomy seems very straightforward to me. As we discussed on IRC, I don't see a problem with it except that as currently implemented in corner transitions it's unreliable. Corner transtions are naturally tricky because 3 tiles can be creating transitions that overlap in all directions.

I'm happy with everything i haven't commented on.

[turin]

Just here to say that I would probably prefer manual placement, if it wasn't too hard to understand. I have spent quite a long time trying to get the stupid multi-hex system to put the multihex tiles where they'll look good, but it often insists on putting on three or four single-hex tiles, usually for no apparent reason. Being able to force the computer to do my will would be good.

[jonathantan86]

I'm not an artist or an art programmer, but here are my viewpoints:

3) when combining terrain with two different base-layers, which base layer to use? My initial reaction was to think that one should use the lower of the two, but this could cause problems. Imagine a shallow water(0) + hills(10). The hills graphic would make the shallow water graphic invisible, but cause transitions from other graphics to be triggered against the shallow water, but you might not want that.

I don't think anyone will combine shallow water + hills (or grassland + hills) so I don't think you have to worry about this. If you wanted "wet" hills or "grassy" hills you would probably have to create an altogether new terrain instead of overlaying hills on water or grass (the top of the hill should be wet or grassy, not the bottom).

4) There is a problem with the ordering of graphics that I have defined. For example, a forest might have tree graphics at 15 while the mountain graphic might be at 20. For forests south of the mountain, there would be the possibility that tree tops mysteriosly get cropped by the mountains bottom.

Put forests at level 30 (or any number higher than mountain). And follow your plan in number 3 (which I quoted above), that is, use the lower level number for terrain transitions. Then we probably wouldn't have problems.

The mountain will overlap the grass south of it, but the forest on top of the grass (south of the mountain) will overlap the mountain.

[Eleazar]

Any chance a special transitions type could make 90 degree geometry work better? like scott's walls?

[Darth Fool]

Ok, here is a sample of how I imagine that the new WML would look like. This would replace what is currently in the terrain.cfg, and terrain-graphics would be eliminated:

Code: Select all

[new_terrain]
symbol_image=ocean
id=deep_water
name= _ "Deep Water"
char=s
submerge=0.5
unit_height_adjust=-3
 
move_type=deep_water
defense_type=deep_water
  [image]
    [hex]
      layer=-20
      image=ocean-1.png
    [/hex]
    [edge]
      direction = rotation
      layer = -20
      image = ocean-1-%r.png
      filter = "layer < -20"
    [/edge]
  [/image]
 
  [image]
    [hex]
      layer=-20
      image=ocean-2.png
    [/hex]
    [edge]
      direction = rotation
      layer = -20
      image = ocean-2-%r.png
      filter = "layer < -20"
    [/edge]
  [/image]
[/new_terrain]

[new_terrain]
symbol_image=village-human-tile
id=human_village
name= _ "Village"
char=v
aliasof=t
heals=true
gives_income=true
                                                                                
  [image]
    [hex]
      vertical=true
      layer = 10
      image = village.png
    [/hex]
  [/image]
[/new_terrain]

[new_terrain]
symbol_image=castle-tile
id=castle
name= _ "Castle"
char=C
unit_height_adjust=3
recruit_onto=true
                                                                                
  [image]
    [hex]
      layer=1.75
      image=stones.png
    [/hex]
    [edge]
      vertical=true
      direction = rotation
      layer = 10
      image = wall-%1.png
      filter = "layer != 1.75"
    [/edge]
    [vertex]
      vertical=true
      direction=rotation
#note that direction refers to layer_1
#layer_2 is clockwise around the vertex
#so if direction=n, %1= n, %2= ne.
      layer = 10
      image = tower-%1-%2.png
      filter = "layer_1 != 1.75; layer_2 != 1.75"
    [/vertex]
    [vertex]
      vertical=true
      direction=rotation
      layer = 10
      image = inner-tower-%1-%2.png
      filter = "layer_1 = 1.75; layer_2 != 1.75"
    [/vertex]
  [/image]
[/new_terrain]


[new_terrain]
symbol_image=ruin-tile
id=ruin
name= _ "Castle Ruin"
char=CR
unit_height_adjust=3
recruit_onto=true
  [image]
    [hex]
      layer=1.75
      image=ruin-stones.png
    [/hex]
    [edge]
      vertical=true
      direction = rotation
      layer = 10
      image = ruin-wall-1-%1.png; ruin-wall-2-%2.png; ruin-wall-3-%3.png
      filter = "layer != 1.75"
    [/edge]
    [vertex]
      vertical=true
      direction=rotation
#note that direction refers to layer_1
#layer_2 is clockwise around the vertex
#so if direction=n, %1= n, %2= ne.
      layer = 10
      image = ruin-tower-1-%1-%2.png; ruin-tower-2-%1-%2.png
      filter = "layer_1 != 1.75; layer_2 != 1.75"
    [/vertex]
    [vertex]
      vertical=true
      direction=rotation
      layer = 10
      image = ruin-inner-tower-1-%1-%2.png; ruin-inner-tower-2-%1-%2.png
      filter = "layer_1 = 1.75; layer_2 != 1.75"
    [/vertex]
  [/image]
[/new_terrain]

[Eleazar]

Ok, here is a sample of how I imagine that the new WML would look like. This would replace what is currently in the terrain.cfg, and terrain-graphics would be eliminated:

I tend to think the current division of terrain.cfg and terrain-graphics.cfg is useful. Currently all the gamplay data goes in terrain.cfg, and all the complex layering and transitioning goes in terrain-graphics.cfg. Since you usually want to change only one of the other, and the information is distinct, i find 2 files more convenient.

* I don't understand: "direction = rotation"
* I'd like to see how the village's base layer is invoked. Something like "base_layer=G" makes sense to me. (for now i'm ignoring the possibility of selecting it from the map file.)
* Filter, i think, should also be able to filter out specific terrains.
*Are you assuming each terrain will have a distinct layer value?
* i like the more explicit control over layers.

[toms]

Seems great. Because it looks understandable.

[Darth Fool]

Ok, here is a sample of how I imagine that the new WML would look like. This would replace what is currently in the terrain.cfg, and terrain-graphics would be eliminated:

I tend to think the current division of terrain.cfg and terrain-graphics.cfg is useful. Currently all the gamplay data goes in terrain.cfg, and all the complex layering and transitioning goes in terrain-graphics.cfg. Since you usually want to change only one of the other, and the information is distinct, i find 2 files more convenient.

You are correct that the split file is easier to modify, if you are only modifying one or the other. However, it makes it more difficult if you want to add a new terrain. Having everything in one tag makes it much easier to add a new terrain.

* I don't understand: "direction = rotation"

This was meant to indicate that there should be a version foreach direction where %r is replaced by the direction in the image name. Alternatively, you might specify a transition for only a specific direction.

* I'd like to see how the village's base layer is invoked. Something like "base_layer=G" makes sense to me. (for now i'm ignoring the possibility of selecting it from the map file.)

yes, I had not fully worked that out. I had considered that it could be a macro, but using a base_layer is a good idea

* Filter, i think, should also be able to filter out specific terrains.

Well, that is why I wrote the syntax as it is, for future expansion, but I may not implement it immediatly.

*Are you assuming each terrain will have a distinct layer value?
* i like the more explicit control over layers.

Well, each terrain will have an almost unique base layer. For example, ruins might have the same base layer as castles, but otherwise, they should be fairly unique.

hmm... I think that the "base layer" may need to be explicit for the terrain and not just depend on using the "lowest" graphic.

[Sangel]

I've been reading through this proposal, and it has definite edges in terms of flexibility and ease of expansion. One question which did cross my mind, which I'm not certain that I can answer for myself, is:

How much graphical redesign will be needed?

That is, aside from the recoding effort, will the graphics we have for our present terrain, or the current transition graphics, need to be reworked by a skilled terrain artist?

Or will this be a seemless change?

[Darth Fool]

I've been reading through this proposal, and it has definite edges in terms of flexibility and ease of expansion. One question which did cross my mind, which I'm not certain that I can answer for myself, is:

How much graphical redesign will be needed?

That is, aside from the recoding effort, will the graphics we have for our present terrain, or the current transition graphics, need to be reworked by a skilled terrain artist?

Or will this be a seemless change?

It will not quite be seemless, but I don't think that it will require a skilled artist to make most of the changes. Most graphical changes to current art would involve moving the center of mostly the transitions to correspond to the edge or vertex. It probably is possible to mostly automate it. There will likely, however, be at least a few cases which require tender loving care by a skilled artist.

[Eleazar]

I tend to think the current division of terrain.cfg and terrain-graphics.cfg is useful. Currently all the gamplay data goes in terrain.cfg, and all the complex layering and transitioning goes in terrain-graphics.cfg. Since you usually want to change only one of the other, and the information is distinct, i find 2 files more convenient.

You are correct that the split file is easier to modify, if you are only modifying one or the other. However, it makes it more difficult if you want to add a new terrain. Having everything in one tag makes it much easier to add a new terrain.

Terrains are modified dozens of times while they are only added once.

* will the ordering of elements within a terrain tag have any effect?

* will campaign designers be able to modify particual aspects of a terrain without repeating the complete terrain definition?

* I'd like to see how the village's base layer is invoked. Something like "base_layer=G" makes sense to me. (for now i'm ignoring the possibility of selecting it from the map file.)

yes, I had not fully worked that out. I had considered that it could be a macro, but using a base_layer is a good idea

Further comments on base layers:
There are basicly 2 different kinds, 1) Bases that are other terrain types, (villages, forest) and 2) bases that only appear with their specific overlay(castles). The most convenient way to defiine these will probably be different. For (1) we simply want to say in effect: "now do terrain X according to it's tag", while for (2) it's probably best to define all layers within the same terrain tag.

* I'd also like to get rid of the alias tag, and instead choose MV/Def types according to archetypes. Functionally, archetypes would be the titles of MV/Def values. (I don't know if they need to be defined outside of the CFG with all the mvtypes)

Code: Select all

terrain_type = hills, frozen
move_type = worst
defense_type = best

Of course "move_type" and "defense_type" should also be able to take archetype names as arguements.

But why define both MV and Def when they are the same? For a simle new terrain "flower garden" it would simply be:

Code: Select all

terrain_type = flat