Pixel Dash

A game built to sharpen core programming skills

Pixel Dash is a side-scrolling endless runner game built in Java — the kind of game that's simple to play but surprisingly complex to build well. The goal wasn't to make the most visually impressive game possible; it was to apply specific computer science concepts in a context that made their value immediately tangible.

Games are unusually good vehicles for learning programming fundamentals. The immediate feedback loop — make a change, run the game, see if it works — keeps iteration fast. And the requirements of a game (state management, object interactions, persistence, testing) map cleanly onto the core concepts that matter in larger software systems.

Applying CS fundamentals through game mechanics

Each feature of Pixel Dash was chosen to practice a specific programming concept:

• Object-Oriented Programming — the game is structured around a clean class hierarchy: a base GameObject class extended by Player, Obstacle, Coin, and Background. Shared behavior (rendering, update loop, bounding box) lives in the base class; specific behaviors are overridden in subclasses. This keeps the game loop simple — it just iterates over a list of GameObjects and calls update/render on each.
• Lists and Collections — obstacles and coins are managed as ArrayLists that grow and shrink dynamically during gameplay. Spawning logic adds new elements at the right scroll speed; collision detection removes them after interaction. Working with live, mutable collections in a performance-sensitive context required careful management of iteration order and concurrent modification.
• File I/O — high scores, unlocked skins, and coin totals persist between sessions using serialized file storage. The save/load system uses Java's file stream APIs to write game state to disk and recover it on next launch. This taught the fundamentals of data persistence — what to save, how to handle corrupted saves, and how to version save data when the game's structure changes.
• JUnit Testing — collision detection, scoring logic, and skin unlock conditions are covered by unit tests. Writing tests before implementing the features (a mild form of TDD) caught several edge cases early — particularly around collision box sizing and the boundary conditions for score thresholds.

The visual layer uses Java Swing for the game window and custom-drawn sprite sheets for the player character and obstacles. Animation is handled by cycling through sprite frames at a fixed frame rate, timed to the game loop.

Why building games makes you a better engineer

Pixel Dash was one of the first projects where all the concepts from coursework — OOP, data structures, file systems, testing — had to work together simultaneously. In lecture, these feel like separate topics. In a running game, they're completely entangled: your data structure affects your collision performance, which affects your game loop timing, which affects your test design.

The project also reinforced that good software design shows up as ease of extension. Adding a new obstacle type took 10 minutes because the class hierarchy was set up correctly. Adding the skin system required no changes to the game loop because player rendering was properly encapsulated. That's what good object-oriented design feels like — not in theory, but in practice.