Why can't everyone have their preferred color?

[Bray]

I've been a professional programmer for over 20 years fwiw This should not be hard in a reasonable code base.

30 here. What evidence do you have that we're dealing with a reasonable code base?

I've wanted this feature for years. I assume we'll never see it.

[FrankJones]

I've been a professional programmer for over 20 years fwiw This should not be hard in a reasonable code base.

30 here. What evidence do you have that we're dealing with a reasonable code base?

I've wanted this feature for years. I assume we'll never see it.

Am I missing something?
Why are people talking as though this would need to be an "all-or-nothing" implementation for every game on the entire site?
If an individual game developer wanted to implement this for a specific game (Let's say Terraforming Mars), that's feasible, right?

[BarnardsStar]

I've been a professional programmer for over 20 years fwiw This should not be hard in a reasonable code base.

30 here. What evidence do you have that we're dealing with a reasonable code base?

I've wanted this feature for years. I assume we'll never see it.

Am I missing something?
Why are people talking as though this would need to be an "all-or-nothing" implementation for every game on the entire site?
If an individual game developer wanted to implement this for a specific game (Let's say Terraforming Mars), that's feasible, right?

Depends on what exactly you had in mind. If you wanted to go with the preferred user colors in your sitewide preferences page, then that’s administered by the site and I do not believe games have the ability to alter it. The user may say “I prefer magenta, turquoise, vermillion, and beige in that order” but I think all the game gets is “this player is turquoise, this other one is yellow, and this last one is puke green”. To do something different there would need to be at least some sitewide change so games could access your actual preferences. Right now when the game is told you’re red, I don’t even know if the game has any idea it’s your preference or just random assignment,

If the game wanted to have its own preferences separate from the site, that might be possible? But I haven’t looked at BGA Studio at all, so I don’t know whether the game can currently do that either.

[nik592]

Am I missing something?
Why are people talking as though this would need to be an "all-or-nothing" implementation for every game on the entire site?
If an individual game developer wanted to implement this for a specific game (Let's say Terraforming Mars), that's feasible, right?

The other problem with this is that such a feature would SEEM like a website feature, not a per game feature. I only play TM and get used to it. One day I decide to plau Wingspan and it doesn't do this - oh no! Must be a bug!

Thiis already happens, as some games choose to ignore player preferences. Sometimes with good reason (eg. in Terra Mystica, you have to choose your faction and that determines your player colour), sometimes because of program difficulties of some kind? (eg. https://boardgamearena.com/bug?id=191730) But sometimes for no (stated) reason at all. (eg. https://boardgamearena.com/bug?id=108210)

So again I say, minimal benefit. Increased support overheads. Feels unlikely. My opinion based on 19 years of coding experience (and about 6+ of purely debugging/analysing bugs and referring them for fixing).

[FrankJones]

This is absurd.

So, we can have a system that queries a player's preferred color and assigns that color to that player, but we cannot write code that simply modifies how that player cubes visually appear on one player's screen ?????

[nik592]

Setting a player's preferred colour - or rather attempting to, as you also have to contend with other player's colour preferences so may not get yours anyway - is a feature of the game state as a whole. You can set it once - Nik is red, Frank is purple, etc. Having my screen display as purple is an on-the-fly feature. Both Nik and Frank want purple, so in Nik's game, Frank is red and vice versa. Let's say you've got 5 players at the table and they all want to be purple. Now you have five different game states to maintain as each player's set of colour-player settings have to be slightly different. It's not just a matter of setting YOUR colour but everyone else's colour too. Whereas if it's consistent, you're just looking in one place and you know on all displays, Frank's pieces are purple.

It's different to a background like in TM too - that's basically an on or off feature on one display. Two states. Having different colours displayed is n different states where n is the number of players. In addition, preferred colour for each player is ALSO a list of options. It's not just purple or I don't care, it's purple, then red, then blue, then teal, then orange, then black, etc. And it also depends what colours are available in the game. Making that decision once isn't too difficult. Making that decision every time each player loads the game is a lot harder.

Also, I'm commenting VERY generally. I've never looked at BGA code. Maybe you're right and it's easier than I'm thinking. But if it were, perhaps it would have been considered by now, at least on a per-game basis as you say? It's not like this is the first time it's being discussed and that there aren't bugs in about it. I'm simply offering some reasons why it may not have been implemented (as I think others are).

[BarnardsStar]

So, we can have a system that queries a player's preferred color and assigns that color to that player, but we cannot write code that simply modifies how that player cubes visually appear on one player's screen ?????

To be honest my concerns here are somewhat speculative. I don’t know the site code, but I do have an idea what code that originates as a passion project of two guys in a garage would probably look like 15 years later. Which is another way of saying: yes, it really depends on how well organized the site code is… Code like this site certainly can be well-organized and modular and such if careful attention was paid to keeping it that way, but without that sort of attention code often tends to sprawl somewhat organically.

It’s entirely possible it could be easy. Everything I’ve learned through experience says it probably wouldn’t be, and they’d probably spend years picking off bugs that originate through such a change.

Now, a browser extension that was tailored game by game (like tof63’s extension) would be comparatively pretty easy, most likely. Stylesheets would be easy, and figuring out which game resources to swap out (“the site says she’s orange but I know where the blue meeple images are so I’ll substitute them instead”) would only be a little harder.

“Why can’t the site just do that?” you probably ask, and sure, it could, but the layers between your preferences and the games would all have to be modified. I don’t know how many layers there are, but that’s the main place I’d anticipate trouble. Assumptions were almost certainly made in the initial design and fixing those assumptions, everywhere that interacts with this code… well, I just don’t think it would be easy.

[dschingis27]

I can only agree with the two previous posters.

FrankJones, you make it sound like you have to change something in the code only in one place. But that is very likely not the case.

We have game logs and also we have replays on BGA. You probably need to change somehting there, too. You need to define color rules not only for the players playing but also for the external observer, and make it work for everyone in replays again. Then we have hotseat mode which might cause some trouble if one player with color preferences plays is on the same device like another player. (Shouldn't cause trouble but does it not?)
This is all doable and it might be easier than we make it sound. Or not. We don't know. The effort in a code change is usually not about how intellectually hard the feature itself is to code, but how it interfaces with the other systems, and how well maintained and synchronized everything is.

Our coding experience and intuition tells us that this change would cause more trouble than how it looks on the surface. I think that happened to every professional coder, you wanted to make a small change but you ended up making a lot of changes and debugging to make it work all the time. This change is indeed probably easier done on a game by game basis but then it's also inefficient and game developers have to deal with things like replays which they are not supposed to deal with.

The other thing you want to consider is risk. This is an operation at the very heart of BGA or at the very heart of a game. Even if a heart surgeon tells you that the operation they are going to do is very easy, you still have a hard time to decide to make a heart operation. It's similar in a code base. Recently BGA made a change in the visual look of the bugs section or made a change how and which emails are send, these are low-stakes operations. But changing the game state on screen is a high-stakes operation, nothing must go wrong, otherwise it's disaster.

[dschingis27]

Teasing? As in making fun of? Really? I’m willing to concede my jokes aren’t always funny (whose are?), but I frankly do not see a reasonable interpretation of my words that assigns a negative trait to you, makes fun of you, subjects you to ridicule, or makes you look less than to the other participants here. I would genuinely be interested to hear if others reading this think I’m in the wrong here.

Yes, I perceived it as teasing at least and I did not think it was a good joke. Particularly because your point ("edge cases") was mentioned before, it came across as "you junior developer are not listening!" Pondering on a point that was already made in the way you did will often create bad vibes.

But already your start was bad. "If you’ve been a developer that long you should recognize" The usage of "should" here devalues the other person. Because "should" can imply that the other person "did not do correctly" but "should have instead" and it is bonkers to assume that a 20 year experienced programmer does not recognize edge cases.

What you can write instead (but even that could be perceived negative):
"You’ve been a developer that long, you will recognize". Not starting with "If" avoids doubting the experience of the other one, using "will" instead of "should" fully acknowledges the other person's state of experience. It focuses your sentence on the point you are going to make rather than making it sound like a comment on the other one's intellectual integrity.

In general, if you put anything in an if-clause that another person stated as fact about themself, you will get negative reactions. Why put it in an if-clause? It suggests you don't trust the person that stated it (which is sometimes definitely warranted but will never be perceived as neutral).

[FrankJones]

I can only agree with the two previous posters.

FrankJones, you make it sound like you have to change something in the code only in one place. But that is very likely not the case.

We have game logs and also we have replays on BGA. You probably need to change somehting there, too. You need to define color rules not only for the players playing but also for the external observer, and make it work for everyone in replays again. Then we have hotseat mode which might cause some trouble if one player with color preferences plays is on the same device like another player. (Shouldn't cause trouble but does it not?)
This is all doable and it might be easier than we make it sound. Or not. We don't know. The effort in a code change is usually not about how intellectually hard the feature itself is to code, but how it interfaces with the other systems, and how well maintained and synchronized everything is.

Our coding experience and intuition tells us that this change would cause more trouble than how it looks on the surface. I think that happened to every professional coder, you wanted to make a small change but you ended up making a lot of changes and debugging to make it work all the time. This change is indeed probably easier done on a game by game basis but then it's also inefficient and game developers have to deal with things like replays which they are not supposed to deal with.

The other thing you want to consider is risk. This is an operation at the very heart of BGA or at the very heart of a game. Even if a heart surgeon tells you that the operation they are going to do is very easy, you still have a hard time to decide to make a heart operation. It's similar in a code base. Recently BGA made a change in the visual look of the bugs section or made a change how and which emails are send, these are low-stakes operations. But changing the game state on screen is a high-stakes operation, nothing must go wrong, otherwise it's disaster.

Fair enough - I trust the experienced programmers in this thread - as I have said (I think?), I'm an amateur hobbyist programmer with no real-world experience. To me, it seems easy, but I trust you all when you say it's not as easy as I think it is. I wish I had advanced further in my studies so I could perhaps try to implement this, but, I got burnt out and moved on to other things.

And, there are numerous other UI improvements that I consider more important. I appreciate everyone's input.