Scope of Work
For my midterm project, I am designing a digital version of the classic Whack-a-Mole game, inspired by the attached references. The goal is to create an engaging and interactive game where players use their mouse to “whack” moles as they pop out of holes. The game should challenge players’ reflexes and introduce risk elements like bombs that add complexity.
The game will start with a Start Screen featuring the game title and a simple “Start” button. I also plan to add access settings, like toggling sound on or off. Once the game begins, moles will randomly pop up from a grid of holes, and the player must click or tap on them to score points. Not every hole will be safe. Occasionally, a bomb will pop up, and hitting it will result in losing points or lives. Players will have a limited time (for example, 60 seconds) to score as many points as possible before the timer runs out. As the game progresses, the difficulty will increase, with moles appearing and disappearing faster, making the game more challenging.
Each successful hit of a mole adds 10 points, while mistakenly hitting a bomb will deduct 20 points or reduce a life. The game will display a score counter and a countdown timer to keep players aware of their progress and remaining time. At the end of the game, an End Screen will appear, showing the final score and offering options to “Play Again” or “Quit.”
I want the grid to contain between 9 and 16 holes, depending on the level of complexity I decide to implement. Moles and bombs will randomly pop up in these holes at varying intervals. The randomness is crucial to establish unpredictability. To add to the challenge, the moles will pop up faster as time progresses, requiring quicker reflexes from the player.
Code Structure
For the game’s development, I plan to use an object-oriented approach. The game will be structured around a few core classes:
- Game Class: Manages the overall game loop, score tracking, and time countdown
- Mole Class: Controls the mole’s behavior (when it pops up, how long it stays, and how it reacts to player interaction)
- Bomb Class: Functions similarly to the mole but triggers penalties when a bomb is clicked
- Hole Class: Represents each position on the grid, randomly spawning moles or bombs
- UI Class: Manages elements like the start screen, score display, timer, and end screen
The core gameplay loop will rely on these functions:
- startGame(): Initializes the game and resets scores and timers
- spawnMole(): Randomly selects holes for moles to appear
- spawnBomb(): Introduces bombs with a set probability
- whackMole(): Detects player clicks and updates the score
- hitBomb(): Triggers penalties for clicking bombs
- updateTimer(): Counts down and ends the game when time runs out
- increaseDifficulty(): Speeds up mole appearances as the game progresses
Challenges and Risks
I expect that one of the most complex parts of this project would be ensuring accurate collision detection. In other words, making sure the program properly registers when a player clicks on a mole or bomb.
Timing is also a big concern. Moles need to appear and disappear at unpredictable but balanced intervals to make the pace of the game flawless and not frustrating.
To tackle these challenges, I plan to build a test script focused on collision detection, using simple shapes before applying it to the actual mole and bomb sprites. This will help me adjust the hitboxes and make sure user interactions feel responsive. I might also test randomization algorithms to ensure that mole and bomb appearances are unpredictable yet adequate.
I mentioned in class and I believe it’s on our site somewhere that you can’t just recreate an existing game. You can be inspired by a game but you need to implement at least some novel interaction and creative concept of your own. So you could use Whack a Mole as a starting point but you should think how you could add something that’s related to the creative coding we’ve been doing in class to change the game beyond being a simple recreation.