Marble Solitaire
peg solitaire engine · Java MVC
One abstract model powers three distinct boards: English, European and Triangle share all of their move, scoring and game-over logic and differ only in a board shape and a distance rule.
Select a marble to begin.
Pick a marble, then a highlighted hole two cells away to jump over a neighbour and remove it. Arrow keys move the cursor, Enter or Space selects. Same rules and three boards as the Java MVC engine.
Playable in your browser: pick a marble, then a highlighted hole two cells away to jump and remove. Same three board variants and rules as the Java engine.
The source for this course project is kept private. Request access through the contact form and I will gladly share the code and walk through it.
Request accessMarble Solitaire is the classic jump-and-remove peg game built for CS 3500: Object-Oriented Design as an exercise in clean architecture over clever logic. The code is split into a textbook MVC: a read-only state interface (MarbleSolitaireModelState) that view code consumes without being able to mutate the board, a mutating model interface that adds move and game-over operations, a text view, and a console controller driven by a Readable input and an Appendable output. The three boards (English 33-hole cross, European octagon, and a Triangle layout) are not three copies of the game: an AbstractMarbleSolitaireModel holds the shared move, scoring and game-over logic once, and each variant supplies only what differs through Template Method hooks (createBoard, hasValidDistance, isInvalidSize), so the Triangle, for example, simply widens the legal-distance check to allow diagonal jumps. A jump moves a marble two cells over an adjacent marble into an empty hole, removing the jumped marble, until either one marble remains (win) or no legal move exists (game over). Backed by 169 JUnit tests across seven files covering each model, view and the controller.
- Java
- MVC
- Template Method
- Interface design
- JUnit
- OOP
- Board variants
- 3 (English, European, Triangle)
- Architecture
- MVC + Template Method
- Tests
- 169 JUnit across 7 files
- English board
- 33-hole cross, 32 to clear
What I'd improve
The console controller couples turn parsing, quit handling and rendering in one loop: I would lift input parsing into its own component and add a pluggable move source so an AI solver or a GUI could drive the same model. The README also over-promised features the code never shipped (an auto-solver, redo, colour themes), a useful reminder to let the tests and the source define the scope, not the pitch.