Flat Tactics

[Alarantalara]

I was just trying to say that you had already pointed out that the characteristic of being a village has nothing to do with the village move/defense type.

The cases you just listed are predictable (though there are some that are not).

The current terrain rules (as of 1.10).

1) Unless otherwise mentioned, all terrains are the best defense and the worst movement of all terrains listed at the top right.
- this covers all the combination terrains like snowy hills
2) The following terrains are best defense and best movement: bridges, fords, village (based on terrain move/defense, not on an income basis)
3) Overlays take precedence over base terrains and may choose to exclude the base
4) The following overlays currently exclude the base terrain: impassable, mushroom grove
5) When an overlay does not exclude the base, then the value is calculated as though the overlay didn't exist, then redone with the overlay terrain
- this matters for villages on snow hills: movement is the worst of snow and hills, then replaced with village if better - fortunately, there aren't many units that have better movement on snow or hills than villages, so it doesn't tend to come up
6) Any unit may replace a best defense with a maximum defense on a per terrain/per unit basis (e.g. vampire bat on village)
7) Mine rails are non-standard and use flat for movement and the base terrain for defense

(That last one is the real reason I added the rail terrain for 1.11 - I'd rather not break every UMC unit that exists just to simplify the way terrain works. I'm hoping to have it as best defense/best movement with base in 1.13, with most units having 0% defense and flat movement on rails so that the same result is achieved but is possible to look up and be easier to understand.)

For what it's worth, it was more complicated for 1.8 core terrains (forest and village changed their rules depending on what terrain they were above), though the exceptions of rules 6 and 7 didn't exist then.

Edit: To keep this on topic, that 5th rule may prove to make it very difficult to represent how things work as part of the terrain, and the 6th rule makes it impossible.
For a worst case example, give the feral trait to a merman fighter (requires a special scenario, but all pieces are core) and place a village on a ford.
What is the merman fighter's defense?
a) 30%
b) 40%
c) 50%
d) 60%

Spoiler:

c) 50% Best defense would set it to 60%, but the feral trait sets a maximum defense of 50% on villages so that is used instead. Note that 50% does not appear as the defense value for any of the terrains involved in the unit description.

I therefore suggest not trying to indicate how terrain movement/defense combine on terrains. Marking which ones are used is not a problem, showing how they interact is.

[ancestral]

Thanks for all the feedback, guys.

@Dixie: I was thinking the half-and-half as you drew it and that might be more suitable for describing hybrids. Obviously there are arctic-forest-mountain tiles, so there may be cases of 3 thirds, but yeah, I’m wary of introducing too many colors.

I do get that the colors could be considered “tiring;” I need to test them in-game and see… I want people with color blindness would have an easy time distinguishing the colors. Here’s what deuteranopia looks like with the colors:

Spoiler:

Perhaps I could use a darker blue for sea tiles.

@SlowThinker, Alarantalara: Yes, I agree with you. Some functions (recruitable, heals, gives income) could certainly benefit from some kind of visual indicator. I’m thinking possibly a different style border. This would resolve issues where a unit occupies an arctic (frozen, snow, tundra) village but the unit could very well obscure the fact that the image icon indicates it’s a village. Perhaps a dotted border versus a double-lined border, for example.

@enchilado: I like it! Honestly, I think the map-like artistic qualities would make it a better suit in a hand-drawn style tileset, akin to the one that irreverent had posted long ago (reminds me of old fantasy maps). It could be effective in its own right, but it’s beyond the scope of what I’m trying to accomplish (easy to discern, identifiable primarily by color and secondarily by symbol).


Anyway, I’ll have some spare time tomorrow to play around with things.

[SlowThinker]

We would need to separate the definition of the unit stats (i.e. everything which is important from the gameplay point of view) from the unit sprites, animations, portraits, sounds - the latter ones should be defined in a "theme" (not necessarily the existing [theme] tag), and able to be changed independently by a mod such as this one discussed here (maybe even without stopping to play). (The third part, the translatable texts, are already externalized.)

I would like to see a more uncompromising solution: to differentiate

• the code that affects the game state
• the code that affects the player's interface

It would have many positive effects (e.g. any add-on could show its help or any other info (accessible by the the context menu) also outside of player's turn ..)

[ancestral]

We would need to separate the definition of the unit stats (i.e. everything which is important from the gameplay point of view) from the unit sprites, animations, portraits, sounds - the latter ones should be defined in a "theme" (not necessarily the existing [theme] tag), and able to be changed independently by a mod such as this one discussed here (maybe even without stopping to play). (The third part, the translatable texts, are already externalized.)

I would like to see a more uncompromising solution: to differentiate

• the code that affects the game state
• the code that affects the player's interface

It would have many positive effects (e.g. any add-on could show its help or any other info (accessible by the the context menu) also outside of player's turn ..)

Correct me if I'm wrong, but I don't see why this can't already be done.

You could split a unit file with one file being the actual statistics and the other being the animations. Also, you could easily make an add-on that affects units and that only modify the visuals or interface.

[Scatha]

These look good! Great work.

I'd suggest perhaps a lighter shade for the flat terrain? This is the default on many maps, and the easiest way to conceptualise them is to think of a background of flat in which other terrain features appear. If the colours help to suggest that I think it would be a good thing. Perhaps even something slightly pastel for the flat terrain?

(Actually, I now wonder what these will look like when you add units. I suspect it might be easiest if the whole palette were shifted slightly towards pastel colours, leaving the brighter colours for units, so that they stand out cleanly as they are the most important aspect on the map. This is really the same point as about the flat terrain, but made again in a different context. But I haven't thought deeply about this, and it might be it's not needed; I suppose the main point might be that you shouldn't finalise the terrain colours until you have some idea of how units will look on top.)

By the way, I think the deuteranopia-filtered colours look really very nice.

[taptap]

You will put units on the hex, so if you have the main information about the terrain in a centered sign, it will be pretty hard to guess the terrain when you put units on them (unless you have an option with shortcut to make the units disappear for a moment, but this would solve most visual problems even with standard background I guess)

[SlowThinker]

Correct me if I'm wrong, but I don't see why this can't already be done.

You could split a unit file with one file being the actual statistics and the other being the animations. Also, you could easily make an add-on that affects units and that only modify the visuals or interface.

An example: imagine an addon that improves the player's interface this way: via the context menu a player can invoke an information about combat statistics (similar like alt-s, but more detailed).
Wesnoth expects this code could change the game state, and so

• in multiplayer it cannot run on individual clients only: all players must have it or no player must have it
• a player can invoke the context menu during his turn only

Concerning the units, [unit] image= is considered a part of the game state, and is compared for OOS errors in multiplayer.

[ancestral]

The trouble is, when you make a contextual menu, you can put anything in it. Basically, you would need a new tag (or at least a new key to check) to control what kind of code can happen there. Plus, you'd have to program extra functionality to let people do this when not on their turn… it's quite the Feature Request, but sure, that would be nice.

I agree with you that changing a unit's picture should not cause OOS; perhaps another FR then.

[SlowThinker]

I would expect two independent modules, one for the game state, another one for the interface, and the 1st one informing the 2nd one about the events that happened.
But it looks Wesnoth started as a tiny game with a simple architecture, and this architecture was never rebuilt.