Shirly
An early VB6 grid game whose collision rules use previous and current positions, neighboring cells, and a changing board. Game logic by me; renderer by Ben.
- Version
- Original project
- Status
- Historical project
- Built with
- Visual Basic 6
- My work
- Game logic; Ben handled the renderer

Project overview
Shirly is an early Visual Basic 6 game built around a moving ball and a grid of obstacles, targets, and points. I wrote the game logic from scratch, while Ben handled the renderer. The part I remember most clearly is working out the collisions from the ball’s previous position, current position, and surrounding cells.
Movement from two positions
The movement timer takes the difference between the ball’s current and previous coordinates to determine its direction. Adding that difference gives the proposed next cell. Before committing the move, the game looks at the cells ahead along each axis and at the diagonal destination.
A side collision reverses the horizontal component, a top or bottom collision reverses the vertical component, and a blocked corner can reverse both. Some blocks also move or change when hit, so the collision branches update the board as well as the ball’s next position.
That was the awkward part: each rule was small, but their combinations required a lot of hand-written cases. A moving block, two adjacent obstacles, and a blocked diagonal could require different responses. The implementation keeps those decisions in the movement routine, where the neighboring cells and the direction are available together.
A game around the movement
Level generation places obstacles and points inside a bordered board. The mouse controls an obstacle cell, changing the ball’s available route. Separate timers handle movement, scoring, and level progression, while the pause control stops the gameplay timers together.
A speed slider changes the movement interval. My recollection is that the game ran quickly enough that we added the slider to control it. That is a memory of using the application, rather than a measured frame rate or benchmark.
The form also contains save/load routines for the board and game state. They write a versioned binary format and apply XOR transformations to the values. That is a historical serialization and obfuscation scheme, with no security guarantee implied by the file’s original naming.
What survives
The available source is a single VB6 form. It preserves the movement, board interaction, levels, score, controls, and renderer interface, but the renderer implementation and full project setup are missing. Ben may have reused code for that renderer; my from-scratch contribution was the game logic.
The original application has not been rebuilt or run as part of the current portfolio work. This page presents the surviving logic and the collision problem I remember working through. The related physics article provides further context for that approach.


