New terrain: cliffs

[zookeeper]

I've been building a new terrain type for some time using the graphics of the old canyon (which is now obsolete). The idea is to make a terrain that works just like canyon (non-walkable, but not impassable) that can be used to give height to maps. Currently, maps always look pretty flat. I'm not a good artist and improving these graphics further is starting to approach my limits, so it would be nice if someone more talented would want to finish them. I can probably tune the terrain graphics wml a bit further if needed, but essentially I'm almost finished with these on my part and am just posting these in the hopes that someone else will take over and get them included (and do whatever improvements are necessary for that to happen).

There are a few major problems with this terrain, however:

• Two actual [terrain]s are needed to draw the cliffs. This is because the cliff wall is always facing one way, which means that in order to be able to determine whether a vertical cliff wall (for example) should be "facing" left or right one needs two terrains, "front" and "back". Front faces south and east, back faces north and west.
• The terrains don't tile well with themselves. While you can draw walls and make isolated hills/islands, it seems to be essentially impossible to determine where the walls should be facing when one hex has more than 2 neighbours. One would need to assign more letters for cliffs in order to make it possible.
• Transitions require a lot of work. Obviously, it should be possible to have, for example, snow above a cliff and grassland below it. And to use cliffs as shores, transitioning nicely with water. Different combinations would probably require quite a few sets of custom transitions. Currently, the cliffs use grassland as their TERRAIN_BASE, and tile badly with most other terrains.

If you wish to test these yourself, just do the following:

• Add...

  Code: Select all

  [terrain]
  symbol_image=cliff-front-se-nw
  id=cliff-front
  name= _ "Cliffs (front)"
  char=:
  aliasof=X
  [/terrain]
  
  [terrain]
  symbol_image=cliff-back-se-nw
  id=cliff-back
  name= _ "Cliffs (back)"
  char=;
  aliasof=X
  [/terrain]
  

  [/size]
  ...to your data/terrain.cfg. I've picked the letters : and ;.
• Copy cliffs.cfg to data/terrain-graphics/.
• Add...

  Code: Select all

  {TERRAIN_BASE                 : grassland-r1}
  {TERRAIN_BASE                 ; grassland-r1}
  {CLIFF : ; cliff-front}
  {CLIFF ; : cliff-back}

  [/size]
  ...to your data/terrain-graphics.cfg. I put it after the TERRAIN_BASE declarations, not sure if it works all right regardless of what it comes after or before.
• And of course, decompress the images from cliffs.zip to your images/terrain/ directory. Then just fire up your editor and start drawing cliffs!

[Tomsik]

Cool...
At long last you can make maps that don't look flat.

[Woodwizzle]

I think this would be hard to implement. The terrain is still grassland, the cliffs are actually walls between 2 terrains. This would complicate the combat. Would only ranged attacks work between cliffs? Does the higher ground always have an advantage? etc.

That being said it does look cool!

[zookeeper]

the cliffs are actually walls between 2 terrains.

No, they're not. They're their own terrain.

[Tux2B]

It is great, though some transitions don't work very well. On the top of the screenshot, you can't distinguish the two terrains (grass and cliff) well.

[Cuyo Quiz]

I think i need an hexboard view, if it is possible.

[Ranger M]

It is great, though some transitions don't work very well. On the top of the screenshot, you can't distinguish the two terrains (grass and cliff) well.

They don't need to be different, they are exactly the same, except that the cliff hex cannot be left in one or more direction, but the grassland can be left in any direction. (and there are attack implications, but they are basically the same as the movement ones, they just haven't been decided on at the moment as far as I can tell.

[turin]

It doesn't make a whole lot of sense to me to have cliffs be unpassable barriers. In most games I've played, they just form "walls" (like Woodwizzle assumed you were attempting). Such a feature would probably complicate gameplay - are you allowed to attack melee across it? What about ranged? Etc. I guess cliffs that actually take up a hex are OK, but it seems odd to me that they take up a whole hex.

Graphics look good.

[Soliton]

The idea is to make a terrain that works just like canyon (non-walkable, but not impassable) that can be used to give height to maps.

What's so difficult to understand here?

The hexes might be hard to see in the screenshot but that would hardly be a problem in-game.

[turin]

The idea is to make a terrain that works just like canyon (non-walkable, but not impassable) that can be used to give height to maps.

What's so difficult to understand here?

It isn't hard to understand, I'm saying that the system wouldn't be intuitive in-game, and they wouldn't function the way one would expect caves to function.

[Eleazar]

It doesn't make a whole lot of sense to me to have cliffs be unpassable barriers. In most games I've played, they just form "walls" (like Woodwizzle assumed you were attempting). Such a feature would probably complicate gameplay - are you allowed to attack melee across it? What about ranged? Etc. I guess cliffs that actually take up a hex are OK, but it seems odd to me that they take up a whole hex.

I really don't understand the distinction between "unpassable barrier" and "wall"
If they didn't take up a hex, then gameplay would be complicated (or at least muddled) but since they take up a whole hex, units on opposite sides of a cliff cannot be adjacent to each other. Since units that aren't right next to each other cannot attack each other, no gameplay is effected.
From a gameplay perspective this is the best way to make cliffs, though i cringe at the number of variations needed to work in more than a few situations.
A shadow might help define the back edge.

[JW]

From a gameplay perspective this is the best way to make cliffs, though i cringe at the number of variations needed to work in more than a few situations.

This indeed seems like a ridiculously large undertaking. Someone should do the math to see if it is worth spending time on.

[turin]

I really don't understand the distinction between "unpassable barrier" and "wall"
If they didn't take up a hex, then gameplay would be complicated (or at least muddled) but since they take up a whole hex, units on opposite sides of a cliff cannot be adjacent to each other. Since units that aren't right next to each other cannot attack each other, no gameplay is effected.
From a gameplay perspective this is the best way to make cliffs, though i cringe at the number of variations needed to work in more than a few situations.
A shadow might help define the back edge.

I'm saying that it is more intuitive for them to act as merely a wall, not taking up a hex but just putting a barrier in between two hexes. However, this is impossible with the current code, and probably isn't worth the effort to change.

My point is that I think that cliffs that work based on unpassable barrier, not wall, seem really odd to me, and it doesn't IMHO add enough to the game to justify the added confusion.

[Velensk]

Thus prompted by a different thread: I post here to say that I was dissapointed that this was never finished and would like to encourage someone to pick it up.

[Eleazar]

4 years later we've done terrains probably as tricky as this, though it wouldn't be easy, but is probably possible.

But i still don't like it from a gameplay perspective.

1) If we don't rig thing so cliffs "take up" a hex than combat is rather weird as previously explained.

2) if we assume that a cliff "takes up" a hex it resolved combat issues, but it looks wrong especially on the north side of things. Based on how we do Cave walls and so forth it looks like a unit should have room to move 1 hex south of the road in zookeepers example, but he actually doesn't.