## balanced_fight_mode patch

Discussion among members of the development team.

Moderator: Forum Moderators

ignatius
Posts: 35
Joined: December 3rd, 2004, 11:59 am
silene wrote: You clearly didn't understand what I meant, did you even read it? The example I was giving was a real example of a situation that will happen in the game.
sorry, I parsed "getting 0 in this function" as "calling the function with a zero argument" (and consequently thought you were referring to the assert-statement) while what you meant is "getting a return value of zero" (and actually referred to the problem of rounding, or, more precisely, truncation errors).
Let's suppose there is a Dwarvish Fighter stuck into water, the probability for him to be hit is 80%. So it's a lot more than your 50% hypothesis. Now let's suppose I use an Elvish Archer to slaughter him. The archer has 4 ranged attacks and the probability to hit is 80%. So it will often (51%) hit three times in a row.

Consequently, on the fourth attack, your cooking function will enter into play and will be called with the arguments 80 and 4. Now try again to convince me the result of the function won't be 0.

I suppose you were thinking the function would never return 0 because your algorithm was supposed to preserve EV...
Not at all! In fact, I did mention this very problem in the original post:
ignatius wrote: ... is reduced from 70% to 65% (64.49% would be optimal, but wesnoth operates with integer percentages).
It's clear that operation with integer percentages incurs a truncation error and that consequently, EV is only preserved up to this error.

In your example, the mathematically correct delta of 0.3125% to the last strike gets indeed truncated to zero and consequently leads to an effective EV of 3.2016 hits v/s the original 3.2 hits for the whole attack. This is a difference of 0.0016 hits. Well, I don't know for you, but for me, this inaccuracy is not a coercive argument for introducing FP math into integer code.

It's of course possible, to construct cases where the error in even bigger and indeed I was thinking about doing up to 5 multiplications upfront before dividing or using fixed-point arithmetic, but this would lead to ugly code and would seem weird, considering that the calculations for resistancies and leadership involve much higher inaccuracies.
silene
Posts: 1109
Joined: August 28th, 2004, 10:02 pm
ignatius wrote:
silene wrote: You clearly didn't understand what I meant, did you even read it? The example I was giving was a real example of a situation that will happen in the game.
sorry, I parsed "getting 0 in this function" as "calling the function with a zero argument" (and consequently thought you were referring to the assert-statement) while what you meant is "getting a return value of zero" (and actually referred to the problem of rounding, or, more precisely, truncation errors).
No!!! I wasn't refering to the problem of truncation!!! Please read again the second point of my original post. I was refering to this line of your patch:

Code: Select all

``if(s<=0) ERR_NW << "s=0 when p=" << p << " n=" << n << "\n";``
And I was saying it should never been logged because it's a common situation!

And my third point about precision didn't have anything to do with EV. My point was that the function implementation will return an underestimated value. This is my last post in this thread, I'm clearly wasting my time trying to improve your patch.
Jetrel
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US
silene wrote:
ignatius wrote: sorry, I parsed "getting 0 in this function" as "calling the function with a zero argument" (and consequently thought you were referring to the assert-statement) while what you meant is "getting a return value of zero" (and actually referred to the problem of rounding, or, more precisely, truncation errors).
No!!! I wasn't refering to the problem of truncation!!! Please read again the second point of my original post. I was refering to this line of your patch:

Code: Select all

``if(s<=0) ERR_NW << "s=0 when p=" << p << " n=" << n << "\n";``
And I was saying it should never been logged because it's a common situation!

And my third point about precision didn't have anything to do with EV. My point was that the function implementation will return an underestimated value. This is my last post in this thread, I'm clearly wasting my time trying to improve your patch.
Ok, maybe I was wrong. Maybe people do get all pissed about code.

Uh, seems to me his issue of logging has two simple misunderstandings, on his part and ours. This is all an assumption - if you could actually post the changed source in question, I'd like to see it. I don't have linux, and I don't know if I can, or should apply the patch.

FIRST, there is no way he could know that the error channel was reserved for a particular type of error - he saw it being used for some debug purpose, and imitated it.

SECOND, in highly "new" code like this, there is nothing wrong with doing an obscene amount of status logging, to show what is actually going on, and to highlight what behaviour the code changes (which is what this message seems to do). It is a form of sanity check, to make sure the code is doing what it is supposed to.

I would have killed for a decent, built-in console to the old MacOS APIs. But we didn't have one, and I was loathe to bloat my programs by linking the standard libraries, which would basically have to emulate the entire text-stream systems of other OSs, which were entirely absent on the mac os. I had to use the alternative, which was MacsBug - taking a look at direct memory addresses. Not a way to get much done. I can sympathize with his practice of logging everything - I would have loved to have had something like that, especially when something was not working and I had no idea why.

So, I hope we don't get into a war over different conventions regarding what logging is appropriate. That would really be stupid.

That said, I might just be talking out of my ass, seeing as how I haven't seen the patch yet, so forgive me if I am talking about something that has nothing to do with anything.

at any rateÃ¢â‚¬Â¦
Ignatius has presented this patch to us in the best way possible - a nice clear explanation, polite wording, doing as much work as he feasibly could beforehand.
One would be wise to treat him in turn - certain words you are using, silene, can mean different things in different contexts; I can see why he would be confused by the use of precision.

Please don't give up on him, I am quite certain that this is not a failing of intelligence on his part, but rather a little language barrier hitting us.
ignatius
Posts: 35
Joined: December 3rd, 2004, 11:59 am
silene wrote: I was refering to this line of your patch:

Code: Select all

``if(s<=0) ERR_NW << "s=0 when p=" << p << " n=" << n << "\n";``
And I was saying it should never been logged because it's a common situation!
I already said that this line is testing and debugging code, I forgot to take out (which is why it isn't indented like the rest of the code).
And my third point about precision didn't have anything to do with EV.
I suppose you were thinking the function would never return 0 because your algorithm was supposed to preserve EV...
... then somehow conveyed the wrong impression to me ... probably my fault!
My point was that the function implementation will return an underestimated value.
That's what integer division does: it returns an underestimated value.
This is my last post in this thread, I'm clearly wasting my time trying to improve your patch.
Well, seems like I have to do without your advise then ...
Jahannan
Posts: 6
Joined: January 5th, 2005, 4:00 am
I really love your patch. Hell, I've practically given up on Wesnoth until I see this available as an option in the standard package. Here are a few things I think would improve it though:

- Statistical extremes are not excluded unless their probability is less than 5% (or perhaps you could set the percent chance as a sub-option when turning on the patch)

- Available in multiplayer as an option selected by the game host (basically, there's no reason that this shouldn't be available. It's up to the game host to set the rules for the game, and if myself and my friends want to be able to play a less randomised game of Wesnoth at a LAN then there's no fair reason why we can't)

- No effect on 50% probabilities with 2 attacks. Though I'm nowhere near as precious about this as most of the Wesnoth players I've seen on the forums, there's still a big difference between reducing the probabilities of rotten luck, and creating a situation in which a deterministic result will occur. This kinda comes under the first point, but it's something which I really want to make sure you take note of.

I hope to see your patch included as an option in the standard distribution as soon as possible... for now, it's back to Nethack and XCom with me.
Dave
Founding Developer
Posts: 7071
Joined: August 17th, 2003, 5:07 am
Location: Seattle
Contact:
I'm afraid that the developers of 'the' official version of Wesnoth have no plans to use this patch. We consider it to change fundamental game mechanics, and we are opposed to distributing a game which is 'schizophrenic' about its ruleset.

Users who like the idea of the patch are welcome to exercise their Freedom and apply it on their versions of the game. They may also distribute their own Wesnoth distribution to others which uses the patch. If many people prefer it, it may become as popular or more popular than the current Wesnoth distribution.

David
Disto
Posts: 2039
Joined: November 1st, 2004, 7:40 pm
Location: Cambridge, UK
Do we have a section where all the patches are, so that you don't have to go through a lot of old posts to find one.
Creator of A Seed of Evil
Creator of the Marauders
Food or Wesnoth? I'll have Wesnoth
ignatius
Posts: 35
Joined: December 3rd, 2004, 11:59 am
Dave wrote:I'm afraid that the developers of 'the' official version of Wesnoth have no plans to use this patch. We consider it to change fundamental game mechanics, and we are opposed to distributing a game which is 'schizophrenic' about its ruleset.
To get this straight: No patches which implement rule options will ever be included, as the ability of players to optionally adopt the game mechanics to their liking is considered a bad thing?

I can understand that certain patches get refused for technical reasons (low quality code, too hard to maintain, potential source for future bugs) or lack of demand or get delayed because of the feature freeze. But, if I read you correctly, this is not the issue here, but rather that there is a design decision to not allow rule options on principle?

I have no problem if this is the case. It's your program after all, and Wesnoth is great enough as it is. It would just like to know, as it's simpler to implement certain changes if they are only for personal use.
Dave
Founding Developer
Posts: 7071
Joined: August 17th, 2003, 5:07 am
Location: Seattle
Contact:
ignatius wrote:
Dave wrote:I'm afraid that the developers of 'the' official version of Wesnoth have no plans to use this patch. We consider it to change fundamental game mechanics, and we are opposed to distributing a game which is 'schizophrenic' about its ruleset.
To get this straight: No patches which implement rule options will ever be included, as the ability of players to optionally adopt the game mechanics to their liking is considered a bad thing?

I can understand that certain patches get refused for technical reasons (low quality code, too hard to maintain, potential source for future bugs) or lack of demand or get delayed because of the feature freeze. But, if I read you correctly, this is not the issue here, but rather that there is a design decision to not allow rule options on principle?
Correct, except it's not so much 'on principle', but rather that the developers like to have a single game with set rules rather than endless variations on the ruleset.

Further, once we provided one rule option, people would want more, and we'd end up with several different options, some of which have multiple settings, and soon enough there would be thousands of different possible combinations, and thus thousands of possible rulesets.

It'd be impossible to make the game sanely balanced for all possible rulesets, and in practice, it'd probably only be possible to make it sanely balanced for a smallish subset of the rulesets.

That'd lead to a game which people would play, and find many options, but most of the options don't work nicely together. That's not the kind of game the developers want to play. We want to play a game where a ruleset has been firmly chosen, and play is optimized for that ruleset.

Further, it'd take a substantial amount of effort to implement fully all the code to make this work: the user interface code would be far more complicated to write than the rule logic changes themselves, and then we'd have to maintain all this code. This is something the developers are simply not going to do for a change that we don't even feel makes the game better.

However, we don't want to interfere with the freedom of others, and we welcome others to make a fork of Wesnoth and present their own version which either implements their own preferred ruleset, or which allows users to choose from a number of different rulesets.

In fact, I personally hope that there is at least one fork of Wesnoth. I think some healthy competition would be very very nice, and it would force us to keep making Wesnoth a fresh, interesting game: when there are multiple forks of a project, the forks with the best ideas and implementation will survive, while the forks which are stagnant will die.

David
Jetrel
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US
Dave wrote:In fact, I personally hope that there is at least one fork of Wesnoth. I think some healthy competition would be very very nice, and it would force us to keep making Wesnoth a fresh, interesting game: when there are multiple forks of a project, the forks with the best ideas and implementation will survive, while the forks which are stagnant will die.
I'd love to do this, but there's a little problem with the idea:

We don't have the people. Unless fork #2 attracts some wonderful people by dint of its great appeal, doing such a thing will fragment the project.

For example, I could actually do most of the stuff this project has done. I could spearhead an effort to do this. However, I could not do the following:

Network code. Translations.

And I have a feeling that many of the people who are most involved in the latter two would revile at my changes.
--------------
Now, the only way I could see it working, is if I applied several changes to the game which were non-volatile after a major release. Changes which would still allow people to participate with other wesnoth players online, and in the trading of campaigns.

However, this change is volatile. And besides the point, a new fork would likely need to be rejected by the campaign/multiplayer server, after a certain amount of time. The existence of those services is the death of forking for wesnoth. I can't host those. I can't host copies of the game.

Our, and my, time is better spent NOT duplicating each others efforts. Granted, we will have a bit of friction in differing opinions, but I think we can work things out (and to be honest, it makes me do a better job when people don't like my art).

The danger is with patches like these. These require new campaign content, and a new set of servers. If we want them to happen, we should help connect people who can provide the servers with people who can provide the code for the fork. We have a PR outlet, and we, truly, are about the only ones who can feasibly help start this.
Dave
Founding Developer
Posts: 7071
Joined: August 17th, 2003, 5:07 am
Location: Seattle
Contact:
Jetryl wrote: I'd love to do this, but there's a little problem with the idea:

We don't have the people. Unless fork #2 attracts some wonderful people by dint of its great appeal, doing such a thing will fragment the project.
People who would implement a fork are people who have fundamental disagreements with the way developement is done.

As such, they are people who are not current developers. It is likely they are would-be developers who aren't developers because they don't like certain aspects of the game, and want certain alternatives.

So, there would be no resource sapping from the project.

Also, since everything is GPLed, both forks can cherry-pick the best ideas from the other.

David
ott
Inactive Developer
Posts: 838
Joined: September 28th, 2004, 10:20 am
It seems to me this patch is a middle ground between the game damage model and the FPI of non-random damage calculations. It also seems to me that Dave is right, that this kind of idea would fundamentally change Wesnoth, and should therefore stay outside the original codebase. Here is my attempt at an analysis of exactly why this is a fundamental change and why it should stay outside the code.

Let's say there are n swings, the probability to hit is p, and the damage for a hit is d. Let's for now ignore the complications introduced by early termination due to units dying before all n swings have been made.

The FPI of non-random damage calculations compress the damage distribution to a single impulse at the mean damage expected, so that Pr[damage=x] = 1 for a single value x=n*p*d, and 0 otherwise. Note that in many cases x is not an integer, so this introduces a complication of how to fit this into the integer damage model used by Wesnoth without skewing expected values, but this wouldn't be hard to fix.

The game itself uses a binomial damage distribution determined by n, p and d. This is zero everywhere except at each of x=0*d,1*d,...,n*d, where Pr[damage=i*d]=(p^i)*((1-p)^(n-i))*(n i) and (n i) is n!/(i!*(n-i)!). Damage here is very chunky. I like to think of it as playing chess with dice, especially when looking at units like the Thunderer.

Assuming that the corner cases relating to truncation of integer division could be resolved, this "balanced" idea squishes the current binomial distribution towards its mean, to become less tail-heavy. Damage is even chunkier, since in some cases the tails are lopped off altogether.

In contrast, the smoothed randomness idea tries to modify the damage distribution to become less chunky. The idea there is to allow non-zero probabilities for damage in between the values 0, d, 2*d, ..., n*d. This was also discussed in thread 3214, where it was pointed out it could be achieved by changing a d-n unit to 1-(d*n), making every unit behave like Cuttlefish (lots of little hits). This of course could be implemented in WML in a custom campaign, with no changes required to the game engine. Therefore, I think this kind of proposal is "compatible" with the Wesnoth engine. By implementing custom units with (d*n)-1 damage, and others with 1-(d*n), we could get closer to chess-with-dice or closer to normally distributed damage.

The FPI of non-random damage and the "balanced damage" ideas cannot be implemented in WML, as far as I can see. They seek to fundamentally change the basic damage model. As such, these ideas are interesting, but not Wesnoth.

Rather than fiddling with the damage model, I think it would be more productive to experiment with units that approach 1-(d*n) or (d*n)-1. If (d*n/4)-4 leads to too many 0-hits or 0-misses outcomes for the values of p that usually apply to combat with that unit, and the consensus is that this isn't fun, perhaps one could look at a (n*/5)-5 unit instead, or change the values of p that apply (by changing resistances or defense).

Furthermore, there are still some balancing issues in the game, which changing the damage model wouldn't solve. Playing Wesnoth takes a long time, so playtesting changes is difficult. Subtle changes like adding 2hp to Walking Corpses can change the feel of an entire campaign. I'm not interested in playtesting options that are orthogonal to the basic rules and which therefore exponentially increase the number of games one needs to play to get a feel for game balance. Therefore, I think it is reasonable for the devs to decree that options that increase the balancing effort exponentially should stay out of the game. The basic damage model isn't broken, so let's not waste time on it.

As Dave pointed out, most existing campaigns have become too hard with the AI improving. Also, with additive calculations of damage modifiers, some combinations of resistances, terrain defense, and modifiers can lead to weird outcomes. (As an example, aligned units with high damage-per-hit like the Horseman, Nightshade, or Highwayman currently have excessive day-night swings against high resistance enemies. This is a problem for such units that are too slow to retreat during their unfavourable time of day.) Instead of introducing basic changes (as options or otherwise) I would rather see effort put in to fix these balance issues. I think multiplicative modifiers are easier to balance, but if we stick with additive modifiers then we should make sure they are balanced, before changing the basic damage model. If the campaigns are too hard, they should be balanced, before changing the basic damage model.
ignatius
Posts: 35
Joined: December 3rd, 2004, 11:59 am
Dave wrote:It'd be impossible to make the game sanely balanced for all possible rulesets, and in practice, it'd probably only be possible to make it sanely balanced for a smallish subset of the rulesets.
IMHO, the whole point of having rules options is to make the game unbalanced on purpose. In fact, the scenario designer should not even have to know, in fact, he should be unable to even query whether an option is active or not.

Generally I think that that rules options are not mainly about difficulty (or balance for the matter), although they can be used to make the game somewhat easier or harder (like in the Challenges you suggested):

If someone finds it frustrating when a "sure" attack fails, when he gets a strong-intelligent Mage recruit or when he loses a level 3 unit, he will have less fun playing the game (or resort to save/loading), even if he would have no problem finishing the campaign otherwise.
Dave wrote:That'd lead to a game which people would play, and find many options, but most of the options don't work nicely together. That's not the kind of game the developers want to play. We want to play a game where a ruleset has been firmly chosen, and play is optimized for that ruleset.
Well, I don't see this a contradictory: All balancing would still be done vs. the default rules and if you stick to them, everything remains like it used to be.
Dave wrote:Further, it'd take a substantial amount of effort to implement fully all the code to make this work: the user interface code would be far more complicated to write than the rule logic changes themselves, and then we'd have to maintain all this code. This is something the developers are simply not going to do for a change that we don't even feel makes the game better.
IMO, a checklist at the start of the level (very much like the proposed Challanges-dialog) would be more than sufficient. If the proposed patch would require substantial changes and/or affects many parts of the code, this is a different issue, of course.
Dave wrote:However, we don't want to interfere with the freedom of others, and we welcome others to make a fork of Wesnoth and present their own version which either implements their own preferred ruleset, or which allows users to choose from a number of different rulesets.

In fact, I personally hope that there is at least one fork of Wesnoth.
Well, nobody will fork the project just to implement some rule options; esp. not at the current state of development. As for myself, I've already implemented the changes I wanted (except for the wounded_veterans patch, where I still resort to save/loading) for my own version, so I'm quite happy. I just would have liked to make those changes conveniently available to others, as I think that there is substantial demand and not everyone can handle sourcecode and patches. And I lack the time and ressources to mantain and release a patched version for every development release.

cu

Ignatius
Icekiss
Posts: 63
Joined: February 19th, 2004, 11:50 am
IMHO, the whole point of having rules options is to make the game unbalanced on purpose.
Well spoken.

I think if such options only exist as a configuration option inside a text file, most of the arguments against them should be debunked.

They require far less code to be implement (no gui to change them, no gui to show them), they don't confuse players, since they never get to see them in the first place, and they don't unbalance anything, since they aren't activated.

In fact, it is almost as if they didn't exist in the first place.

The only difference being, that if someone is annoyed about something particular (his horrible streaks of bad luck...) and willing to dig a bit, he can do something about it without having to patch the source, and recompile wesnoth himself.
Having read quite a bit on the forums, the RNG seems to be a prime example of something that can annoy some people deeply...

So, honestly, I am not able to see the downside of it all. So what if some of that options don't play well together? So what if the campaign developers didn't know about them? So what if one or the other is even buggy right now, because it wasn't properly maintaned?
As far as I can see, your average player would never know they existed. And those that do know about them, will still think that even with their restrictions, they are better than not having them in the first place.

Especially if someone already provided you with a patch that seemed to satisfy the ones having a certain gripe, I honestly fail to see the problem.

And Multiplayer? Simply completely disallow them there, since otherwise you would have to show them to the other participants, which would complicate things (And even then it would still be confusing to the players who don't know about them)...
Just keep it strictly SP.
If you are a debian linux user, take a look at my program: http://deb-install.sourceforge.net/
Invisible Philosopher
Posts: 873
Joined: July 4th, 2004, 9:14 pm
Location: My imagination
Contact:
Icekiss wrote:So what if the campaign developers didn't know about them?
One of them talks about balance without the campaign developer knowing they use that. They may have forgotten to mention they use it because they use it all the time. And a replay uploaded would probably be incompatible, but if not, then just strangely lucky.
Icekiss wrote:So what if one or the other is even buggy right now, because it wasn't properly maintaned?
"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
Play a Silver Mage in the Wesvoid campaign.