Colors

Note that the Documentation does not display colour the way it would look on the screen.

Color can be a very useful tool for your game. It can be used to increase readability and make your game more appealing visually.

Remember however that, with the exception of the webclient, you generally don’t control the client used to connect to the game. There is, for example, one special tag meaning “yellow”. But exactly which hue of yellow is actually displayed on the user’s screen depends on the settings of their particular mud client. They could even swap the colours around or turn them off altogether if so desired. Some clients don’t even support color - text games are also played with special reading equipment by people who are blind or have otherwise diminished eyesight.

So a good rule of thumb is to use colour to enhance your game but don’t rely on it to display critical information. If you are coding the game, you can add functionality to let users disable colours as they please, as described here.

Evennia supports two color standards:

  • ANSI - 16 foreground colors + 8 background colors. Widely supported.

  • Xterm256 - 128 RGB colors, 32 greyscales. Not always supported in old clients.

To see which colours your client support, use the default color command. This will list all available colours for ANSI and Xterm256 along with the codes you use for them. The central ansi/xterm256 parser is located in evennia/utils/ansi.py.

ANSI colours

Evennia supports the ANSI standard for text. This is by far the most supported MUD-color standard, available in all but the most ancient mud clients.

To colour your text you put special tags in it. Evennia will parse these and convert them to the correct markup for the client used. If the user’s client/console/display supports ANSI colour, they will see the text in the specified colour, otherwise the tags will be stripped (uncolored text).

For the webclient, Evennia will translate the codes to CSS tags.

Tag

Effect

|n

end all color formatting, including background colors.

|r

bright red foreground color

|g

bright green foreground color

|y

bright yellow foreground color

|b

bright blue foreground color

|m

bright magentaforeground color

|c

bright cyan foreground color

|w

bright white foreground color

|x

bright black (dark grey) foreground color

|R

normal red foreground color

|G

normal green foreground color

|Y

normal yellow foreground color

|B

normal blue foreground color

|M

normal magentaforeground color

|C

normal cyan foreground color

|W

normal white (light grey) foreground color

|X

normal black foreground color

|[#

background colours, e.g. |[c for bright cyan background and |[C a normal cyan background.

|!#

foreground color that inherits brightness from previous tags. Always uppcase, like |!R

|h

make any following foreground ANSI colors bright (no effect on Xterm colors). Use with |!#. Technically, |h|G == |g.

|H

negates the effects of |h, return foreground to normal (no effect on Xterm colors)

|/

line break. Use instead of Python \n when adding strings from in-game.

|-

tab character when adding strings in-game. Can vay per client, so usually better with spaces.

|_

a space. Only needed to avoid auto-cropping at the end of a in-game input

|*

invert the current text/background colours, like a marker. See note below.

Here is an example of the tags in action:

 |rThis text is bright red.|n This is normal text.
 |RThis is a dark red text.|n This is normal text.
 |[rThis text has red background.|n This is normal text.
 |b|[yThis is bright blue text on yellow background.|n This is normal text.

Note: The ANSI standard does not actually support bright backgrounds like |[r - the standard only supports “normal” intensity backgrounds. To get around this Evennia implements these as Xterm256 colours behind the scenes. If the client does not support Xterm256 the ANSI colors will be used instead and there will be no visible difference between using upper- and lower-case background tags.

If you want to display an ANSI marker as output text (without having any effect), you need to escape it by preceding its | with another |:

say The ||r ANSI marker changes text color to bright red.

This will output the raw |r without any color change. This can also be necessary if you are doing ansi art that uses | with a letter directly following it.

Use the command

color ansi

to get a list of all supported ANSI colours and the tags used to produce them.

A few additional ANSI codes are supported:

Caveats of |*

The |* tag (inverse video) is an old ANSI standard and should usually not be used for more than to mark short snippets of text. If combined with other tags it comes with a series of potentially confusing behaviors:

  • The |* tag will only work once in a row:, ie: after using it once it won’t have an effect again until you declare another tag. This is an example:

    Normal text, |*reversed text|*, still reversed text.
    

    that is, it will not reverse to normal at the second |*. You need to reset it manually:

    Normal text, |*reversed text|n, normal again.
    
  • The |* tag does not take “bright” colors into account:

    |RNormal red, |hnow brightened. |*BG is normal red.
    

So |* only considers the ‘true’ foreground color, ignoring any highlighting. Think of the bright state (|h) as something like like <strong> in HTML: it modifies the appearance of a normal foreground color to match its bright counterpart, without changing its normal color.

  • Finally, after a |*, if the previous background was set to a dark color (via |[), |!#) will actually change the background color instead of the foreground:

    |*reversed text |!R now BG is red.
    

For a detailed explanation of these caveats, see the [Understanding Color Tags](Understanding-Color- Tags) tutorial. But most of the time you might be better off to simply avoid |* and mark your text manually instead.

Xterm256 Colours

The Xterm256 standard is a colour scheme that supports 256 colours for text and/or background. It can be combined freely with ANSI colors (above), but some ANSI tags don’t affect Xterm256 tags.

While this offers many more possibilities than traditional ANSI colours, be wary that too many text colors will be confusing to the eye. Also, not all clients support Xterm256 - these will instead see the closest equivalent ANSI color. You can mix Xterm256 tags with ANSI tags as you please.

Tag

Effect

|###

foreground RGB (red/green/blue), each from 0 to 5.

|[###

background RGB

|=#

a-z foreground greyscale, where a is black and z is white.

|[=#

a-z background greyscale

Some examples:

Tag

Effect

|500

bright red

|050

bright green

|005

bright blue

|520

red + a little green = orange

|555

pure white foreground

|230

olive green foreground

|[300

text with a dark red background

|005|[054

dark blue text on a bright cyan background

|=a

greyscale foreground, equal to black

|=m

greyscale foreground, midway between white and black.

|=z

greyscale foreground, equal to white

|[=m

greyscale background

Xterm256 don’t use bright/normal intensity like ANSI does; intensity is just varied by increasing/decreasing all RGB values by the same amount.

If you have a client that supports Xterm256, you can use

color xterm256

to get a table of all the 256 colours and the codes that produce them. If the table looks broken up into a few blocks of colors, it means Xterm256 is not supported and ANSI are used as a replacement. You can use the options command to see if xterm256 is active for you. This depends on if your client told Evennia what it supports - if not, and you know what your client supports, you may have to activate some features manually.