User:Ayin/Extended terrains proposal
This is a proposal to implement extended terrain types. The base ideas for this proposals were submitted by Ivanovic and freim.
There is now a counter-proposal for this proposal on User:Ayin/New_terrain_graphics_system_proposal. Ayin (talk) 13:32, 15 October 2005 (CEST)
Contents
Description
The idea is that scenarios are now to have 2 (or more?) maps. The “base terrain” map, and the “terrain overlay” map. Then, the terrains defined in [terrain] WML will have another attribute, named, for example, layer, defining the map this terrain applies to. Same for [terrain_graphics] rules: a rule may be defined for a layer, or for another.
This will have the following consequences :
- One letter may be available, with different meanings, for both maps (not sure this is a good thing, though).
- Terrains will be a combo of several base terrains. For example, swamp + bridge, forest + village.
Note that, with the current proposal, the overlay and the base part will be totally independant. There will be no way to specify, on an overlay, terrain graphics which depend on the base terrain it is on. This solution is simpler (more in the KISS spirit), but less powerful than previous 2-letter terrain proposals.
Editor UI
The editor UI will need to have 2 lists of terrains on its right pane: a list of “base” terrains, and a list of “overlay” terrains.
Backwards compatibility
To be determined.
Code changes
- Add the support of multiple maps in map.cpp. In terrain.cpp, there should be 2 classes: terrain_type which describes the base terrain types, and terrain_group which describes a combo of several terrains. terrain_group should have the same methods as base terrains, but be very lightweight as those will need to be created on-the-fly. It may, for example, have char[2] as a data payload. get_terrain_info should return a terrain_group.
- Fix unit_types.cpp so the defense_modifiers and attack_modifiers work with the new multiple maps. Those methods should not use gamemap:TERRAIN anymore to identify terrain types, but should rather use terrain_group.
- Most places where gamemap::TERRAIN is used should use terrain_group instead (actions.cpp, unit_display.cpp, reports.cpp, etc.)
- Modify builder.cpp so it works with the new-style maps (changes to display.cpp may not be necessary if it is done properly).
- The map generator will need to take those changes into account. the terrain element in the map generator WML, and the adjacent_liked element, will have to be somewhat re-thought.
- The editor is certainly the part which will need the most work, as UI changes will be necessary.
IRC log transcripts
Oct 9, 2005
Oct 09 20:22:44 <Sirp> Ayin, about this proposal....
Oct 09 20:22:58 <Sirp> I don't quite understand some aspects of it. If you have forest + village, what is an Elf's defense there?
Oct 09 20:23:55 <Ayin> The best of both: it would be similar to "aliasof=ft"
Oct 09 20:25:01 <Sirp> Ayin, well, at the moment we don't have any such terrain in the game, since 'Elvish' villages only provide 60% defense to Elves and aren't aliases of forest.
Oct 09 20:25:21 <Sirp> but anyhow....I assume this means that 'snow' would be a base type, not an overlay type?
Oct 09 20:25:37 <Ayin> Sirp: The goal of the proposal (requested by freim, actually :) ) is to allow designers to create bridges on swamps, castles on desert, castles on swamps, etc.
Oct 09 20:25:40 <Sirp> since surely grassland + snow would not give a unit the best defense of either.
Oct 09 20:25:41 <Ayin> Sirp: Indeed
Oct 09 20:26:03 <Ayin> Snow, grassland, mountain etc would be base types
Oct 09 20:26:24 <Ayin> Villages, bridges, castles, would be overlay types
Oct 09 20:26:27 <Sirp> but would 'snowy forest' also be a base type?
Oct 09 20:26:49 <Ayin> That is a good question
Oct 09 20:26:58 <Sirp> okay so it sounds like all overlay types are 'man-made structures'?
Oct 09 20:27:41 <Ayin> Yep, something like that
Oct 09 20:28:18 <Sirp> Ayin, well I think the basic idea is okay, but it might need further fleshing-out.
Oct 09 20:28:48 <allefant> will the second map be a complete new map, or each "tile" just get an overlay?
Oct 09 20:28:49 <Ayin> Sirp: I agree. This is mostly the reason I created the wiki-page
Oct 09 20:28:55 allefant Ardonik Ayin Oct 09 20:28:55 <Sirp> Ayin, I have actually thought for a while that 'terrain combinations' rules should allow one to specify whether its "choose best" or "choose worst"
Oct 09 20:29:24 <Ayin> allefant: I don't understand your question
Oct 09 20:29:35 <Sirp> e.g. 'snow hills' should give movement of 'choose worst' rather than the current choose best.
Oct 09 20:29:37 <allefant> i'm thinking about the implementation..
Oct 09 20:30:11 <allefant> in a big map, it might be better for cache to have both tiles as one map position, instead of having two complete maps..
Oct 09 20:30:45 <allefant> well, just some random thought i had whilte reading it.. not really important for this right now :)
Oct 09 20:31:01 <Ayin> Well, as one map is about 1K (that is, smaller that a unit frame), is it really a big deal?
Oct 09 20:31:10 <allefant> no, guess not
Oct 09 20:31:29 <Sirp> I don't think we have to think about optimizations right now...just as long as each tile doesn't require dynamic allocation.
Oct 09 20:32:34 <Sirp> Ayin, I think that also for instance, fords should allow 'best movement' but 'worst defense'
Oct 09 20:33:18 <Sirp> since fords generally are easy places to cross, but if your enemy did catch you while crossing a ford, I think you'd be in a rather exposed and difficult to defend position.
Oct 09 20:33:44 <Sirp> while bridges should allow choose best movement and best defense.
Oct 09 20:34:10 <isaac> agree
Oct 09 20:36:48 <Ayin> Mhhh, those are good ideas, but those are totally incompatible with my proposal :)
Oct 09 20:37:35 <Sirp> Ayin, I don't see how they are really incompatible.
Oct 09 20:38:13 <isaac> erm
Oct 09 20:38:18 <isaac> I see quite easy to implement it
Oct 09 20:38:26 <Ayin> You mean that a "choose=best" or "choose=worst" flag should be added to overlay terrains?
Oct 09 20:38:30 <isaac> in the "man-made" stuff definition
Oct 09 20:38:34 <Sirp> Ayin, yes.
Oct 09 20:38:34 <isaac> yeah
Oct 09 20:38:37 <isaac> that
Oct 09 20:38:45 <Sirp> Ayin, you need one for each of movement and defense.
Oct 09 20:38:47 <isaac> Ayin: even
Oct 09 20:38:49 <Ayin> Okay. I get it
Oct 09 20:38:49 <isaac> move=best
Oct 09 20:38:50 <isaac> defense=worse
Oct 09 20:38:57 <freim> Ayin: forest are drawn as overlay now
Oct 09 20:39:10 <isaac> ouch
Oct 09 20:39:11 <isaac> :P
Oct 09 20:39:28 <Ayin> freim: Indeed, but this does not necessarily mean they should go on the "overlay" map
Oct 09 20:39:30 <Sirp> Ayin, intuitively, a village is something 'good'. snow is something 'bad'. You need a way to reflect this. :)
Oct 09 20:39:36 <freim> Ayin: but what is drawn as what doesn't really matter on defense
Oct 09 20:39:44 <freim> what matters is what is defined as what
Oct 09 20:39:44 <isaac> dinner
Oct 09 20:40:09 <freim> Ayin: well, it would be nice to be able to draw them on different bg
Oct 09 20:40:12 <Sirp> I think forest should be a base terrain unless we decide we are going to have "hills with forest on them"
Oct 09 20:40:18 <freim> fx forest on both grass and savanna
Oct 09 20:40:58 <Torangan> Do you intend to allow multiple overlays like Forest + Snow + Village?
Oct 09 20:41:07 <Sirp> hmmmm
Oct 09 20:41:23 <Torangan> Would make the system even more flexible (and complex).
Oct 09 20:41:27 <freim> well, it would allow for greater flexible
Oct 09 20:41:34 <freim> flixibility
Oct 09 20:41:36 <Ayin> Torangan: The proposal only allowed one overlay.
Oct 09 20:41:49 <Sirp> I think there are two main aspects to this:
Oct 09 20:42:01 <Sirp> (1) the graphical aspect, which I think is what freim's main goals are
Oct 09 20:42:06 <Ayin> The problem is that you do not create "snow hills" by just combining the picture for hills with the picture for snow
Oct 09 20:42:09 <Sirp> (2) the gameplay aspect.
Oct 09 20:42:28 <Ayin> And (3) the "terrain letter attribution" aspect
Oct 09 20:42:43 <Sirp> Ayin, well, that also. :)
Oct 09 20:42:57 <Sirp> I think we need to decide what we want exactly from each aspect.
Oct 09 20:43:11 <Ayin> This is the root of the problem
Oct 09 20:43:40 <Sirp> it sounds like what freim wants to do is draw forest and have an 'underlying' terrain type drawn beneath it, and then the forest drawn on top.
Oct 09 20:44:03 <freim> yes
Oct 09 20:44:11 <Ayin> Currently: (1) the graphical aspect is defined using [terrain_graphics] WML, and (2) the gameplay aspect is defined using [terrain] WML. Both are totally separated.
Oct 09 20:44:14 <Torangan> Multiple overlays would make things like complex castle interactions easier I suppose?
Oct 09 20:44:28 <Ayin> Torangan: Probably not
Oct 09 20:44:39 <Sirp> Ayin, I would tend to think that having them totally seperated is A Good Thing, wouldn't you?
Oct 09 20:44:56 <Torangan> I can't say that I understand the complexity behind all those transitions, overlays, multihex...
Oct 09 20:45:03 <Sirp> since e.g. grassland + forest and savannah + forest is different from a graphical perspective
Oct 09 20:45:10 <Sirp> while from a gameplay perspective each is just forest
Oct 09 20:45:34 <Sirp> and in the other direction, ford is a unique type of terrain from a graphical perspective, while it's a combination of terrain types from a gameplay perspective.
Oct 09 20:45:53 <Sirp> so I would tend to say the two problems are disjoint.
Oct 09 20:46:03 <Torangan> Having more graphically different terrains which behave the same gameplay wise would be nice. E.g. the comments about keeping both versions of the swamp...
Oct 09 20:48:17 <Ayin> Sirp: You are right, but the main problem is lack of flexibility. [terrain] tags are global WML. Those can be defined, using macros, in campaigns, using the few letters which are left free by global definitions. [terrain_graphics] tags may be either global, or [scenario]-specific, but, let's face it, few campaigns designer actually master them.
Oct 09 20:49:00 * GregorR made a new terrain 8-D
Oct 09 20:49:05 <GregorR> I used ö
Oct 09 20:49:07 <Sirp> Ayin, yes. I think that extending the terrain definition to 2 chars would be a nice thing.
Oct 09 20:49:24 <Ayin> So, currently, "swamp bridges" are accessible to scenarios designers, without any change to the Wesnoth code, provided that:
Oct 09 20:49:33 <Sirp> so a question: if we extended terrain definitions to 2 chars instead of 1, what would our remaining problems be?
Oct 09 20:50:36 <Ayin> * The scenario designer creates his own campaign, which defines the terrain using either one of the letters left, or, as GregorR did, a iso-8859-1 character.
Oct 09 20:51:06 <Ayin> * The scenario designer actually creates 3 terrains corresponding to the 3 bridge positions
Oct 09 20:51:40 <Ayin> * The scenario designer understands [terrain_graphics] WML enough to create terrains made with swamp, and bridge graphics.
Oct 09 20:52:31 <Ayin> Sirp: IMO, using 2-char terrains would allow 2 things:
Oct 09 20:52:41 <Ayin> * More "free" characters for scenario designers
Oct 09 20:52:49 <Ayin> * A wider choice of pre-made terrains
Oct 09 20:53:28 <freim> Sirp: my main reason for wanting two (or more) seperate layers are not flexibility, but reduction of complecity in transitions and WML
Oct 09 20:53:43 <freim> complexity
Oct 09 20:53:49 <GregorR> Incidentally, since they would have to use 3 letters, and (if I'm not mistaken) only two letters are reserved for campaigns, wouldn't they HAVE to go outside the simple character set?
Oct 09 20:53:52 <Sirp> freim, okay.
Oct 09 20:54:49 <freim> Sirp: fx the canyon don't work very well now. If it was allowed to be drawn on top of different bg tiles then it wouldn't need any special bg trans at all and could go through different terrain
Oct 09 20:55:08 <freim> Sirp: making trans between everything on the "same level" is getting increasingly hard
Oct 09 20:55:24 <freim> having to make them for a base layer instead is much easier
Oct 09 20:55:39 <freim> and then the other stuff can be drawn on top independently
Oct 09 20:57:45 <Sirp> Ayin, if I find time I may try to modify/extend your proposal and see if I can get something agreeable to you and freim.
Oct 09 20:58:32 <Ayin> freim: Mhhh... What is wrong with the canyon?
Oct 09 20:59:07 <freim> Ayin: it has a fixed grass bg
Oct 09 20:59:37 <freim> Ayin: which looks strange. Why should a canyon through a desert fx have grass around it
Oct 09 21:00:28 <Ayin> freim: Creating a new "canyon-over-desert" terrain would then fit in the "swamp bridge" case I described above. Currently perfelctly possible, but somewhat complicated.
Oct 09 21:01:00 <Sirp> Ayin, freim: how about this....
Oct 09 21:01:07 <freim> Ayin: yes, it is this complication I would like to remove
Oct 09 21:01:11 <Sirp> terrain definitions can have two chars
Oct 09 21:01:27 <Sirp> but '.' = null
Oct 09 21:01:32 <Sirp> so ./ is the same as /
Oct 09 21:01:45 <freim> Ayin: since 2 layers give more flexibility, reduce the need for special WML, and reduce the number of transition tiles
Oct 09 21:02:02 <freim> Ayin: and is easier for content makers to make use of I think
Oct 09 21:02:04 <Sirp> but if you want to make a bridge over swamp you can use w/
Oct 09 21:02:31 <Ayin> freim: I don't think it will remove the number of transition tiles. I agree it may be simpler, if done properly, though.
Oct 09 21:02:32 <Sirp> this will just make the terrain 'bridge' but will draw swamp as the background instead of water.
Oct 09 21:02:49 <Sirp> on gameplay it will have no effect by default
Oct 09 21:02:59 <Sirp> but you can write a definition of w/ if you want to to make it behave differently.
Oct 09 21:03:53 <Ayin> Sirp: So, mhhh, Okay. The problem is that, err "make the terrain 'bridge' but will draw swamp as the background instead of water" is not something possible with the current system.
Oct 09 21:04:28 <Sirp> Ayin, yes, that is something we would have to make possible. :)
Oct 09 21:04:39 <Ayin> Or well, this would mean combining the terrain_graphics system with a 2-layer graphics map system
Oct 09 21:04:50 <Sirp> Ayin, yes.
Oct 09 21:04:56 <Sirp> which is I believe something freim definitely wants.
Oct 09 21:05:16 <Ayin> This terrain stuff is a potent headache-generator
Oct 09 21:05:36 <Sirp> Ayin, yes. :(