RFC: terrain/map expansion/overhaul

[jonadab]

The game is running out of printable ASCII characters for representing terrains on maps. It is desirable to stick with printable ASCII characters, but it is desirable to have only one character per terrain, and it is desirable to keep things simple -- yet, there is a desire for more variety of terrain.

This Request for Comments is intended to suggest a reasonable solution to this quandry.

The proposal is to extend the system by having a concept of terrain _sets_. Each set could be thought of as a palette or alphabet, i.e., each set gives its own meaning to the various characters. A given map would then be specified using two distinct 2D arrays: one that specifies which terrain _set_ each hex pulls from, and the one that specifies which terrain is used from that set. For most maps, the terrain set array would be largely homogenous, which would keep things largely human-readable for those maps. (Edit1: in fact, if a map pulls _entirely_ from one terrain set, it ought to be possible to simply specify this and not have to include the full 2D set array.) Only when a map author chooses to mix and match terrains from multiple sets would things get complicated. (Edit2: the map editor could discourage this, if desired.)

In order to support legacy maps (i.e., ones created before this change goes in), there would be a default terrain set, known as set 1. (This is mnemonic; the 1 stands for 1.0, since this set would contain all of the terrains used in Wesnoth 1.0.) If for any map the terrain set array is not specified, it is assumed that every hex pulls from set 1. For new maps, however, set 1 would be deprecated, and all of its contents would be duplicated in other sets. Sets that would be defined initially would include a loyalist set (with grassland, ordinary forest, ordinary hills, ordinary water, and so on), tundra set (with snow, snow-covered forest, snow-covered hills, ice instead of shallow water, and so on), a desert set, and so forth.

Terrain sets would be defined in WML, and each one would be represented by an alphanumeric character. Sets represented by numbers and lowercase letters would be defined by the game or reserved for future use; sets represented by uppercase letters would be available for user-created content.

The available terrain characters (i.e., the ones specifying which terrain to use within any given set) would be divided into three categories: those representing "standard" terrains, those representing "special" terrains, and extra-special characters with particular properties (e.g., keeps).

For the "standard" terrains, it would be expected that the corresponding terrain on each set that defines it is fundamentally similar. For instance, g is grassland in set 1 and would be grassland in the loyalist set and should be something relatively flat and straightforward in every set. So, in the desert set g would be plain old sand probably, and in the underground set g would be normal cave floor, and so on. Similarly, h is hills in set 1, so it would be ordinary hills in the loyalist set, rocky cave or cave hills in the underground set, snow-covered hills in the tundra set, desert hills in the desert set, and so on. This is an additional nod to keeping things simple and maps human-readable as much as possible.

If a given map uses a "standard" terrain from a tileset that does not define it, the corresponding terrain from set 1 would be used as a fallback. So, if a desert map attempts to use the forest terrain from the desert set, and there isn't one, the regular forest terrain would be used. Later, if a desert-forest terrain is added (cactus patch or somesuch maybe) and is placed in the standard forest slot in the desert tileset, it would automatically be used without any need to edit the map.

If possible, a small handful of additional characters should be reserved for future standard terrains, if there are any characters left in set 1, i.e., any characters that Wesnoth 1.0 did not use.

Some characters, however, would be set aside for "special" terrains, and their meaning would be explicitely set-dependent, i.e., would vary from set to set. Using one of these terrains from a set that does not define it would be an error. The characters that set 1 uses for things like snow-covered hills (which really should be hills in the snow set) for the most part would be the characters that would be used for special terrains in all the sets.

Finally, certain extra-special characters would be treated very specially. The starting points for the various players (1, 2, and so on) are in this category. In set 1 they would behave with the same magic as they do now (i.e., deciding which terrain to use based on the surrounding terrain). In every other set, however, the keep terrain from the same set would be used, but it would also be the starting point for the player in question.

If this proposal is well-received, we will need to construct a list of what every character represents in set 1, and whether it should be a standard terrain or a special terrain.

[torangan]

There've been many suggestions on how to redo the terrain system and DarthFool (IIRC) is even implementing a new one already.

[Eleazar]

here's basicly what we want:
http://www.wesnoth.org/forum/viewtopic.php?t=9601
there's been a good deal of thought put into this,
and now we "only" need a good deal of coding.

Using 2 2D arrays would basicly make the maps only creatable with the map editor. We wish to keep it easy to make maps with any text editor.

[SkeletonCrew]

here's basicly what we want:
http://www.wesnoth.org/forum/viewtopic.php?t=9601

This thread doesn't seem to address the problem of running out of terrain letters. This proposal does.

Using 2 2D arrays would basicly make the maps only creatable with the map editor. We wish to keep it easy to make maps with any text editor.

Yesterday I also posted a proposal to solve the same problem.
In this proposal you can keep using a text editor.
http://www.wesnoth.org/forum/viewtopic.php?t=10685

Mark

[jonadab]

Using 2 2D arrays would basicly make the maps only creatable with the map editor. We wish to keep it easy to make maps with any text editor.

This proposal was deliberately designed to allow maps to be edited with any text editor (well, any text editor that uses a fixed-width font).

As noted, things only get at all complicated if the map author feels the need to make use of multiple terrain sets in one map, which in general is not going to be necessary or even a good idea. (Do you really want desert mountains and desert hills mixed together on the same map as snow mountains and snow hills, or either of them on the same map together with underground mountains and underground hills?)

I contend that most maps would be entirely homogenous, using terrains only from one set, so you wouldn't even _need_ the second 2D array, just a single line at the top of the map file specifying which set is used. Some maps would be split across a couple of sets, but even there it's mostly going to be along the lines of "we want snow on the northern half of the map only", so the terrain set array is going to look something like the following (only perhaps larger):

ssssssssssssssssssssssssssssssssssssssssss
ssssssssssssssssssssssssssssssssssssssssss
ssssssssssssssssssssssssssssssssssssssssss
ssssssssssssssssssssssssssssssssssssssssss
ssssssssssssssssssssssssssssssssssssssssss
ssssssssssssssssssssssssssssssssssssssssss
ssssssssssssssssssssssssssssssssssssssssss
ssssssssssssssssssssssssssssssssssssssssss
llllllssslllllssssssssssssssssllllllllssss
lllllllsllllllllllllssssssllllllllllllllll
llllllllllllllllllllllllllllllllllllllllll
llllllllllllllllllllllllllllllllllllllllll
llllllllllllllllllllllllllllllllllllllllll
llllllllllllllllllllllllllllllllllllllllll
llllllllllllllllllllllllllllllllllllllllll
llllllllllllllllllllllllllllllllllllllllll

In a text editor that uses a fixed-width font, that's pretty easy to follow when you're looking at how to interpret the other array.

You might also run into map authors who want to pull in a castle from a different terrain set than is used for the rest of the map, but that's going to be a small handful of hexes, and will typically be near an edge or corner of the map.

Furthermore, most of the terrains that are used most of the time will be "standard" terrains, i.e., h will be hills of some sort whichever terrain set it's coming from; g will be something flat whichever terrain set it's coming from; and so on. The only terrains that would be different between the different terrain sets would be "special" terrains. If anything, this revision makes maps _easier_ to hand-edit, because there are _fewer_ characters to remember for the standard terrains. For instance, when constructing a desert map, I no longer need to remember what the characters are for desert mountains, desert hills, and so on; I can specify the desert terrain set and just use h for hills, m for mountains, etc. This is much more mnemonic.

Sure, some clown is going to want to make a bizarroid mix-and-match map with patches of snow and ice in the middle of the desert, cave terrains above ground, and other such nonsense, but I would hope that such things would be kept out of the mainline campaigns and maps that ship with the game, and I wouldn't feel obliged to make said clown's job easy.

EDIT: further clarification follows.
The way I see things, the following terrain characters would be considered "standard", i.e., would be expected to be defined similarly by all terrain sets:
level non-road terrain: g (mnemonic: "ground")
road: R (mnemonic: big "Road" with a big R)
path or unpaved road: r (mnemonic: little "road" with a little r)
trees or similarly obstructed terrain: f (mnemonic: "forest")
non-level terrain: h (mnenonic: "hills")
very non-level terrain: m (mnenonic: "mountains")
wetlands/swamp: w (mnenonic: "wetlands")
water (shallow): c (mnemonic: "creek")
water (deeper): s (mnemonic: "sea")
beach/bank: d
bridges: | and \ and / (mnemonic: what it looks like)
ford: k
castle: C (mnemonic: big Castle with a big C)
keep of castle: K (with player positions: 1,2, et cetera) (mnenonic: big Keep, big K)
encampment: n
keep of encampment: to be determined
town (large village): t (mnemonic: "town")
village (small): v (mnemonic: "village")
village (on non-flat terrain): a
village (on very non-flat terrain): b
chasm or cliffs or similar (unpassable except by flying): X
impassible barrier (cannot be passed at all): W (mnemonic: big Wall, big W)

The following terrains from set 1 would be considered "special", so that each terrain set could use their characters for unique purposes. Special terrains do not need a mnemonic, because their usage would be much less common than standard terrains.
lava: special terrain l in set 1; impassable barrier W in another set (maybe the tropical set).
dwarven castle: special terrain o in set 1; castle C in the underground set.
dwarven village: special terrain D in set 1; town t in the underground set.
desert: special terrain I in set 1; flat terrain g in the desert set.
desert hills: special terrain J in set 1; hills h in the desert set.
desert mountains: special terrain M in set 1; mountains m in the desert set.
oasis: special terrain P in set 1; wetlands w in the desert set.
desert town: special terrain B in set 1; town t in the desert set.
desert village: special terrain U in set 1; village v in the desert set.
savanna: special terrain G in set 1; flat terrain g in the tropical set.
tropical forest: special terrain T in set 1; forest f in the tropical set.
ice: special terrain i in set 1; shallow water c in the snow set.
snow: special terrain S in set 1; flat terrain g in the snow set.
alpine: special terrain F in set 1; forest terrain f in the snow set.
snow hills: special terrain H in set 1; hills h in the snow set.
snow village: special terrain V in set 1; village v (or town t) in the snow set.
show hills village: special terrain A in set 1; village-on-hills a in the snow set.

These are negotiable, and could go either way:
alternative unpaved road: E
village (on wetlands): Y
village (on water): Z
ruined castle: N
sunken castle: Q
swamp castle: q

Characters not used in Wesnoth 1.0 should become RESERVED for future standard terrains.

New terrain since 1.0 already, that I know about, includes rocky cave (should obviously be terrain h in the underground set) and cave mushrooms (should be terrain f in the underground set, I think). I'm sure there are others. Ones that would be *wanted* include an underground chasm (terrain X, underground set) and frozen swamp (w in the snow set). Others (e.g., castle and keep in the snow set) could reasonably default to their set 1 equivalents for now.

If the first line of a given map begins with the string "Wesnoth Map Version 2.0", then it is a version 2.0 map. If some higher number than 2.0 is present, then it's a higher-version map. Oherwise, it is a 1.0 map.

For 1.0 maps, there is no concept of terrain sets and all terrains implicitely come from set 1. For 2.0 maps, the next line will either specify the terrain set for the entire map (e.g., "Terrain Set: l") or will declare that the terrain set is mixed ("Terrain Set: mixed"). If a single set is declared, then the remainder of the map consists of terrains taken from that set, which is effectively no more complicated than a 1.0 map, except that a different terrain set is used.

If the terrain set is declared as mixed, then there will be N lines of set array and N lines of terrain array. N can be required to be declared on a third line (right after the terrain set is declared to be mixed) or can be deduced by dividing the number of remaining lines in half, or a blank line can be used to separate the terrain set array from the terrain array.

[Garion]

How would that affect units' movement and defense numbers? Presently, almost all units move and defend differently in, say, grassland as opposed to snow or desert.

But if I read your proposal right, you'd reduce desert, grassland, and snow to a single character on each map (g), and simply draw on different graphics to "skin" the map with differing tilesets.

The problem with this is that it alters unit behaviour, too. If my assumption about how units tell what terrain they're in is right (I assume they check the coordinate of their location against the character in the mapfile), you'd have to generate a new movement_type for each new terrain tileset and then teach units to distinguish between map types and select a movetype at the start of each scenario, accordingly.

For instance, using some of your standardized letters for different terrains, you'd have a "woodland" profile that looked like this for the standard tileset:

Code: Select all

name=woodland_stnd
		[movement_costs]
		s=100  (Deep Water)
		c=3     (Shallow Water)
		w=2    (Swamp)
		g=1     (Grassland)
		f=1      (Forest)
		h=2     (Hills)
		m=3    (Mountains)
		t=1      (Town)
		C=1     (Castle)
		X=100 (Canyon)
		[/movement_costs]

But then you'd need another profile for the subterranean tileset.

Code: Select all

name=woodland_undg
	[movement_costs]
		s=100  (Deep Water)
		c=3     (Shallow Water)
		w=100 (Lava?)
		g=3     (Cave Floor)
		f=2      (Mushrooms)
		h=4     (Rocky Cave)
		m=4    (Cave Mountains?)
		t=1      (Town)
		C=1     (Castle)
		X=100 (Cave Wall)
		[/movement_costs]

And you'd have to do that for quite a lot of movement types, with different values for each different tileset.

Daunting.

Alternatively, you could let units treat all "g" tiles identically no matter what they look like, but that's lame. It makes sense, the way it is now, that Elves perform better in the open than they do underground.

The only third thing I can think of is to continue to distinguish between snow, grassland, and desert with different characters in all the tilesets- which sort of undermines the point of your proposal.

[jonadab]

How would that affect units' movement and defense numbers?

It wouldn't.

Notice that I have consistently used the terminology "terrain set", deliberately avoiding the terminology "tile set", which would be misleading. Each character in a terrain set corresponds to a _terrain_, which would be defined in WML in much the same way as terrains are defined in WML now, except that it would be defined in the context of the set. Among other things, a specific terrain might have multiple possible graphics, various effects, might be aliased to one or more other terrains, or might not, and so forth, just like a terrain now.

However, snow is _analagous_ to grassland, the closest thing you'd have on a snow-covered map. If you take a standard map with grassland, forest, hills, and shallow water, and send winter to drop snow all over it, you end up with snow, snow-covered forest, snow-covered hills, and ice. Yes, units are going to have different behavior than they had on the other map, to one extent or another, but the snow-covered hills are still analagous to the hills, and the snow-covered forest to the forest.

So yes, I'm proposing that snow, desert, and grassland correspond to the same character ("g"), but I am *not* proposing that they "simply" be drawn with different graphics. Their other differences would remain intact.

If you want to think of each terrain set as a "skin", I can go along with that, but in that case a "skin" can definitely have an impact on behavior, as well as appearance. Also note that while set 1 would have all of the _terrains_ from Wesnoth 1.0 in it, it would not have to have the same _graphics_ as Wesnoth 1.0 had. If we have better graphics, by all means, use them. It is the gameplay effect of the terrains in set 1 that needs to be compatible with Wesnoth 1.0, in order to support the existing campaigns and maps. (And yes, there may be a few maps already using terrains that weren't in Wesnoth 1.0, but it would be few enough at this point that they could be adjusted, I'd think.)

As far as how units specify things, they use the terrain name ("sand", "forest", "tundra", etc), not the map character, so that doesn't need to change. Yes, if a lot of new non-aliased terrains are added, then they'd have to specify movement for them, but that really is a separate issue. (And, it's normally not done on a per-unit basis, but in movement types, and a unit just says which movement type it is, usually, and lets it go at that. So really only the twenty-five or so movement types in units.cfg would need to change for each non-aliased terrain added -- and I am NOT proposing that we add a whole lot of terrains right now, and even if/when we do most of them probably will be aliased.)

Underground wetlands would definitely not be lava. The underground tileset would probably contain lava (as a special, I would think), but underground wetlands would just be a muddy or swampy area of the cave, just about exactly like if you use swamp in an underground map now (which one of the scenarios in TRoW does, incidentally). In fact, for now, the underground tileset could probably default on defining a w terrain, and let the default swamp terrain from set 1 be used. Similarly, most of the sets probably don't need to redefine shallow water or deep water terrains (although, I'm proposing that the arctic set put ice in the place of shallow water, but that is negotiable, as are all of the specifics).

Note that this framework allows for someone to come along later and contribute new terrains (e.g., volcanic mountains, aliased to mountains, and placed as m in the tropical terrain set, would be cool) without disrupting anything. Meanwhile, map authors can happily use the m terrain in the tropical set if they want, and as long as the tropical set doesn't define a terrain m, the default mountains from set 1 are used as a stand-in.

[Garion]

As far as how units specify things, they use the terrain name ("sand", "forest", "tundra", etc), not the map character, so that doesn't need to change.

This critical sentence was the flaw in my reasoning. I figured units used the map for their behaviour. I guess the [movement_values] tag would probably use map characters instead of terrain names to define its attributes, if that were the case, though. D'oh.

The lava thing was just sort of offhand gibberish, used only to showcase a drastic hypothetical change.

In this case, I really like your proposal. The thread Eleazar linked looks like it has some great ideas for improving how maps are drawn, and it could probably easily accomodate your concept, as well. More versatility is never a bad thing.

I just feared- with limited understanding, it seems- that it'd be a bear to implement.