test content
Logo
What is the Arc Client?
Install Arc
A White/Silver colour option for powers?
arizoko
Posts: 20 Arc User
Rather surprised this isn't already a thing to be honest. I can understand not using the entire greyscale because colouring your abilities black might make some of them invisible, but you'd think there'd be at least one white option.
0
Comments
Epic Stronghold
Block timing explained
In order to get Black, White, or even Silver powers, CO would have to make multiple versions of every power in the game.
Black and White powers have to independant textures from the rest of the powers. The reason for this is because a white base texture does not change color regardless of the hue value applied to it, the same is also true for a black texture.
So in order for us to use Black, White, or even Grey, powers they must create a separate texture for each. Grey would actually be the easiest ones as they can simply grayscale filter the colored textures for grey. After the textures are made they then would have to code in a texture swap for the option.
This is where the actual problem lies. Cryptic in their infinite wisdom during early development of the game decided to hard code each and every power, rank, and advantage. There is no modularity to anything when it comes to powers. This means that for every alternate texture, sound, effect, or anything really, there has to be a separate version of the power made for every possible combination.
So to get black and white power colors Cryptic either has to be willing to create the extra duplicate powers which means all future adjustments to powers is even more of a coding nightmare... OR... they have to take the time required to rebuild the entire power list from the ground up in a modular database format.
"Hard coded" is one of those terms I'm not overly fond of, even though I've used it in the past as well. That phrase implies that something can never be changed, but as long as you have access to the source code, you can change literally anything. It's not that they must create separate textures for black and white versions, it's just that they decided doing so was the easiest route to take, not to mention safest because they don't have to really change any source code that way.
Huh. The fact that they have multiple things capable of activating powers (enemies, players, items) leads me to believe they already have a modular design.
Let's assume that the piece of data that makes up a list of which powers an object has (be it creature, player, device, or whatever) looks something like this, with "power" being a specific power from that list:
power.id; // reference id to the actual power
power.color = 0; // any tinting to be applied to said power, with 0 being an indicator for "default settings"
Certainly there's more than that, but this is all we're interested in right now. In just about any OOP language, it's not hard to add a new variable to a class (a class in this case is like a template for objects--in this case, the class defining the layout of an object in our power list) and assign it a default value. So we add...
power.brightness = 0; // adjusts brightness up or down, with 0 meaning "no change"
power.saturation = 100; // adjusts color saturation, with 100 meaning "full saturation"
Best case: These new variables and default values are retroactively applied to all existing objects descended from that class because they had the foresight to create a proper class/template.
Worst case: It isn't class-drived, but rather, an anonymous, generic object in which case you can't retroactively add new variables with default values because there's no template to work with. In this case, you can still catch the null/undefined values, convert them to the desired defaults, and add them as you go.
TL;DR: People get too hung up with why developers can't do something, but that's not how you solve problems. The only real reason a developer can't do something is because it's either too much work or too high of a risk for too little result, or because their boss specifically said, "you're not allowed to change this."
It was explained before by one of the devs that every individual version of a power is coded as an entirely separate power. Of course, they didn't touch on how the power tinting system is actually coded only that it uses hue shifting. So, it's very possible that there is a simple variable of Power.color that is adjusted by the power tinting menu.
From what we were told, every aspect of a power from it's base damage, cost, activation time, and cooldown, to it's animation, sound effects, graphics, and description; is all directly written into each individual power. Each power has to be written a minimum of 3 times (once for each power rank) and on top of that every additional advantage adds more copies of the power. This is the reason they did away with 0 point advantages because every 0 point advantage meant they had to create a duplicate of EVERY version of the power to add in the 0pt advantage version. Quite frankly, it's a terrible design.
I've pitched ideas about how to make black and white powers work before in the past when the devs were actively posting on the forums and talking with the players, and was met with the response that there just isn't any modularity to the power system to allow for it. In fact, one of the devs even stated that it's a miracle the power tinting system even works at all. It's entirely possible that they could just plug in a few extra variables and everything would just work how everyone wants it too, but it's also (at least according to the devs a few years back) entirely possible that simply plugging in a few extra variables could cause the system to stop functioning all together.
Don't get me wrong, I'm 100% skeptical of their claims. I have a background in both graphic arts and programming, so I'm well versed enough to know that the likelihood of an entire system breaking by adding in a new variable is highly unlikely. But, I do still understand their concern, since the coding required to implement a Brightness & Saturation setting could potentially create problems that have a chance of breaking the system, but the odds are still rather low.
Now... considering that every individual rank, advantage, and combination thereof, of a power is coded as an entirely separate power, it's actually unlikely that there is a template. Meaning, your worst case, they are anonymous generic objects, so it's a mountain of work to add the new setting.
They should have created a template from the onset, but they didn't. On top of that the powers system has been defined repeatedly as "spaghetti code" implying that not only is it an absolutely massive section of coding, but it's completely disorganized as well. Rank 1 of a power might have the coding of 300 other powers between it and it's Rank 2. One would assume that they have been reorganizing the section with each power set pass over the past couple years, which if they have been could potentially pave the way for improvements like this one. Considering it's been a highly desired feature for years on end as well, it may also even be plausible that they might have been making the necessary modifications to each power's code to allow for such a feature while they were working on the power, and sometime in the future after all powers have had their pass they might surprise us with "new Black and White power colors"
Generally, the only time I've ever run into issues with artifacts or flaws while manipulating these argb/hsb levels is:
1) When boosting saturation really high on an image with more than one color present--say a person's face--it creates ugly multi-color splotches and dots. This wouldn't pose a problem if the slider presented to the player treated the current saturation level as the maximum, allowing them to go between 0 (grayscale) and 100 (default saturation) but never higher than that.
2) When manipulating the alpha channel with multiple layers, parts where two or more layers intersect become less transparent than intended. The alpha channel is something a brightness and/or saturation adjustment shouldn't be touching so this should be a non-issue.
3) When turning brightness all the way up or all the way down. The former results in pure white while the latter results in pure black, although the alpha is preserved in either case. This kind of thing can be worked around by presenting the user with a slider that only allows them to adjust so far in either direction. Let's say -100 means pure black and 100 means pure white with 0 as the default. If you only allow them to adjust between say, -70 to 70, the effect becomes lighter or darker without resulting in a pure blackout/whiteout.
Epic Stronghold
Block timing explained
That said, if this game really is made in C then...hmm that's interesting. If I recall, sometime around 2008, Cryptic bought the rights to the Champions IP and the game came out in 2009. How long has this game, or at least the engine, been in development? O.o
And to think, STO and Neverwinter are built on this same engine. Jesus, I hope they at least ported it. No wonder they just make new black & white versions of things. I wouldn't want to touch code from that era either.
Which is most certainly late enough that object oriented languages were available. They just didn't use them, for whatever reason.
Epic Stronghold
Block timing explained
Get the Forums Enhancement Extension!