EngineersofAI LogoCoursesBlogResearch LabAI LettersThe LabCode BankInteractive 3DKodrEarnestJobs
Skip to main content

Chess Move Validator

Chess looks elegant.

But underneath that elegance is strict logic.

Every piece:

  • Moves in specific patterns
  • Cannot violate board boundaries
  • Cannot teleport
  • Cannot move randomly

There are no approximations.

Either a move is valid
or it is not.

This project trains:

  • Rule encoding
  • Coordinate reasoning
  • Conditional logic
  • System constraints

We are not building full chess.

We are validating moves.

What You Are Building​

You will create a program that:

  • Takes a chess piece (rook, bishop, knight, etc.)
  • Takes a starting position (like e2)
  • Takes a target position (like e4)
  • Determines whether the move is valid based on piece rules

We will not:

  • Handle captures
  • Handle check/checkmate
  • Handle board occupancy (initially)

This is rule validation only.

Why This Project Matters​

Chess is perfect because:

  • It forces spatial thinking.
  • It forces rule clarity.
  • It forces precise condition handling.
  • It exposes logical gaps immediately.

This is computational thinking in pure form.

Watch First​

Step One - Represent the Board​

Chess board:

  • Columns: a–h
  • Rows: 1–8

We must convert positions like "e2" into numeric coordinates.

Example:

a → 1
b → 2
...
h → 8

Let’s write a simple converter.

def position_to_coords(pos):
    column = ord(pos[0].lower()) - ord('a') + 1
    row = int(pos[1])
    return column, row

Now "e2" becomes (5, 2).

This allows mathematical reasoning.

Simple Solution - Rook Validator​

Start small.

The rook moves:

  • Horizontally
  • Vertically

So a move is valid if:

  • Same row
    OR
  • Same column
def is_valid_rook(start, end):
    start_col, start_row = position_to_coords(start)
    end_col, end_row = position_to_coords(end)

    if start_col == end_col:
        return True
    if start_row == end_row:
        return True

    return False

That’s it.

Clean. Direct.

Pause and Think​

What happens if:

  • Start equals end?
  • Position is outside board?
  • Input is malformed?
  • Case sensitivity differs?

The naive solution assumes perfect input.

Engineers do not assume perfect input.

Improve It - Add Validation​

We now improve structure.

def is_within_board(col, row):
    return 1 <= col <= 8 and 1 <= row <= 8


def is_valid_rook(start, end):
    start_col, start_row = position_to_coords(start)
    end_col, end_row = position_to_coords(end)

    if not is_within_board(end_col, end_row):
        return False

    if start == end:
        return False

    return start_col == end_col or start_row == end_row

Now the system is safer.

Add Another Piece - Bishop​

A bishop moves diagonally.

Diagonal condition:

|col difference| == |row difference|
def is_valid_bishop(start, end):
    start_col, start_row = position_to_coords(start)
    end_col, end_row = position_to_coords(end)

    return abs(start_col - end_col) == abs(start_row - end_row)

This is where computational thinking shines.

We converted geometry into arithmetic.

Knight - The Non-Linear Case​

Knight moves in L-shape:

  • 2 in one direction
  • 1 in the other
def is_valid_knight(start, end):
    start_col, start_row = position_to_coords(start)
    end_col, end_row = position_to_coords(end)

    col_diff = abs(start_col - end_col)
    row_diff = abs(start_row - end_row)

    return (col_diff, row_diff) in [(2, 1), (1, 2)]

Notice how clean this becomes once coordinates are numeric.

Now We Refactor - Better Structure​

Instead of separate functions, we can generalize.

def is_valid_move(piece, start, end):
    piece = piece.lower()

    if piece == "rook":
        return is_valid_rook(start, end)
    elif piece == "bishop":
        return is_valid_bishop(start, end)
    elif piece == "knight":
        return is_valid_knight(start, end)
    else:
        return False

Now we have a rule dispatcher.

Structure is emerging.

Where This Gets Interesting​

We are currently:

  • Ignoring other pieces
  • Ignoring blocked paths
  • Ignoring captures
  • Ignoring board state

But already you see:

  • Abstraction emerging
  • Reusability forming
  • Logic separation happening

This is how systems grow.

Edge Case Thinking​

Ask yourself:

  • Should we validate input format first?
  • What if user enters "z9"?
  • Should we prevent zero movement?
  • Should we normalize case?

Edge cases are where systems break.

Growth Reflection​

Right now:

  • Each validation is constant time.
  • We check only coordinate difference.

Now imagine:

Full chess engine.

  • Board occupancy
  • Move history
  • Special rules (castling, en passant)
  • Check detection

Now complexity grows.

Structure must scale.

Interview Extension​

If asked in interview:

Improve the validator to:

  • Reject moves blocked by other pieces
  • Add pawn logic (forward vs capture)
  • Handle castling rules
  • Represent board as 2D list
  • Prevent king from moving into check

Now you’re thinking system-level.

Engineering Reflection​

Chess forces precision.

There are no “almost correct” moves.

Either rules are encoded correctly
or they are wrong.

This project teaches:

  • Rule clarity
  • Mathematical reasoning
  • Defensive design
  • Clean function separation

That is computational thinking.

Final Thought​

If you can encode chess movement cleanly,

You can encode:

  • Access control systems
  • Validation engines
  • Policy enforcement systems
  • Business rules

Because all of them are rule engines.

And rule engines demand clarity.

© 2026 EngineersOfAI. All rights reserved.