Backgammon is a game of skill and luck, we all know that.

I am going to write a DLL to use for the dice rolls in eXtreme Gammon.

It will eliminate any of those "lucky" 6-6s in the bear-off that turn me into being 97% favourite to the bot being 97% favourite (AI Factory, I'm looking at you here).

The DLL will roll two dice - let's say the bot gets first dibs, it makes it's roll. The user then gets the same two dice, he/she makes his/her roll.

Then a new set of dice are generated, the bot makes it's roll, the user gets the same two dice and moves accordingly.

Rinse and repeat.

Any thoughts, caveats? This will ensure that luck is completely eliminated and the better player wins, yes?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/1/2022 12:31 PM, Nasti Chestikov wrote:

Backgammon is a game of skill and luck, we all know that.

I am going to write a DLL to use for the dice rolls in eXtreme Gammon.

It will eliminate any of those "lucky" 6-6s in the bear-off that turn me into being 97% favourite to the bot being 97% favourite (AI Factory, I'm looking at you here).

The DLL will roll two dice - let's say the bot gets first dibs, it makes it's roll. The user then gets the same two dice, he/she makes his/her roll.

Then a new set of dice are generated, the bot makes it's roll, the user gets the same two dice and moves accordingly.

Rinse and repeat.

Any thoughts, caveats? This will ensure that luck is completely eliminated and the better player wins, yes?

Well, it won't eliminate luck, since a great roll for one player is a
terrible roll for the opponent.

For example, an early 66 is great for one player, but stinks for the
second player.

Also, in no-contact positions the result would be a foregone conclusion
most of the time, eliminating the skill factor of using the cube.

I don't think this idea will accomplish what you think it does.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/1/2022 12:31 PM, Nasti Chestikov wrote:

Any thoughts, caveats? This will ensure that luck is completely eliminated and the better player wins, yes?

As long as there are dice, there is going to be luck. Who
gets to play first? That's still determined by luck, right?

I seem to recall that there have been some attempts to play
"duplicate backgammon" where you have teams of two people.
Say Austin and Alyssa are on one team, and Brian and Brooke
are on another team. Austin plays Brian and Alyssa plays
Brooke. The referees ensure that whatever rolls Austin gets
are identical to whatever rolls Brooke gets, and whatever
rolls Brian gets are identical to whatever rolls Alyssa gets.
The players don't get to see what's happening on the other
board until the games are over. This might sound like a good
way to eliminate luck, just as duplicate bridge eliminates
the luck of the deal. The trouble is, as soon as someone
makes a play on one board that diverges from the play on the
other board, the fact that the dice are the same on both
boards becomes almost irrelevant. For example, suppose the
first roll of the game is 52, which Austin plays 24/22 13/8
and Brooke plays 13/11 13/8. Then suppose the next roll is
55. The positions on the board are now massively different;
Austin now has two checkers on the bar and snake eyes are
disastrous for him, while snake eyes are a joker for Brooke.
Brooke's huge advantage compared to Austin at this point
cannot be reasonably attributed to any difference in skill.

---
Tim Chow

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, December 2, 2022 at 1:25:29 PM UTC, Tim Chow wrote:

On 12/1/2022 12:31 PM, Nasti Chestikov wrote:

Any thoughts, caveats? This will ensure that luck is completely eliminated and the better player wins, yes?

As long as there are dice, there is going to be luck. Who
gets to play first? That's still determined by luck, right?

I seem to recall that there have been some attempts to play
"duplicate backgammon" where you have teams of two people.
Say Austin and Alyssa are on one team, and Brian and Brooke
are on another team. Austin plays Brian and Alyssa plays
Brooke. The referees ensure that whatever rolls Austin gets
are identical to whatever rolls Brooke gets, and whatever
rolls Brian gets are identical to whatever rolls Alyssa gets.
The players don't get to see what's happening on the other
board until the games are over. This might sound like a good
way to eliminate luck, just as duplicate bridge eliminates
the luck of the deal. The trouble is, as soon as someone
makes a play on one board that diverges from the play on the
other board, the fact that the dice are the same on both
boards becomes almost irrelevant. For example, suppose the
first roll of the game is 52, which Austin plays 24/22 13/8
and Brooke plays 13/11 13/8. Then suppose the next roll is
55. The positions on the board are now massively different;
Austin now has two checkers on the bar and snake eyes are
disastrous for him, while snake eyes are a joker for Brooke.
Brooke's huge advantage compared to Austin at this point
cannot be reasonably attributed to any difference in skill.

---
Tim Chow

I've heard this argument before which does have some validity.
I've never played this version, but I do like the idea a lot and would
like to see it tried more.
Two counter-arguments. There are a few rolls that have a very high
probability of being lucky -- for example an early 31 and early doubles.
So, it's good to see the luck of these events approximately cancelled out.
Yes, somebody could roll these doubles and thereby dance on the bar,
but the likely effect is for these lucky events to be made less lucky or for the luck to cancel out completely.
I also think there's a reasonable likelihood that the racing phases of the two games will overlap.
For all pure races, the luck of the roll has an extremely strong positive correlation
with the pip count of the roll. So if the races overlap, we'll get a lot of this
luck-cancelling or reduced luck.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On December 1, 2022 at 10:31:14 AM UTC-7, Nasti Chestikov wrote:

I am going to write a DLL to use for the dice rolls
in eXtreme Gammon.
The DLL will roll two dice - let's say the bot gets
first dibs, it makes it's roll. The user then gets the
same two dice, he/she makes his/her roll.
Any thoughts, caveats?

Personally, I think it's impossible to measure luck
in BG. Trying to do so is just a vain, pretentious
attempt to make science out BG. Since you can't
measure it, you can't compare the luck of players
either but I will nevertheless suggest an idea based
on measuring (done by the bot and assumed to be
accurate) and comparing luck.

After the 1st player rolls and plays, and before the
2nd player rolls, look at the "dice map" ("temperature
map in Gnubg) of equities of all possible rolls and
roll the numbers with the closest equity (i.e. "luck")
to what the 1st player had gained.

Keep track of the -/+ equity difference so that when
the 2nd player is on roll again, you can adjust his
nearest "equity to be" by it (and keep repeating so).

The players may not necessarily make the best use
of their "luck" but will be at least given equal "luck",
(with, of course, all these statements being based
on the bot's calculations of "equity" and "luck"...)

I don't think this can be done by writing and external
DLL but it would be easy to add it to Gnubg, since it
already has a temperature map feature and the inane
"dice manipulation" feature which can be modified for
this purpose and turned into something a little more
useful. However, I don't think the Gnubg team cares
to do any real improvements that would broaden the
minds (or "horizons" as in the cliche) of BG players. :(

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 2 December 2022 at 15:41:57 UTC, peps...@gmail.com wrote:

I've heard this argument before which does have some validity.
I've never played this version, but I do like the idea a lot and would
like to see it tried more.

Paul

I was a little disappointed that there was so little appetite for your idea here

https://groups.google.com/g/rec.games.backgammon/c/IQjNOzKU0rk

and Murat's subsequent idea that everyone should use the same sequence of dice rolls and settings......it would have been a truly level playing field.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 2 December 2022 at 20:17:15 UTC, MK wrote:

However, I don't think the Gnubg team cares
to do any real improvements that would broaden the
minds (or "horizons" as in the cliche) of BG players. :(

MK

Yes I was somewhat disappointed that the latest release the other week (the first update in four years) contained no groundbreaking advances.

I'd love it if they brought back the "read dice from user DLL" feature that I understand was present many moons ago (and yet, strangely dropped from subsequent releases).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, December 4, 2022 at 2:28:01 PM UTC, Tim Chow wrote:

On 12/2/2022 10:41 AM, peps...@gmail.com wrote:

Two counter-arguments. There are a few rolls that have a very high probability of being lucky -- for example an early 31 and early doubles. So, it's good to see the luck of these events approximately cancelled out.

This is a good point.

I also think there's a reasonable likelihood that the racing phases of the two
games will overlap.

I'm less sure about this point. I can see that the luck will be
significantly reduced if the racing phase starts at *exactly* the
same time and the pip counts are approximately the same on both
boards. But all it takes to disturb the balance is for there to be
one big roll and for the race to start one roll later on one board.

I think the main problem is that the concept of a "team" would be
a hard sell in backgammon. It's caught on in bridge, but I have
a hard time seeing it catch on in backgammon. It's also harder to
implement in backgammon as a matter of logistics. In practice, I'm
sure tournament organizers would resort to electronic dice, and
players might not trust electronic dice.

The extent to which this form reduces the luck would seem readily measurable. Simply look at the correlation between the results and the PR differentials.

Doubles seems reasonably common in backgammon, and those are teams.
I like the team arrangement where one player is much stronger than the other, and
the weaker player does sanity checking for clear blunders. If there's not a clear leader,
you just get squabbling. Another approach might be to agree in advance with your doubles
partner that, whenever you have an unresolved disagreement over a play (meaning the captain's
play happened but the non-captain still hated it), then there will always be a bot prop on the issue
for a reasonable stake agreed in advance. That way, no disagreement need be too frustrating.
If you don't get your play, then either your play is not clearly right (and you shouldn't complain) or
you will win money in the prop (and therefore also shouldn't complain).

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/2/2022 10:41 AM, peps...@gmail.com wrote:

Two counter-arguments. There are a few rolls that have a very high probability of being lucky -- for example an early 31 and early doubles.
So, it's good to see the luck of these events approximately cancelled out.

This is a good point.

I also think there's a reasonable likelihood that the racing phases of the two
games will overlap.

I'm less sure about this point. I can see that the luck will be
significantly reduced if the racing phase starts at *exactly* the
same time and the pip counts are approximately the same on both
boards. But all it takes to disturb the balance is for there to be
one big roll and for the race to start one roll later on one board.

I think the main problem is that the concept of a "team" would be
a hard sell in backgammon. It's caught on in bridge, but I have
a hard time seeing it catch on in backgammon. It's also harder to
implement in backgammon as a matter of logistics. In practice, I'm
sure tournament organizers would resort to electronic dice, and
players might not trust electronic dice.

---
Tim Chow

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-12-02, MK <murat@compuplus.net> wrote:

After the 1st player rolls and plays, and before the
2nd player rolls, look at the "dice map" ("temperature
map in Gnubg) of equities of all possible rolls and
roll the numbers with the closest equity (i.e. "luck")
to what the 1st player had gained.

This won't work very well since the rolls (with the exception of the
first one) will not be random but determined by the previous rolls and
plays.

For instance, after 3-1, the second will will always be the same. After
2-1 it will probably be different after 2-1 and split and 2-1 and slot,
but it will still be predetermined.

The idea is good, but you should apply the correction elsewhere: let the
dice be random and substract the luck from the game or match result.

This is what is called "luck adjusted result" in gnubg (and something
less obvious in XG, but the feature is available in it as well).

Winning or losing fractions of points in money games or some percentage
of the match in match play is a bit puzzling at first, though.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On December 4, 2022 at 3:36:41 PM UTC-7, Philippe Michel wrote:

On 2022-12-02, MK <mu...@compuplus.net> wrote:

After the 1st player rolls and plays, and before the
2nd player rolls, look at the "dice map" ("temperature
map in Gnubg) of equities of all possible rolls and
roll the numbers with the closest equity (i.e. "luck")
to what the 1st player had gained.

As I sat down to write an essay on leveling of luck,
Phillip's post came in. I'll postpone it and respond
to him first, since this is a more specific subject.

This won't work very well since the rolls (with the
exception of the first one) will not be random but
determined by the previous rolls and plays.

Either I wasn't clear or you misunderstood. The first
player always rolls random, (he is the driver), after
each of his rolls the second player will be given an
equally lucky/unlucky roll (he is the passenger but
in the same car). I will illustrate with an example.

For instance, after 3-1, the second will will always
be the same. After 2-1 it will probably be different
after 2-1 and split and 2-1 and slot, but it will still
be predetermined.

Let's say X rolls a 31 first. The best move 8/5 6/5
gives him +0.231 equity.

To give O a roll with similar "luck equity", we look at
the temperature map and see that 33 is the closest
with +0.093 and we give O a hand-picked 33 roll.

At that point, O is still behind by +0.138 which we
will add to his next hand-picked roll.

Then X randomly rolls again, let's say a 52 giving him
a -0.116 equity. Now he is only ahead by +0.022.

We again look at the temperature map and see that
64 is the closest with +0.033 and we give O a 64.

At that point, X falls behind by -0.011 which we will
subtract from O's next hand-picked roll.

I hope you guys get the idea...?

If O had started with an opening 21 instead, giving
him only +0.003 equity by playing 24/23 13/11 as
best move. Then from the map we would pick a 61
for X which would give him +0.000 as nearest equity.

After O would roll randomly again and play, we would
add +0.003 to X's next "quity-to-be" and hand-pick a
roll from the map that would place him closest to O.

And so on...

The idea is good,

Yes. Thanks for acknowledging.

but you should apply the correction elsewhere:
let the dice be random and substract the luck
from the game or match result.

No. The two are not the same thing. In mine, players
don't wait for luck to level out after the fact when it's
already too late. Instead, luck is constantly kept as
level as possible throughout the duration of each
individual game, roll per roll. This is the beauty of it. ;)
This is what sets it apart from retroactive calculations.

You all be warned, though, that leveling luck this way
will cause serious damage to the so-called "cube skill
theory"...! (I'll explain this more in my next essay but
you all can already guess what's going to happen :).

This is what is called "luck adjusted result" in
gnubg (and something less obvious in XG, but
the feature is available in it as well).
Winning or losing fractions of points in money
games or some percentage of the match in
match play is a bit puzzling at first, though.

As I said above, what I'm proposing has absolutely
nothing to do with all that after-the-fact, retroactive
mathshittings... :( (I say this because in a world where
"PR-sacrificing" moves are made, making the most out
of one's luck is not necassary; there is no "wastage of
luck"! You all may want to write down this expression
that I coined. It may prove more valuable that the idea
of "wastage of pips"...)

Gnubg has that stupid "dice manipulation" feature that
looks at the temperature map to hand-pic rolls for 21
levels (no freaking less!!) of good/bad numbers.

Just trash that "absurd feature". The code you need is
already in there. Take a few lines from it, make a few
minor changes to pick the roll with the closest equity
to what is desired and throw out the the rest of the no
longer deeded code. It should be trivial for you to do.

You really have no excuses for refusing to make this
"improvement" to Gnubg, which will throw a monkey
wrench into the "jackoffski cube skill theory bullshit"
also, that I'm sure you all will greatly enjoy... :))

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/4/2022 9:38 AM, peps...@gmail.com wrote:

Doubles seems reasonably common in backgammon, and those are teams.

Those with more experience than I do might want to weigh in, but my
impression is that doubles are largely regarded as being "for fun,"
whereas the idea of duplicate backgammon is presumably to emphasize
skill.

Chouettes are another example of team play in backgammon, but again,
my impression is that people who play for significant stakes tend to
favor non-consulting chouettes, which largely eliminates the "team"
aspect of the game.

Anyway, the main argument is probably that the idea has been tried
a number of times before, and it has never caught on. You can read
a little more about it here:

http://www.bgonline.org/forums/webbbs_config.pl?read=48603

https://bkgm.com/variants/Duplicate.html

---
Tim Chow

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-12-05, MK <murat@compuplus.net> wrote:

Either I wasn't clear or you misunderstood. The first
player always rolls random, (he is the driver), after
each of his rolls the second player will be given an
equally lucky/unlucky roll (he is the passenger but
in the same car).

OK. This is not how I had understood it.

Still, these pairs of similarly lucky rolls would lead to some weird situations. For instance if player 1 rolls a big doublet in a close
race, so will player 2? If player 1 rolls badly in a bearoff against a
low anchor and exposes two blots, player 2 will roll badly as well and
miss them?

I suspect that the manipulation to level out luck so quickly would be
more obvious and unnatural than you think.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On December 8, 2022 at 3:58:59 PM UTC-7, Philippe Michel wrote:

On 2022-12-05, MK <mu...@compuplus.net> wrote:

Either I wasn't clear or you misunderstood. The first
player always rolls random, (he is the driver), after
each of his rolls the second player will be given an
equally lucky/unlucky roll (he is the passenger but
in the same car).

OK. This is not how I had understood it.

What I first wrote wasn't clear at all. I'm glad you are
still interested in the subject. I've been thinking more
on it for the past few days and working on an essay
combining it with what I had in mind before, while at
the same time giving you all time to digest the idea
and pursue it further.

Still, these pairs of similarly lucky rolls would lead to
some weird situations. For instance if player 1 rolls
a big doublet in a close race, so will player 2? If player
1 rolls badly in a bearoff against a low anchor and
exposes two blots, player 2 will roll badly as well and
miss them?

Such situations may arise if neither players owes any
equity to the other. Remember that a running balance
of equity will be kept and updated after every roll, so
that the "passenger" player can be given a better or a
worse roll. This is a key aspect of it. I hope you all do
undertand this.

Even if "equity balance" allows big doublets for both
players in a close race, they may not necessarily help
both players equally.

Player 2 with a low anchor is likely to get stuck behind
a block for a few rolls and "accrue" some "luck equity"
which will be given to him as soon as possible in one
of his next rolls. So, in your example above, he actually
may be given a "luck equalizing" roll that hits both blots.

I suspect that the manipulation to level out luck so
quickly would be more obvious and unnatural than
you think.

I'm not so sure that what you are saying will happen
even in equally skilled bot vs bot play because there
may/will be positions where the closest equity to be
given to player 2 may still be substancially different
than what player 1 rolls.

I'm pretty sure that things will look more natural in bot
vs human play, and even more natual in human vs
human play because error moves (or PR-sacrificing
moves) will be made. Skill will emerge maybe slower
than "normal" but more visibly and decisively, which is
actually exactly what it tries to accomplish.

You guys take your times. Think about it some more.
There is no need to rush. Once you understand well
enough I think you will recognize its value as another
"mutant tool" to experiment with, especially to observe
what happens to that so-called "cube skill theory" in
the absence of excessive luck swings...

In fact, I'm tempted to give it a bg variant name such
as LevelGammon, because people may come to like
playing it, especially against bots, (considering also
its added benefit that it would limit, if not eliminate,
any possible cheating by some bots;)

As I said, the code to pick a roll from the temperature
map is already there in Gnubg. You only need to add a
variable to keep a running tab on equity. I hope you will
see that with a minimal effort, this can be a very useful
tool and/or even a possible variant.

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On December 8, 2022 at 7:18:48 PM UTC-7, MK wrote:

As I said, the code to pick a roll from the temperature
map is already there in Gnubg. You only need to add
a variable to keep a running tab on equity. I hope you
will see that with a minimal effort, this can be a very
useful tool and/or even a possible variant.

I'm sure Philippe is more than capable of doing it
himself but because I would like to see this done
very much and thus motivate him to do it, I want
to contribute some effort myself also as a show
of goodwill.

In play.c there is a section that sorts the array of
equities for the 21 possible dice rolls. I think that
would be the best place to add one more line to
compare which array element is closest to the
"equity balance" of the "passenger player" and
save the array index for it in a variable.

And where it decides which nth best equity to roll,
add one more line to check if luck leveling option is
selected (i.e. 22nd level?) and use the above saved
index to roll the numbers from that array element,

You will need two more lines; one after each time
the "driver" player rolls, to add the max equity from
that roll to the "equity balance" of the "passenger"
player, and one after each time the "passenger"
player moves (or fails to move) to subtract the used
(or add back the unused) equity to/from his "equity
balance".

That should be all that is needed. Oh, of course, a
22nd option must be added to the drop-down list
where users select the level of "dice manipulation" ;)

Don't worry about whether it will lead to some weird
situations and such. Because it's so easy to do, just
do it please and let's all see what will come out of it,
whatever that may be...

MK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

You can try this yourself without having to code. I did this and played
10 games this way. Here is how to do this:

- Set GNU Backgammon to manual dice.
- Roll a pair of real dice (different colours) at hand
- Determine who starts (e.g. GNU Backgammon is assigned the red die)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)