# Pieces

Home * Chess * Pieces

This is about Chess Pieces of Classical or Orthodox Chess. Other chess variants introduce Fairy chess pieces with different movement.

In chess terminology the term Piece is a bit ambiguous and may have different meanings - the term Chess Men is therefor often appropriate, since pieces otherwise don't include Pawns and even the King, but consider minor pieces, Knight and Bishop, and the major pieces (also heavy pieces), Rook and Queen. Rook, Bishop and Queen are so called sliding pieces, since they may "slide" in appropriate ray-directions as far they like - as long they are not hindered (blocked) by own or opponent pieces (which they may capture), with implications on move generation issues.

# Piece Coding

There are six types of pieces for each side, in total twelve different men. Since only one piece may occupy one square at a time, one usually expands the range of piece codes with the Nil-Piece aka empty square, often encoded as zero. Depending on the board representation, some programmers introduce an artificial blocking piece, which surrounds the embedded 8x8 boards inside a 10x12 board for cheaper off the board tests in offset move generation.

For cheaper extraction, most programmers prefer distinct coding of piece-types and the color of piece. Quite common is to use three bits to encode the piece-type plus one bit or Two's Complement (not recommend for languages with zero based array indices, like C, C++ or Java) for the color.

Other programs distinguish not only piece-type and color, but enumerate all 32 pieces from their initial position, which label or code does not change during the course of a game (even after a possible promotion of a pawn) and might be one-to-one associated with the bit-position of a 32-bit piece set, and/or are used to index a piece list containing the current square the piece resides on.

Lachex for instance used following enumeration scheme: the a1-rook was labeled with 1, b1-knight with 2, a2-pawn with 9, the a8-rook with 17 and the h7-pawn with 32. Beside a bitboard board-definition using 12 piece bitboards and occupancy as union set, Lachex used a redundant 8x8 board array, containing those 1..32 piece-codes, but zero for empty squares. Another piece-array contained the associated piece-types or zero if the piece is missing [2].

## Piece-Type Coding

Any enumeration of piece-type codes is fine. Harm Geert Muller proposed distinct white and black pawn codes inside the otherwise colorless range of piece-types, to take the different move-directions of pawns into account. This way piece-type completely specifies the mechanical move abilities, and three bits are still appropriate for a dense range to index tables or lookup-arrays, e.g. for Piece Values and that like. Often the order of enumeration is conform with the value of the pieces, for instance a C++ enumeration:

```enum EPieceType
{
ept_pnil   = 0, // empty
ept_wpawn  = 1,
ept_bpawn  = 2,
ept_knight = 3,
ept_bishop = 4,
ept_rook   = 5,
ept_queen  = 6,
ept_king   = 7,
};
```

## Piece Type and Color

One approach is to use negative values for black and positive for white (or color don't care) pieces. But if we like to index (zero based) arrays in C, C++ or Java by piece codes an offset has to be considered - also the Two's Complement needs abs-functions or additional indirection to extract the pure piece code, rather than to mask (and eventually shift) three bits. That is why most programmers rely on positive ranges only and concatenate the three piece-type bits with one color-bit, for instance the color at the big end.

``` PieceCode:4 = 8 * Color:1 + PieceType:3;
```

In C++ as enumeration:

```enum EPieceCode
{
epc_empty   = ept_pnil,
epc_wpawn   = ept_wpawn,
epc_woff    = ept_bpawn, // may be used as off the board blocker in mailbox
epc_wknight = ept_knight,
epc_wbishop = ept_bishop,
epc_wrook   = ept_rook,
epc_wqueen  = ept_queen,
epc_wking   = ept_king,

epc_blacky  = 8, // color code, may used as off the board blocker in mailbox
epc_boff    = ept_wpawn  + epc_blacky, // may be used as off the board blocker in mailbox
epc_bpawn   = ept_bpawn  + epc_blacky,
epc_bknight = ept_knight + epc_blacky,
epc_bbishop = ept_bishop + epc_blacky,
epc_brook   = ept_rook   + epc_blacky,
epc_bqueen  = ept_queen  + epc_blacky,
epc_bking   = ept_king   + epc_blacky,
};
```

To concatenate piece type and color the other way around is also quite common, color at the little end.

``` PieceCode:4 = 2 * PieceType:3 + Color:1;
```

## Disjoint Piece Flags

An alternative coding approach for most efficient inner loops with cheap test-instructions in scanning board arrays in conjunction with move generation, specially captures, is to encode pieces by five and up to eight disjoint bits (one byte). Each white and black piece has a disjoint color bit set, and appropriate bits may indicate a sliding piece, orthogonal or diagonal stepping or sliding etc.. One may even use one disjoint bit out of six per piece, yielding in exactly two bits set per regular piece code, for instance [3]:

Bit Binary Semantic
0 `0000 0001` White
1 `0000 0010` Black
combined (ored with)
2 `0000 0100` Pawn
3 `0000 1000` Knight
4 `0001 0000` Bishop
5 `0010 0000` Rook
6 `0100 0000` Queen
7 `1000 0000` King

## Encapsulation

There are a lot of possibilities to encode pieces, however surrounding source code should not directly rely on the binary representation and range of that codes, e.g. the semantic of a certain bit. In general, it is recommend to hide implementation details, likely in C++ inside a wrapper class with inlined getter and setter, or in C a set of C-Macros and functions that "wrap" an scalar integer type. A distinct type, e.g. a type definition in C/C++ is recommend for better compile time checking, other programmer still prefer (unsigned) integer types for passing pieces (and moves, colors and square coordinates) around.

On the other hand, one should not exaggerate abstraction, to be aware of an wrapped integer type is fine, and that bytes are appropriate to store an array of piece codes, which may easily zero-extended to wider types if passed via registers. If you intend to implement stuff like Zillions of Games or different Fairy Chess variants, it might be a reasonable idea, to design derived piece classes with virtual functions and late binding during runtime.

# Value of Pieces

and under the Evaluation topic:

# Printing and Drawing

## ASCII Art

ASCII art chess pieces, collected by Andreas Freise [4]:

```                                .      +
[]       ()    _,,       ()     ()
)(       )(   "-=\~      )(     )(       ()
)(       )(     )(       )(     )(       )(
ejm97 /__\     /__\   /__\     /__\   /__\     /__\

.      +
[]       ()    _,,       ()     ()
)(       )(   "-X\~      )(     )(       ()
)(       )(     )(       )(     )(       )(
ejm97 /XX\     /XX\   /XX\     /XX\   /XX\     /XX\
```

ASCII art Staunton chess set by David Moeser [5]

```    .::.
_::_
_/____\_        ()
\      /      <~--~>
\____/        \__/         <>_
(____)       (____)      (\)  )                        __/"""\
|  |         |  |        \__/      WWWWWW            ]___ 0  }
|__|         |  |       (____)      |  |       __        /   }
/    \        |__|        |  |       |  |      (  )     /~    }
(______)      /____\       |__|       |__|       ||      \____/
(________)    (______)     /____\     /____\     /__\     /____\
/________\   (________)   (______)   (______)   (____)   (______)
King        Queen       Bishop      Rook      Pawn     kNight
```

## Unicode

Name Symbol Code point HTML (dec) HTML (hex)
White King U+2654 &#9812; &#x2654;
White Queen U+2655 &#9813; &#x2655;
White Rook U+2656 &#9814; &#x2656;
White Bishop U+2657 &#9815; &#x2657;
White Knight U+2658 &#9816; &#x2658;
White Pawn U+2659 &#9817; &#x2659;
Black King U+265A &#9818; &#x265A;
Black Queen U+265B &#9819; &#x265B;
Black Rook U+265C &#9820; &#x265C;
Black Bishop U+265D &#9821; &#x265D;
Black Knight U+265E &#9822; &#x265E;
Black Pawn ♟︎ U+265F &#9823; &#x265F;