This was a high school group project completed in 2006, developed as part of an introductory computer science course. While the formal requirements were limited to basic UI elements such as buttons, sliders, and labels, the goal we set for ourselves went well beyond those constraints. Rather than producing a simple form-based application, we chose to build a small but complete game.

The project was developed collaboratively. My partner focused on rendering and drawing simple geometric shapes, while I handled the game logic, collision behavior, state management, and overall structure of the application. Within the limits of the language and environment, the emphasis was on producing a functional, playable system rather than maximizing technical sophistication.

Game Description

The game consists of a ball moving diagonally within a square playfield containing blocks and four target objects located in the corners. When the ball collides with surfaces, it reflects or inverts direction depending on the type of collision. Some blocks can move when hit, while others become fixed once they can no longer shift position.

The player can influence the ball’s path using a single block controlled by the mouse cursor. This provides a simple way to intervene when the ball risks becoming trapped. When the ball reaches each of the four corner targets, they are cleared, and the level advances. Higher levels introduce additional blocks, increasing obstruction without changing the underlying rules.

Controls and Parameters

The game includes basic UI controls typical of the assignment. Sliders adjust speed, acceleration, and starting level, while buttons allow the game to be paused, reset, or reconfigured at runtime. Scoring decreases over time, encouraging faster completion rather than precision.

Objectives

The objectives were straightforward: build a simple game in Visual Basic, satisfy the required UI elements, and demonstrate basic control flow and collision handling.

Challenges

Implementing correct bounce behavior took some iteration, as this was my first exposure to collision logic. Integrating gameplay code with rendering written by a partner also required working with unfamiliar abstractions.

Results

The final program met all requirements and produced a playable, stable game. While mechanically simple, it was complete and responsive, and it remains runnable on modern versions of Windows many years later without modification.

Shirly was fun to play, we didn’t take the entire time available to finish, and it actually still runs 18 years later in a totally new operating system (Windows 11). You wouldn’t expect something developed in Windows XP or NT to still function on Windows 11, but it does [for me] 18 years later. Give it a try if you like, the file should be 72.0KB and have a SHA256 of 4E1814C48A499AA550A9BE919C44C09DF94406CAD29107D4388DD431F992013E. I can imagine you shouting “surely, you must be kidding” don’t call me Shirly!