# Design an Extensible Animal-Chess Game Engine Design an object-oriented engine for a two-player, turn-based animal-chess game. The interviewer will supply the concrete board layout and rule table: piece ranks, legal movement, captures, terrain effects, and terminal conditions. Your engine must represent a game, validate and apply moves, expose immutable board state to callers, and make it possible to add or revise rules without rewriting storage or turn management. Pseudocode is sufficient. Explain the responsibilities of the main classes and walk through one move from request to committed state. ### Constraints & Assumptions - A move must be validated against one consistent game-state version. - Invalid moves do not mutate state or advance the turn. - Callers must not be able to modify internal board data through a returned object. - Concrete animal abilities should be data or rule components rather than a large switch spread across the codebase. ### Clarifying Questions to Ask - Is local play enough, or must the design persist multiple concurrent games? - Are undo, replay, clocks, or spectators required? - Which rules depend on terrain, piece type, or recent move history? - Must the engine support variants with different boards or win conditions? ### What a Strong Answer Covers - Clear separation among game state, rule evaluation, move orchestration, and persistence - Invariants for turns, occupancy, captures, and terminal games - Extensibility without making every piece responsible for global rules - Safe state exposure, test seams, and deterministic replay - Appropriate data structures and complexity for move validation ### Follow-up Questions - How would you add a piece whose move spans several squares? - How would you make two simultaneous move requests safe? - What belongs in a `Piece` class versus a rule service? - How would you reconstruct a game for debugging?