THE RULES BEHIND THE SOFTWARE
Set
A concurrent Set game where independent player threads share a dealer-controlled table.
Independent selections.
One dealer decides what happens next.
Code-native explanation of the implementation. Illustrative data.
- CONTEXT
- University coursework
- MY ROLE
- Sole developer
- TIMELINE
- 2022
- EVIDENCE
- Source reviewed · illustrative diagrams
AT A GLANCE
Two players. One contested triple.
A Java concurrency assignment turns the card game into a coordination problem: keyboard and computer players submit selections while a dealer validates sets, awards points, replaces cards and manages the round timer. The engineering story is the boundary between independent input, shared table state and centralized validation.
My contribution +
I implemented the player, dealer and shared-table coordination within the supplied university game framework.
WHAT THE SYSTEM HANDLES
The interesting parts.
Independent players, one shared table
Each player runs on a separate thread. Bounded input and candidate queues connect player actions to the dealer, while synchronized table operations maintain card and token state.
Implementation details
- Human input maps configured keys to player and slot.
- Computer players generate random key presses; they are not strategic solvers.
- The checked-in configuration starts four computer players and zero human players.
Validate, score and refill
The dealer converts a three-token selection into cards, validates the Set rule, removes a winning triple and associated tokens, then communicates a point or penalty to the waiting player.
Implementation details
- A valid set has each feature either equal across all three cards or different across all three.
- Point and penalty freezes temporarily suppress player input.
- Card replacement and countdown management belong to the dealer.
A playable desktop surface
The Swing interface shows cards, player tokens, countdown, scores, freeze indicators and final winners. Configuration controls player counts, key bindings and round timing.
Implementation details
- The table stores both slot-to-card and card-to-slot mappings.
- The UI interface provides a seam for mocks used by the unit tests.
STRUCTURE & JUDGMENT
How the parts fit.
Keyboard / random computer input
Per-player input producer
→ Player threadsPlayer threads
Token selection and freeze state
→ Candidate queue / Shared tableCandidate queue
Bounded IDs awaiting validation
→ Dealer threadDealer thread
Rules, timer and card lifecycle
→ Player threads / Shared tableShared table
Cards, slots, tokens and synchronization
→ Swing interfaceSwing interface
Cards, score and countdown
- Java 8
- Threads, monitors and semaphores
- Swing / AWT
- Maven
- JUnit 5
- Mockito
Separate selection from validation
Player threads collect token selections and enqueue their ID; the dealer owns rule checking, card removal and the point/penalty response.
WHY IT MATTERSThis makes the contention visible: multiple players can refer to the same cards, but validation must coordinate with card replacement. This explanation is inferred from the implementation.
Keep shared card mappings together
Table methods update slot-to-card and card-to-slot mappings alongside UI operations; a fair semaphore and synchronized blocks coordinate access.
WHY IT MATTERSThe case study can explain a concrete invariant instead of making an unverified claim that the entire game is race-free.
Make the interface replaceable in tests
Game code receives an Env containing a UserInterface abstraction. Unit tests use Mockito doubles for UI and table dependencies.
WHY IT MATTERSCore score and table behavior can be exercised without opening the desktop window.
Scope, limitations & what I would revisit
- Computer behavior is random slot input, not a Set-playing AI. Idle player/computer loops also prevent a claim of demonstrated CPU efficiency.
- Some implementation paths assume 12 slots even though the framework exposes configurable dimensions.
- The tests cover selected table, score and lifecycle methods; they do not establish correctness under adversarial thread schedules. Some dealer checks use dedicated helper methods instead of the full concurrent loop.
- This is a Swing desktop assignment, not a browser application. Bundled card assets were inventoried but are unnecessary for the proposed original vector explanation.