Player Color constraints and preferences

[paramesis]

A game I'm implementing has player colors fixed to a position on the board and the rules state that in a two player game, players must sit opposite of each other, so their colors must be a pair of red-blue or green-yellow.

This wouldn't be hard to resolve logically while keeping support for color preferences enabled, but given that we don't have access to the implementation details of reattributeColorsBasedOnPreferences, is there a way to determine whether a color's value was set by a player's preference after running this method, or more preferably, to query the player's preferences outside of this function?

[LaszloK]

Looking at the DB schema, it seems like you don't have access to this in-game.
What I would do if I were you is take a snapshot of what the colours are before the call to reattributeColorsBasedOnPreferences, and compare them with what you get afterwards.
Sure, you might sometimes end up in situations where it's not possible to determine which of the players had the preference that caused a change (e.g. red+blue getting changed to blue+yellow - did the 2nd player have a preference here, or only the first?) but you can make an educated guess - it won't always be right, but mostly it will, and you can attribute the rest to the fact that the game itself puts a limitation on what colours can be used.

[paramesis]

I can see why the DB wouldn't need to track that information for each game. Another solution I had come up with would involve randomly reducing the player colors to a valid pair, which would have a similar probability of producing a sub-optimal result. I just came up with a way to add certainty to the idea you suggested. You can prepend the game's color array with dummy colors that aren't in the game and aren't available as preference colors:

Code: Select all

$dummy_colors = array( "111111", "111112", "111113", "111114" );
$preference_canary = $gameinfos['player_colors'];
for ( $idx = 0; $idx < count( $players ); $idx++ ) {
	array_unshift( $preference_canary , array_shift( $dummy_colors ));
}
self::reattributeColorsBasedOnPreferences( $players, $preference_canary );

Any player whose color isn't one of the dummy colors has expressed a preference. You can then do some logic to determine the actual colors you want to present to players that wouldn't conflict. If both players have conflicting preferences, such as red and green, the winner will be decided randomly.

Code: Select all

$available_colors = $gameinfos['player_colors'];
// reduce available_colors to a valid pair of color preferences
self::reattributeColorsBasedOnPreferences( $players, $available_colors );

[LaszloK]

Well talk about a brilliant hack.

I wonder why you need the loop, can't you simply:

Code: Select all

$preference_canary = array_merge($dummy_colors, $gameinfos['player_colors']);

[paramesis]

array_merge works just as well. I was scared off by it the first time since I didn't quite understand how associative and indexed arrays work in php (coming from C++, I'm used to static typing).

With the game I'm implementing, there is also a prescribed turn order tied to colors. When player color preference is run, the natural player order (player_no) column apparently varies independently of the default player colors, which can lead to an incorrect turn order.

I could have the game state manually set the next player, but since the turn order never changes, I would prefer it to match the natural player order and the display order on the player status sidebar.

Would a sql UPDATE to reassign player_no before running self::reloadPlayersBasicInfos() have any side effects?

[vincentt]

Hi,

Maybe I am answering too late, but if your game has quite a huge logic about colors (turn order/position, etc.) maybe it is best to NOT change the colors to the preference of the users? If you do not trigger self::reattributeColorsBasedOnPreferences won't it make nothing?

It looks it will avoid a potential awkward situation or a bug report

Cheers

Vincent

[Victoria_La]

The BGA guidelines specifically forbid usage of reattributeColorsBasedOnPreferences if color has ANY significance, such as turn order. Because it provide unfair advantage for users who can choose colors.

[paramesis]

The BGA guidelines specifically forbid usage of reattributeColorsBasedOnPreferences if color has ANY significance, such as turn order. Because it provide unfair advantage for users who can choose colors.

Thanks, I missed the line in the main logic documentation after it mentioned Chess where it says any kind of color-determined player order cannot be used with color preference. I will happily disable it and move on.

I will say going down this rabbit hole has made me more comfortable with SQL queries.