Difference between revisions of "Team Color Shifting"

From The Battle for Wesnoth Wiki
m (TeamColorShifting moved to Team Color Shifting)
m
Line 1: Line 1:
 +
by Richard Kettering (Jetryl)
 +
 
===How to make units which conform to the system that lets us shift team colors.===
 
===How to make units which conform to the system that lets us shift team colors.===
  

Revision as of 08:44, 30 December 2005

by Richard Kettering (Jetryl)

How to make units which conform to the system that lets us shift team colors.

Any team color shifting system needs a way of indicating which areas of the graphic are to be changed in color. Ours solves this by selecting a certain range of colors, and shifting the pixels whenever they are that source color in the unit image. In our system, this can be done with any set of colors that you choose, on a per-unit basis. There are other ways that this could have been done, but this one was chosen for several reasons. For one thing, if we had used special grayscale image maps to indicate what to change, they would have basically doubled the number of images used by the game. The notable disadvantages of our system are that the colors which get shifted away are inaccessible for use, which is a minor issue, and that we only have a binary choice of a pixel getting shifted, which is a somewhat more major limitation, albeit one which is worth working around.

These colors are defined in the unit .cfg file. They are defined as follows, for an example in which we shift the colors black and white:

 flag_rgb=0,0,0,255,255,255

Note that these shift ONLY the precise RGB values given - do not confuse color with hue, because every specific shade - every specific instance with a different luminosity and saturation value - must be specified separately.

The game will shift the color set to one of the team colors; in doing so it will completely overrun the saturation of the original color (E- not sure about that). It will change the hue to that of the team, and shift the luminosity as well. The coloration you give is set in terms of relative luminosity - the entire patch may be bright or dark depending on which team the unit is on.

Also note that the first color specified is special, because it is treated as the median value, and will be assigned the precise luminosity value of the team color. Anything brighter than it will be brighter than the team color, anything darker will be darker.


WorkFlow:

There are two general ways to do things. No matter what, you need a patch of color on the target unit which is separate from other colors, and is contiguous. It is best if this is only on specific sections, and does not have any stray pixels lying around in other areas of the image.

This can, on very rare occasions, be done to existing graphics with no changes in the target image; however it is almost always best to redesign the unit around use of the team color system. In this, you often go so far as to change the costuming, and to include props showing the team color which would not have been included before.

Possibly the easiest way to do this, to a reworked image, is to define a new layer in a capable program (photoshop, gimp, etc), overlaid on the rest of the image, in which you draw with a color that will stick out like a sore thumb. Magenta has often been used for this because it largely has no use as a normal color for general unit graphics.

colorswatch_200.png

We've actually defined a WML macro to specify a set of magenta colors, as seen in the previous palette. To use this, you simply sample the color with your graphics program's eyedropper tool, and then draw with it. The macro is used just like the flag_rgb business - you simply insert the following in your unit .cfg file (for reference, the macro itself is defined in utils.cfg):

 {MAGENTA_IS_THE_TEAM_COLOR}


Time-Saving Tips:

If units are drawn with a small color set, as used in traditional sprite art, you can use a properly-set paint-bucket tool to replace all instances of a given color. You'll want to set it to be non-contiguous, non-antialiased and to have a tolerance of 0 (presumably, you also want it to fill based on "all layers" - these settings are based on Photoshop, and the Gimp is likely similar).

If someone used a "non-traditional" spriting technique (such as jetryl or wayfarer, using a paintbrush instead of a pencil tool), you're not out of luck at all. Simply take the same paint-bucket tool with the same settings, and crank the tolerance up to about 20-30. The paint-bucket will then affect all of those similar, subtle gradations in shade which were achieved with the paintbrush tool, replacing them all with a single color. Use this with progressively lighter shades, and you'll fill in 90% of the target area, after which it is trivial to fill the holes left behind with a pencil tool.

Also, if you'd like a sane representation of what the final colors will look like, you can shift this separate team-color layer in your graphics application by using a temporary hue/saturation filter on that layer (I use +40 to the hue on the magenta colors to give a red hue similar but not identical to the one which the game uses).

Finally, to keep things intuitive, if you are using the magenta swatch, which you should, it is often easiest to simply sample the colors from a unit to which this has already been applied.


Screenshots

This is a screenshot of what a unit looks like with his team color layer turned off - this is the graphic before the edit, essentially:

tcpatch_off_140.png

This is a screenshot of the team color layer itself. Note that it is only what is changed:

tcpatch_alone_654.png

And this is what the combined image looks like, which will get mixed-down into a single PNG file:

tcpatch_on_180.png


See Also