2048
Java implementation of 2048 with adjustable grid sizes, scoring + high-score persistence, and a polished desktop UI backed by tests and CI
Project Overview
This project is a Java implementation of the classic 2048 puzzle game, built as a clean Maven application with a desktop UI and a strong focus on correctness and maintainability.
The objective was not only to recreate the game, but to deliver a “real” software project: clear separation between the game engine and UI, reproducible builds, automated checks, and a release process that makes it easy for users to install and run.
What It Does
- Implements the full 2048 gameplay loop: grid state, moves, merges, tile spawning, and end-game conditions.
- Tracks current score and high scores, including high-score management per grid configuration.
- Supports adjustable grid sizes (from standard 4×4 up to larger configurations) to change difficulty and strategy.
- Enables multiple games per session, so users can restart and compare outcomes without restarting the application.
- Ships with a documented setup path via JAR releases or running from source with Maven.
Engineering Highlights
Clean architecture: engine vs UI
The project is structured around a core gameplay layer that owns the rules and state transitions, and a UI layer that renders the grid and exposes user controls.
- The gameplay core manages tile movement, merge rules, score updates, move tracking, and tile generation.
- The UI focuses on input handling, rendering, and user feedback (scores, settings, and end-game behavior).
This separation keeps the game logic testable and prevents UI concerns from leaking into the rules engine.
Score and high-score management
Beyond basic scoring, the project includes an explicit scoring backend and high-score tracking for different grid sizes. This supports replayability and makes “non-standard” grids feel like first-class modes rather than demos.
Polished UX
The UI work focused on making the game feel complete:
- Dedicated panels for scores and settings.
- Grid size selection at game start.
- Fixes for UI glitches and correctness issues around end-game scoring.
- Duration tracking to add a lightweight “session metric” alongside score.
Quality and Delivery
The project was treated like a production repository from day one:
- Unit tests run via
mvn test. - A broader
mvn verifyworkflow drives static analysis, coverage reporting, and dependency checks. - Spotless enforces consistent formatting.
- CI includes a release pipeline that publishes a runnable JAR, making installation straightforward for end users.
Technologies Used
| Technology | How it was used |
|---|---|
| Java | Core gameplay engine and application runtime |
| Maven | Build lifecycle, dependency management, test execution, and packaging |
| JavaFX | Desktop UI: grid rendering, panels, and input handling |
| JUnit | Unit tests to validate core behavior and prevent regressions |
| Spotless | Automated formatting to keep the codebase consistent |
| CI / Release Pipeline | Automated checks and publishing runnable artifacts |
Project History
Project bootstrap
Initialized the Maven project with testing, coverage reporting, static analysis, and SonarQube reporting to establish quality gates early.
Core game engine
Implemented the grid and move mechanics as a dedicated core class responsible for state transitions, score, move counting, and tile generation.
Desktop UI (JavaFX)
Built the grid-based UI layer and resolved UI edge cases to keep gameplay responsive and visually consistent.
Scores and game sessions
Added the score backend, high score management by grid configuration, and support for multiple games per session.
UX improvements
Added UI panels for score display and grid size selection, plus duration tracking and end-game score fixes.
Release and maintenance workflow
Added a release pipeline for publishing JARs, CODEOWNERS for maintainership, and formatting automation via Spotless.
Project Details
- Role
- Owner
- Client
- Desktop users
- Duration
- 1 month
- Published
