2025

Java Development, Team Project

Object-Oriented Design & Team Collaboration

The Whack-A-Mole game was structured to practice clean Java OOP principles, separation of concerns, and team-based version control in IntelliJ IDEA.

System Architecture & Class Structure

  • WhackAMole (Main Class): Orchestrates the central game loop and coordinates interaction between all subsystem components.

  • GameTimer (Engineered by Danielle Kemp): Manages overall game time tracking and programmatically ramps up game difficulty as elapsed time increases.

  • GameBoard: Controls board grid state, mole positioning array data, and user interaction inputs.

  • ScoreTracker: Computes real-time player scores by validating successful hits and misses.

  • Mole: Encapsulates individual mole state behaviors, visibility intervals, and despawn logic.

Technical & Design Highlights

  • Dynamic Difficulty Scaling: Designed time-based thresholds that increase mole appearance speed as the round progresses.

  • Modular OOP Execution: Leveraged clean class abstraction and encapsulation so each team member could develop and test their assigned class independently before merging.

GitHub: https://github.com/daniellexkemp/WhackAMoleGame

Mission

Mission

To build a functional Java game demonstrating core Object-Oriented Programming (OOP) concepts, class encapsulation, event-driven game logic, and collaborative team development.

To build a functional Java game demonstrating core Object-Oriented Programming (OOP) concepts, class encapsulation, event-driven game logic, and collaborative team development.

Challenge

Challenge

Coordinating state changes across multiple independent Java classes—such as syncing mole spawn rates with a running game timer and tracking user inputs—requires strict class abstraction and error-free communication across the game loop. Additionally, managing different IDE console environments (IntelliJ vs. terminal output) required careful alignment and visual testing.

Coordinating state changes across multiple independent Java classes—such as syncing mole spawn rates with a running game timer and tracking user inputs—requires strict class abstraction and error-free communication across the game loop. Additionally, managing different IDE console environments (IntelliJ vs. terminal output) required careful alignment and visual testing.

Solution

Solution

Structured the game using five modular Java classes with dedicated responsibilities. Built a custom GameTimer module to handle non-blocking time progression and dynamic difficulty logic, ensuring smooth gameplay transitions from game start to the game-over summary screen.

Structured the game using five modular Java classes with dedicated responsibilities. Built a custom GameTimer module to handle non-blocking time progression and dynamic difficulty logic, ensuring smooth gameplay transitions from game start to the game-over summary screen.

Result

Result

Developed as a collaborative Programming 2 team project at Indiana University Indianapolis, this Java arcade game practices object-oriented programming principles, event handling, and custom game loops. Built by a 5-person team, the application features modular class architecture dividing board management, score tracking, mole behaviors, and time-based difficulty scaling. As part of the development team, I engineered the GameTimer class to manage game durations and dynamically adjust mole spawn rates as time progresses.

Developed as a collaborative Programming 2 team project at Indiana University Indianapolis, this Java arcade game practices object-oriented programming principles, event handling, and custom game loops. Built by a 5-person team, the application features modular class architecture dividing board management, score tracking, mole behaviors, and time-based difficulty scaling. As part of the development team, I engineered the GameTimer class to manage game durations and dynamically adjust mole spawn rates as time progresses.