Introduction

Encoding a chess position is not just about where the pieces are standing right now. A full game state also includes side to move, castling rights, en passant availability, and move counters, and if you want to represent the whole game efficiently you usually store an initial position plus the moves rather than full snapshots after every turn.

What a Full Chess State Must Include

At minimum, a legal chess position needs:

• piece placement on 64 squares
• whose turn it is
• castling rights
• en passant target square if one exists
• halfmove clock for the fifty-move rule
• fullmove number

That is why a board array alone is not enough. Two positions with identical piece placement can still be different game states if one side can castle in one position but not in the other.

This is exactly the reason FEN exists. It is a compact snapshot format for a single position, not for a whole game.

Snapshot Encoding Versus Game Encoding

If you only need the current position, a snapshot format is fine. For example, many engines and tools store:

• a board representation in memory
• a FEN string for import and export

But for a whole game, repeatedly storing 60 full snapshots is wasteful. A better idea is:

1. store the initial position once
2. store each move in a compact form
3. reconstruct later positions by replaying the moves

That is the same reason PGN and UCI move lists are so practical. The game history compresses well because one move changes only a tiny part of the board.

A Compact Move Encoding

One simple approach is to encode each move as:

• source square: 6 bits
• destination square: 6 bits
• promotion piece or flags: remaining bits

The example below packs a simple UCI-style move such as e2e4 into an integer:

1files = "abcdefgh"
2
3
4def square_to_index(square):
5    file_index = files.index(square[0])
6    rank_index = int(square[1]) - 1
7    return rank_index * 8 + file_index
8
9
10def index_to_square(index):
11    file_index = index % 8
12    rank_index = index // 8
13    return files[file_index] + str(rank_index + 1)
14
15
16def encode_move(uci):
17    from_sq = square_to_index(uci[:2])
18    to_sq = square_to_index(uci[2:4])
19    promotion = 0
20    if len(uci) == 5:
21        promotion_map = {"q": 1, "r": 2, "b": 3, "n": 4}
22        promotion = promotion_map[uci[4]]
23    return from_sq | (to_sq << 6) | (promotion << 12)
24
25
26def decode_move(value):
27    from_sq = value & 0b111111
28    to_sq = (value >> 6) & 0b111111
29    promotion = (value >> 12) & 0b1111
30    promo_map = {1: "q", 2: "r", 3: "b", 4: "n"}
31    return index_to_square(from_sq) + index_to_square(to_sq) + promo_map.get(promotion, "")
32
33
34packed = encode_move("e2e4")
35print(packed)
36print(decode_move(packed))

This does not validate legality, but it shows how little information a move actually needs once you already know the board state.

Bitboards for In-Memory Speed

Chess engines often use bitboards rather than arrays because bit operations are fast. A common setup uses one 64-bit integer per piece type and color, for example:

• white pawns
• white knights
• white bishops
• and so on for all 12 piece sets

That makes move generation and attack calculations efficient, but it is still only part of the total state. You must keep the side-to-move and rights flags alongside the bitboards.

So a strong design is often:

• bitboards or arrays for live engine state
• FEN for single-position serialization
• move list encoding for entire game history

The Best Puzzle Answer Depends on the Goal

If the goal is human readability, FEN plus PGN is already excellent. If the goal is engine speed, bitboards win. If the goal is efficient long-term storage of a game, initial state plus compact move encoding is usually better than saving every board snapshot independently.

That is the key tradeoff. Board state and game history are related, but they do not have to be encoded the same way.

Common Pitfalls

• Encoding only the piece placement and forgetting castling rights, en passant, or side to move.
• Saving every position snapshot in a game when a move list would be much smaller.
• Designing a compact move format without enough bits for promotions or special flags.
• Confusing a position format such as FEN with a full game format such as PGN.
• Optimizing board representation before deciding whether the real problem is engine speed, storage, or readability.

Summary

• A full chess state includes more than just piece locations.
• FEN is good for one position, but a full game is usually better stored as an initial position plus moves.
• Compact move encoding can be very small because each move changes only a small part of the position.
• Bitboards are excellent for fast in-memory engine logic.
• The best encoding depends on whether you care most about speed, storage size, or human readability.