Connect Four And Grid Game Engines

What's being tested

Grid game engines test clean state modeling, turn validation, and efficient winner detection after each move. The core pattern is checking only lines crossing the last placed token, not rescanning the whole board.

Patterns & templates

• Board representation — use grid[rows][cols] plus heights[col]; drop(col, player) becomes O(1) placement with bounds checks.

• Last-move win check — after (r, c), scan four direction pairs: horizontal, vertical, diagonal down, diagonal up.

• Connect-N counting — count(dir) + count(opposite) + 1 >= n; each move costs O(n) or O(rows + cols) worst case.

• API design — expose move(col), getWinner(), isDraw(), currentPlayer; reject moves after win or into full columns.

• Generalization template — parameterize rows, cols, and target; validate impossible configs like target > max(rows, cols) carefully.

• Testing strategy — cover vertical, horizontal, both diagonals, full-column rejection, draw state, invalid player turns, and win-on-last-move cases.

Common pitfalls

Pitfall: Rescanning the entire board after every move is simple but often misses the intended optimization; anchor detection on the last token.

Pitfall: Diagonal logic is error-prone; define direction vectors once, such as (1,1) and (1,-1), then reuse symmetric counting.

Pitfall: Forgetting terminal-state behavior leads to bugs where players keep moving after a win or overwrite draw/winner state.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.