# Design a Testable 2048 Game Engine Design the object model and core operations for a 2048 game. The engine must create a game, return the current board, apply a move in any of four directions, restart, and report whether the game is over. It should also be possible for an application service to store and retrieve multiple independent games. For one line in a move, nonzero tiles slide toward the chosen side. Equal adjacent values then merge once per move, from the movement side outward, and the resulting tiles slide again. A successful board-changing move asks a supplied tile generator for the next tile; an unchanged move does not. Focus on domain logic, not user-interface rendering. ### Constraints & Assumptions - Board size is configurable and at least two. - The tile generator is injected so tests can control placement and value. - A returned board must not let callers mutate the engine's state. - Define whether “game over” means no empty cell and no legal merge, independent of reaching a target tile. ### Clarifying Questions to Ask - Should the engine track score and move history? - Is undo required, and are games persisted across process restarts? - Can two clients submit moves to the same game concurrently? - What should happen if the tile generator cannot find an empty cell? ### What a Strong Answer Covers - Separation of board transformation, game lifecycle, randomness, and repository concerns - Correct one-merge-per-tile behavior for tricky lines - No-op move handling, defensive state exposure, and game-over detection - A concurrency or versioning strategy for multiple stored games - Deterministic unit tests for movement and restart ### Follow-up Questions - What should `[2, 2, 2, 2]` become after a move to the left? - How would you make replay deterministic? - Where should score calculation live? - How would the design support a different board size or spawning policy?