On private/community hosted/moderated servers my experience was that cheating was mostly a non-issue. Only with the advent of forced matchmaking/only official servers and such has it become a real problem.
Mostly by looking at the calling site where the code is already used and the calling site where I want to reuse it. If both of those mean the same (calculate the tax on x products, for the purpose of applying to the shopping cart, vs for applying to generating reports) then I'll reuse it, if it can be achieved without adding stuff like flags, in most cases. In other cases, it just looks the same (sum some field + calculate a percentage of that, for example, for discounts vs taxes on products) where it's obvious that they don't mean the same. (Though, I do heavily rely on a good type system to deal with future evolutions of that copied code)
My metric for that is "does that code MEAN the same thing" or "does it just look the same". Has worked quite well for me so far. I frequently find myself making a copy of some code rather than adding a parameter (most commonly done with code that would get some flag added)
I assume to split the overall behaviour (loop through all elements, transform some value, etc) and the specific one (apply this function to all elements, transform it in this way, etc) into multiple functions and combine those to achieve the actual intended behaviour.
Oh right. Guess the " (2 bits per color? how is that possible)" is what threw me off there, because I read it as 2 bits per colour channel, rather than cga colour. Of course, "indexed" colours can get away with much fewer bits.
this is probably a rhetorical question, but lemme answer anyways: By packing the colour channels into a single byte. So, for example, you'd have RRGGBBAA within a single byte, for each pixel. Giving you 64 possible colours, with 4 steps of alpha.
Or if you don't need to have alpha, you could pack it even further down to RRGGBB in a byte, which leaves 2 bits left over for the next pixel. Via that, you can pack four pixels worth of colour data into 3 bytes: RRGGBBRR|GGBBRRGG|BBRRGGBB (italics for delineting pixels, vertical bars for delineting bytes)
The latter is a tradeoff between compression and a more complex accessing pattern.
A bit of a tangent, some system used RRRGGGBB for colours, because the eyes are the least sensitive to differentiating the amount of blue, so that's another way to use up a full byte per pixel.
The movement explicitly DOESNT want to force companies to keep their servers running. It is singularily concerned with keeping games playable in some form after shutdown. Be it via patching out the requirement on a server, providing a way to host it yourself or any other option, really.
Battle passes/mtx would IMO definitely fall under monetary considerations, which would make the excemption not apply. But as is written now, there still needs to be a precedent set for that, to really cement that interpretation
My comment was not meant as any form of value judgement upon the game at all. Only that it is an example I could think of where the death of the game was communicated upfront and where it was expected.
It's not endless support but more "Don't stop me from playing the game". For example, win xp is no longer supported. You can still use it.
For a lot of games the current situation is essentially the same as "The OS is no longer profitable enough, so the developer prevents you from using it"