Yet Another Breakout Clone
I’m not a game developer, but, as most programmers do, I’ve always had some interest in the field. The first game that I wrote back in gymnasium was a two-player version of Snake. Written from scratch in Turbo Pascal 7, it featured such innovative design decisions as a completely text- and number-less HUD (I couldn’t figure out how to properly output text in graphics mode) and diagonally moving snakes (it made the keyboard controls easier to implement). Later, while studying AI in the university, I fiddled with neural networks and genetic algorithms and eventually used both to control the enemy ships in my version of Space Invaders.
Nothing much came of it. Once out of school, money became a primary concern, and I was already smart/cynical enough to know that game development took a lot of resources and that most beginner-made games failed to turn a profit. Sensibly, I didn’t even consider the option.
Then one day, as I was idly browsing through “hot” questions on StackOverflow, it occurred to me that I had never given this gamedev thing a proper shot. With a grand total of two completed games – written years apart – I could hardly even call myself a beginner. Obviously, that wouldn’t do. Recalling that most beginner-oriented articles recommend starting with something simple, I decided to go forth and implement a clone of the classic Breakout game. Which brings me to the crux of this post, i.e. presenting the game itself.
First, a couple of screenshots :
I’m sure you’re already familiar with the game mechanics of Breakout, so instead of the traditional feature list, I’ll instead highlight a few potentially interesting implementation details:
- Continuous collision detection – no matter how fast the ball is moving, it can’t “jump” through walls and blocks. Basically, instead of checking if the ball currently overlaps with another game object, I calculate the path it has taken in the previous frame and then see if that collides with anything.
- Multiple maps – each map comprises a pair of .png files. The first file is specifies the map layout, with each coloured pixel corresponding to one brick in the game. The other file is for brick metadata. Specifically, the red channel of this metadata image encodes the number of points the player gets for destroying the brick. This makes it easy to add and prototype maps – all you need is a basic image editor.
- Game state stack – states like “in-game”, “paused”, “game over” are handled using a simple stack-based “engine”. It makes for a cleaner, less ad-hoc design. See this tutorial for details.
- Written in Processing – a Java-based language specifically designed for interactive visualisation and easy prototyping. The code is largely self-contained, with only one external dependency – the Minim audio library.
Play the game (requires Java)
Download source files
Related posts :
No! Not Java! Evil!
Lol, I’m just slightly kidding. I just could never stand much of anything Java, client-side. I have fond memories of client-side Java crashing my older computers; them poor things just couldn’t take it.
Nicely done, though. Brilliant idea, using PNGs for maps.
You might be interested in a game called Hyperballoid 2. I say that because after having done variations of Breakout games myself, I was stunned by Hyperballoid. I think anyone whose worked on a Breakout game must necessarily love this one.
I’m no fan of Java myself, actually. I used it mainly because Processing is just so damn convenient for small 2D projects. The API is simple and easy to learn, and web deployment takes just a couple of clicks. That said, it’s not really a proper “game engine”, so I wouldn’t recommend it for anything bigger than Breakout.
I’ll take a look at Hyperballoid.
[…] with. The API makes sense and is reasonably intuitive. It also reminds me of Processing, which I have used several times before. The MDN canvas tutorial was very helpful for learning the […]