Outbreak

There aren't many Breakout/Arkanoid clones in QuickBASIC, likely because writing collisions is a difficult task. While the very flashy Arqanoid (by Richard Eric M. Lope) and well-coded Arkanoid (by Aleksander Trojanowski) are efforts worth mentioning, neither of them feels as good as Outbreak by Dillon, Michael and Isaac. How come?

First off, the paddle controls smoothly with the mouse (keyboard support is unavailable,) the framerate is stable, and more important than all you can get a feel for the ball and can actually control it well enough that breaking bricks doesn't feel like a shore. While it doesn't gain velocity over time, the ball will bounce off everything, including falling items and bonuses (an odd quirk that takes a while to get used to.)

Second, Outbreak features a whopping total of five types of bricks (some will endure multiple hits while others will explode and destroy surrounding structures, some will appear out of nowhere, some will bounce the ball right back at you...) and multiple pickup items, which can be beneficial (Cannonball makes your ball unstoppable, Glue lets it stick to the paddle whenever it lands, Shoot adds two guns to the paddle so you can clear blocks on your own,...) or a real pain in the ass (Switch reverses paddle movements, Slippery makes it harder to control, AI takes control of the paddle and releases it when it is seemingly the least opportune for you.) All pick-ups usually last for thirty seconds (except for the very devastating Fireball,) and a nifty timer displayed on the lower-right corner of the screen will let you know just how long until the effect wears out.

Although most stages are well-designed, some obviously exist only to piss you off. Unfortunately, you'll have to arm yourself with patience as all fifty stages must be completed in one sitting (count about two and a half hour.) Indeed there's no save feature, no pass code, and no unlock system. To make the matter worse, on rare occasions, the ball may get stuck in an endless loop, which is annoying since the restart option in the main menu throws you back to level 1! After completing the game, you'll be rewarded with a random cheat code that can be inputted in the game menu; using these cheats bars you from registering your score and obtaining a new cheat upon game completion.

The overall presentation is a bit of a mixed bag; graphics are indiscriminately represented through pixel art, drawing functions and raw print commands. While it's not too distracting, it's nonetheless weird to see digits being displayed in two different fonts for no apparent reason. In short, for every little cool detail (like the tiny lively sparks when the ball hits the paddle, or the nice-looking opening animation,) you get a dull-looking brick or a grey pipe-like screen border. The game supports different sound options (digitalized in 8kz or 11hz, PC Speakers, or mute.)

I'd like to talk a bit about the code, so if that's not your cup of tea, feel free to skip this paragraph. Given the quality of the game, the coding style is... surprising. Collisions are pixel-based and every step in the process requires POINTing pixels on the screen, and using the color attribute to determine how physics should behave, what items should be dropped, or what blocks are hit; for instance, the actual graphic for the paddle is surrounded with black pixels of different indices and depending on the pixel index hit, the ball will bounce in a different direction. It's super risky but it works. Routines and function are few, which implies several things: for starter, the code is riddled with GOSUB and GOTO statements making it hard to read (some lines are labeled, others are numbered.) Then, many snippets of code are copied over and over again, needlessly bloating the program. Finally, most of the game code is located in the main program (menus, demo and gameplay are all located in the same section...) it's an absolute mess. There's a whole ocean of conditional branching, which is often used instead of math (for instance, the position and number of hearts on the life counter is branched, not computed.) Many conditionals are relying on STRINGs instead of INTEGERs (CONSTs could help readability, reduce the compiled application's size and make the program run faster.) There's also some misunderstanding of how RND works (there's a nested code in particular that got a chuckle out of me.) The overall organization of data reeks of first program (resource files are text mode instead of binaries,) but the level of polish and work that went into the game totally makes up for it.

The source code being too large to be compiled, the game has to be run in QBasic. This is not only tricky for the least skilled of us (the CHDIR instruction at line 2449 must be commented out or edited so the game can find all its files,) but it also results in a much slower experience (the game requires around 40,000 CPU Cycles in DOSBox in QuickBASIC 4.5 and over 100,000 CPU Cycles under QBasic 1.1. - the readme recommends at least a Pentium 75 MHz) Since the program relies on CALL ABSOLUTE for mouse support, don't forget to also add the /L option to the command line when using QuickBASIC 4.5.