[split] Terrains with different Coverage-Levels

[MetalKing]

I like that Idea due to there exist Terrains likesome Kind of Forests you would even not note a colorful Clown if he is behind the Trees.

I think about a more generic Approach. Different Kinds of Terrains could have different Coverage-Levels determining the Range a Unit can get spotted. E.g. If you are in a GrainField (I refer to real GrainFields and not the small Plants of Embellishment 'Grain') you don't need special Grain-Skills to be covered by the Grain. That Way a Unit can could get discovered e.g. at least at 3 Fields remote but the discovering Unit doesn't get trapped/ambushed by. @Boldek: would that match your needs?

[artisticdude]

Different Kinds of Terrains could have different Coverage-Levels determining the Range a Unit can get spotted. E.g. If you are in a GrainField (I refer to real GrainFields and not the small Plants of Embellishment 'Grain') you don't need special Grain-Skills to be covered by the Grain. That Way a Unit can could get discovered e.g. at least at 3 Fields remote but the discovering Unit doesn't get trapped/ambushed by.

That seems like it would be violating the KISS principle, IMO.

[MetalKing]

That seems like it would be violating the KISS principle, IMO.

Oh, you casted the magical KISS-Spell. Reveal a covered Unit if another Unit nears closer than n Fields smells of AdvancedMathmatics.

[artisticdude]

Oh, you casted the magical KISS-Spell.

No, I stated my opinion. It's not a question of how simple it would be to implement, but of whether it would fit in with the KISS philosophy. Wesnoth is based on the idea that you can have in-depth gameplay with simple rules and mechanics, and without bloat features or complicated systems. In my opinion, what you are suggesting seems like it would complicate the gameplay unnecessarily and would confuse beginning players (and even more advanced players). Hiding/uncovering units can already be done with shroud/fog/certain abilities/some combination thereof. It would have a severe impact on the gameplay of Wesnoth to have all units be hidden until an enemy unit moves within a certain range and "spots" them. Furthermore, it would effectively nullify the purpose of having fog (and, to some extent, shroud) on a map, since it would effectively be forcing the effects of fog on that map.

Perhaps I'm misunderstanding what you are trying to say here, but that's how I see it.

[MetalKing]

Oh, you casted the magical KISS-Spell.

No, I stated my opinion. It's not a question of how simple it would be to implement, but of whether it would fit in with the KISS philosophy. Wesnoth is based on the idea that you can have in-depth gameplay with simple rules and mechanics, and without bloat features or complicated systems.

What is complicated about an Integer-Property defining the Range a Unit gets visible?

In my opinion, what you are suggesting seems like it would complicate the gameplay unnecessarily and would confuse beginning players (and even more advanced players).

Hiding/uncovering units can already be done with shroud/fog/certain abilities/some combination thereof.

It's not about realizing first Time that a Unit can't get seen.

It would have a severe impact on the gameplay of Wesnoth to have all units be hidden until an enemy unit moves within a certain range and "spots" them.

Does that means the same like "It does matter"? So let's assume: a Suggestion touching the GamePlay. What a strange Beast is that? Try to see it this Way: It doesn't concern just the Reasons a Unit if visible but even the effective States of Visibility like the Unit is invisible even it would visible without that Change. Do you feel how thin your Arguments are?

Furthermore, it would effectively nullify the purpose of having fog (and, to some extent, shroud) on a map, since it would effectively be forcing the effects of fog on that map.

Oh No! You did forget that it this Feature impact the Gameplay as you realized above.

Perhaps I'm misunderstanding what you are trying to say here, but that's how I see it.

Fazit: You don't like it and use contradicting Arguments like change nothing, change something, is already there and you try to see a KISS-Violation. Sorry, but I refuse to discuss on that Level.

[artisticdude]

Do you feel how thin your Arguments are?

Um, no? I don't see that what you've said in any way disproves my arguments...

I don't think you understand what I was trying to say (which may be partially my fault). Then again, I think I'm not comprehending exactly what you're proposing here.

Since obviously neither of us is understanding the other very well here, I shall refrain from further comment on the matter.

[Caphriel]

MetalKing, your suggestion as I understand it would substantially complicate gameplay. Currently units are either visible to every unit that can see the hex they're on, or only visible to adjacent units if they have the appropriate special for the terrain they're on. Your suggestion would make unit visibility distance arbitrarily depend on terrain type as well as allow all units to be concealed by terrain regardless of special ability, and seems to include making all terrains have some conceal value.

Boldek, to my understanding, requested an overlay to allow stealth (such as currently exists in Wesnoth) for all units regardless of ability, on specific hexes, but not on all hexes matching the terrain type.

[Elvish_Hunter]

Boldek, to my understanding, requested an overlay to allow stealth (such as currently exists in Wesnoth) for all units regardless of ability, on specific hexes, but not on all hexes matching the terrain type.

Since this is a completely different suggestion, I splitted the topic.
The original discussion is here: http://forums.wesnoth.org/viewtopic.php?f=12&t=36503

[MetalKing]

My Point is: I think it's possible to realize a simple Mechanism to give Terrain the Attribute to cover a Unit resp. limitize the Range a Unit is visible for another Unit. A Terrain needs an Attibute with e.g an Integer-Value for Range and a Method to check if the Unit is visible by any of the Player's Units. There is already a Function that checks if a Unit get discovered by Contact. That Function can perhaps get easily extended by extending the Range stealth Units ghave to get unstealthed by a simple Rule: if (distance(u1,u2) <= u2.location.coverRange) {unit2.goUnstealth();} At Present there have to be already a Test for Units with Range of 1 meaning neighbored Fields. So we don't have to crack anywhere into the Code but have a Location of Code dealing with Stealth or not Stealth.

[The_Other]

No offence MetalKing, but I find it quite hard to understand exactly what you mean.
I think you're suggesting that the current visibility system ("If I can reach you, I can see you") should be replaced with "If you're within R hexes I can see you, where R is decided only by what terrain you're in".
This is very easy in WML if R has a constant value rather than being set by terrain (I've experimented a bit with altering range-of-vision), it appears a bit odd in the GUI though (although only if you look very closely at unit's stats). What you would do is store every unit's max_moves (possibly in a different-named custom variable), change the value to R for every unit, then set moves_remaining to equal the original max_moves. Every unit then moves as far as it's normally supposed to but can always see R hexes away. You just have to remember to reset moves_remaining to the correct value each turn.
However, this won't work when the value of R varies in the way you suggest - you could do it if R was determined by the 'looking' unit's terrain, but not where it is determined by the 'looked-at' unit (because any given unit might be trying to see units with different values of R, which won't work). In this case, theoretically you could use an ability that hides a unit if the nearest enemy is more than R hexes away. But there would have to be such an ability for every possible value of R, and every single unit would have to have all of them. Again, this is possible in theory, but requires a lot of work, and might (possibly) slow the game down because of the amount of extra code being checked each turn.
The only alternative that I can see is to change the game engine itself, which is probably not likely in this case because (A) the current system works well, even if it isn't totally realistic, and (B) it would confuse players who are used to the current system and haven't heard about the change.

[MetalKing]

My Idea is not about limiting the Range a Unit can see but the Range a Unit is visible depending from its Field TerrainType resp its new Attribute Coverage. Neither if that Mechanism could implemented in WML nor if it can be done just implemented reasonable in the Engine is afaik a Requirement to post an Idea in this Forum and Impact on the GamePlay is necessary for every Idea that shall cause more than polish the Status quo. Like described its mainly a simple additional ConditionCheck and could made toggable by cfg-menu and/or by WML.

It's rather risible (at least in my Circle of Acquaintances we did laugh about that Property several Times) that a Unit in the LowLands can see a Unit behind a Mountain if it can go there resp vice versa a NonSwimmer cant look over a River. I am not sure if People consider Wesnoth GamePlay as perfect and each Change means a Lost of Perfection or Changes to the Engine are that difficult that these are considered to be impossible.

There is btw a Violation of the Rule R1:"A moved Unit that collected additional Informations can't undo its Move." If I move a Scout inside a Forest and it didn't get ambushed by any stealth Unit I archieve the Information there is no stealth Unit. To keep undo and R1 a Unit could get a irrevesable peer-Action revealing Area in Sight. I wonder if Wesnoth-Units can see Sun and Moon as they cant go there.

[The_Other]

Neither if that Mechanism could implemented in WML nor if it can be done just implemented reasonable in the Engine is afaik a Requirement to post an Idea in this Forum

I know that, I'm not suggesting that you shouldn't have posted the idea.
I merely mean to explain, as clearly and directly as possible, why this idea is very unlikely to be implemented. Of course, you are free to suggest any idea you can think of - but many suggestions will not result in anything being changed, unless you work out how to implement it yourself

[Caphriel]

Somewhat off-topic and rambling explanation of why this idea in particular, and many otherwise good ideas in general, get rejected, ahead:

Impact on the GamePlay is necessary for every Idea that shall cause more than polish the Status quo....
I am not sure if People consider Wesnoth GamePlay as perfect and each Change means a Lost of Perfection...

I can't speak for everyone, but I don't consider Wesnoth gameplay to be perfect. However, perfect or not, I like the game as it is, and I am confident that most Wesnoth players do, also. Otherwise they wouldn't play it. Suggestions that would dramatically change gameplay are therefore resisted more than suggestions that wouldn't. A change is not necessarily an improvement, and change for the sake of change is not de facto good.

It's rather risible (at least in my Circle of Acquaintances we did laugh about that Property several Times) that a Unit in the LowLands can see a Unit behind a Mountain if it can go there resp vice versa a NonSwimmer cant look over a River.

HAPMA and UAPEB. The visibility range of a unit may represent how far it can dispatch scouts and have them return with information within a limited time period, and not direct line of sight. Or whatever. The point is that Wesnoth is not a simulator, it's an abstracted strategy game, and realism is not one of the design goals. WINR, after all, and the results of its compromises with realism are a strategy game that is fun and has simple, relatively intuitive rules (in most cases.)

There is btw a Violation of the Rule R1:"A moved Unit that collected additional Informations can't undo its Move." If I move a Scout inside a Forest and it didn't get ambushed by any stealth Unit I archieve the Information there is no stealth Unit.

This has been discussed before. I can't find the thread off-hand, though.

Neither if that Mechanism could implemented in WML nor if it can be done just implemented reasonable in the Engine is afaik a Requirement to post an Idea in this Forum

It's not a requirement that an idea be generally acceptable in order to post it here, but if you post an idea that would dramatically change Wesnoth, be difficult to implement, and generally has no chance of getting accepted, you shouldn't get annoyed when it is summarily dismissed.

You have a lot of good and interesting ideas for strategy games. However, they're not good ideas for Wesnoth. Most of the things you suggest are dramatic changes to gameplay, and I would be willing to bet money that the Wesnoth project will not be making any major changes to fundamental gameplay ever in the future. Mature, stable software projects, open source or not, don't make massive changes like that.

Of course, you (or anyone else) is free to fork Wesnoth to implement some of your ideas. That might be easier than starting a new game entirely. But if you except ideas that will fundamentally change the game Wesnoth is to be accepted, you're probably setting yourself up for disappointment

I hope that helps you understand why I, and some others, argue against ideas whose primary flaw is that they're being suggested for Wesnoth and not for some other game in which they'd fit better.

Sorry for derailing the thread a bit

[MetalKing]

UAPEB is a funny Thing. I can understand Reasons for Abstractions but I don't know how Unit-Names and RPG match to UAPEB. This Abstraction is reasonable to understand that Experience done with single Units are at partially comparable with operating whole Battallions but this Abstraction have Limitations and RPG gets here far behind its Limits. So what about the Leader-Unit? Is it a Battalion of Leaders? Or is it a single Leader with Military Power of a whole Battallion? The Player sees Units with Character-Attributes (or Batallaions of Units with same Character?) with an individual Name and Identity and any Commonalties pf Properties and Behaviors with whole Batallaions are fine but the Player sees Units and not Batallaion. You can define a 5 is even but you won't change that even 5 can exist or even is something other that we are used to think even is.

you can't simply create something due to you declare and define something if that definion is bad resp isn't possible.
e.g. you can't construct a natural number that is both odd and even together even you like or need that. UAPEB and the GameStories of Units with RPG-Properties and Individuality are a missmatch you can't repair woth any abstraction.
UAPEB is something like the EpiCycle-Theory to explain a geocentric Model of World even the Reality is that the World is heliocentric. Heliocentric means here: we operate with Units and not Battaltions. They, look like Units, they talk like Units and die like Units. Declaring them to Battallions and adding epicyclic Arguments can't fix it.

[Crendgrim]

Let's all agree that Konrad simply represents "Konrad and his female ninja bodyguards".

I'd suggest you read the following thread, in which this problem (although the topic was a bit different) already has been discussed: http://forums.wesnoth.org/viewtopic.php?f=6&t=33658
The answer to your problem is, once again, WINR: Wesnoth is created as this, and to change this to make it more realistic would throw over all gameplay mechanism existing so far. And I think this is a bad idea.