Bug 298173 - Unfair advantage for higher-numbered players
Summary: Unfair advantage for higher-numbered players
Status: RESOLVED WORKSFORME
Alias: None
Product: konquest
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR major
Target Milestone: ---
Assignee: Pierre Ducroquet
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-15 10:12 UTC by Jeroen Vermeulen
Modified: 2022-11-13 05:14 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeroen Vermeulen 2012-04-15 10:12:40 UTC
User-Agent:       Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19
Build Identifier: 

The higher a player's number (i.e. the later they get to move), the better their chance of victory.  It's become almost impossible for Player 1 to win against larger numbers of players.  More often than not, the “last mover” will have conquered the rest of the galaxy while you're still securing your hold on your first conquest.

To verify that it's not just me being a bad loser, run a few tournaments between 4 or more equal computer players.  (Well, 2 will do but it's easier to spot the pattern with more).  Check out the end-of-game statistics display, and click on any of the column headings to sort from “weakest” to “strongest.” By any of these orderings, the order of the listing will be very close to Player 1 — Player 2 — Player 3 etc, as in the initial ordering.  With some room for chance, the higher a player's number the better they do.

Reproducible: Always

Steps to Reproduce:
Play a game involving similarly-skilled players (such as, for demo purposes, identical computer players).
Actual Results:  
Running 50 tournaments between two “Computer Normal” players, I found that Player 2 won 64% of the time, which means that its chances of victory are almost double those of Player 1.  (The effect is more obvious with larger numbers of players).

Expected Results:  
Equally-skilled players should have similar chances of winning.  In my tournament example, the outcome was two standard deviations away from the expectation of 50% — putting the likelihood of this happening in a fair game at 5% or so.

I think this happened when the minimum travel time for a fleet was dropped from 2 turns to 1 turn, so that you can send off an attack to an adjacent planet in one turn and own it next turn.
Comment 1 Alexander Schuch 2014-01-26 22:00:07 UTC
The "problem" seems to be that the last player is the one who gets the production. At some time I will do statistics on my own, but for now - what happens if you turn off "Production After Capture" in game setup? As far as I understand the problem, the production in the round after the capture seems to be what gives this advantage.
Comment 2 Thomas Kent 2015-09-19 23:58:57 UTC
Could it be set so that all attacks happen for all players, then production is calculated for all players for that round?
Comment 3 Justin Zobel 2022-10-14 05:46:55 UTC
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported and confirmed, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Comment 4 Bug Janitor Service 2022-10-29 05:02:08 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Bug Janitor Service 2022-11-13 05:14:23 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!