User:Ayin/Extended terrains proposal - Revision history

Ayin at 11:32, 15 October 2005

2005-10-15T11:32:54Z

Ayin at 20:40, 10 October 2005

2005-10-10T20:40:37Z

Show changes

Ayin at 20:31, 10 October 2005

2005-10-10T20:31:19Z

Ayin: /* Code changes */

2005-10-09T13:31:52Z

‎Code changes

Ayin: /* Description */ - limits of the proposal

2005-10-09T13:24:00Z

‎Description: - limits of the proposal

Ayin: /* Description */

2005-10-09T13:16:57Z

‎Description

Ayin: /* Code changes */

2005-10-09T13:14:37Z

‎Code changes

Ayin at 13:05, 9 October 2005

2005-10-09T13:05:45Z

Ayin: Proposal for extended terrains

2005-10-09T13:04:18Z

Proposal for extended terrains

New page

This is a proposal to implement extended terrain types. The base ideas for this proposals were submitted by [[User:Ivanovic|Ivanovic]] and [[User:freim|freim]].

==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 <tt>[terrain]</tt> WML will have another attribute, named, for example, <tt>layer</tt>, defining the map this terrain applies to. Same for <tt>[terrain_graphics]</tt> 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.

==Code changes==

* Add the support of multiple maps in <tt>map.cpp</tt>. In <tt>terrain.cpp</tt>, there should be 2 classes: <tt>terrain_type</tt> which describes the base terrain types, and <tt>terrain_combo</tt> which describes a combo of several terrains. <tt>terrain_combo</tt> should have the same methods as base terrains, but be '''very lightweight''' as those will need to be created on-the-fly. <tt>get_terrain_info</tt> should return a terrain_combo.
* Fix <tt>unit_types.cpp</tt> so the defense_modifiers and attack_modifiers work with the new multiple maps.
* Modify <tt>builder.cpp</tt> so it works with the new-style maps (changes to <tt>display.cpp</tt> may not be necessary if it is done properly).

← Older revision		Revision as of 11:32, 15 October 2005
Line 1:		Line 1:
	This is a proposal to implement extended terrain types. The base ideas for this proposals were submitted by [[User:Ivanovic\|Ivanovic]] and [[User:freim\|freim]].		This is a proposal to implement extended terrain types. The base ideas for this proposals were submitted by [[User:Ivanovic\|Ivanovic]] and [[User:freim\|freim]].
		+
		+	'''There is now a counter-proposal''' for this proposal on [[User:Ayin/New_terrain_graphics_system_proposal]]. [[User:Ayin\|Ayin]] <sup>[[User_talk:Ayin\|(talk)]]</sup> 13:32, 15 October 2005 (CEST)

	==Description==		==Description==

← Older revision		Revision as of 20:31, 10 October 2005
Line 28:		Line 28:
	* The map generator will need to take those changes into account. the <tt>terrain</tt> element in the [[map generator WML]], and the <tt>adjacent_liked</tt> element, will have to be somewhat re-thought.		* The map generator will need to take those changes into account. the <tt>terrain</tt> element in the [[map generator WML]], and the <tt>adjacent_liked</tt> 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.		* The editor is certainly the part which will need the most work, as UI changes will be necessary.
		+
		+	==IRC log transcripts==
		+
		+	=== Oct 9, 2005 ===
		+
		+	<pre>
		+	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. :(
		+	</pre>

@@ Line 26: / Line 26: @@
 * Most places where gamemap::TERRAIN is used should use <tt>terrain_group</tt> instead (<tt>actions.cpp</tt>, <tt>unit_display.cpp</tt>, <tt>reports.cpp</tt>, etc.)
 * Modify <tt>builder.cpp</tt> so it works with the new-style maps (changes to <tt>display.cpp</tt> may not be necessary if it is done properly).
-* The map generator will need to take those changes into account.
+* The map generator will need to take those changes into account. the <tt>terrain</tt> element in the [[map generator WML]], and the <tt>adjacent_liked</tt> 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.

@@ Line 9: / Line 9: @@
 * 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.
 ==Editor UI==

@@ Line 16: / Line 16: @@
 ==Code changes==
-* Add the support of multiple maps in <tt>map.cpp</tt>. In <tt>terrain.cpp</tt>, there should be 2 classes: <tt>terrain_type</tt> which describes the base terrain types, and <tt>terrain_combo</tt> which describes a combo of several terrains. <tt>terrain_combo</tt> should have the same methods as base terrains, but be '''very lightweight''' as those will need to be created on-the-fly. <tt>get_terrain_info</tt> should return a terrain_combo.
+* Add the support of multiple maps in <tt>map.cpp</tt>. In <tt>terrain.cpp</tt>, there should be 2 classes: <tt>terrain_type</tt> which describes the base terrain types, and <tt>terrain_group</tt> which describes a combo of several terrains. <tt>terrain_group</tt> 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. <tt>get_terrain_info</tt> should return a <tt>terrain_group</tt>.
-* Fix <tt>unit_types.cpp</tt> so the defense_modifiers and attack_modifiers work with the new multiple maps.
+* Fix <tt>unit_types.cpp</tt> 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 <tt>terrain_group</tt>.
 * Modify <tt>builder.cpp</tt> so it works with the new-style maps (changes to <tt>display.cpp</tt> may not be necessary if it is done properly).