Against all odds
I stumbled upon Tiido Priimzgi's first graphic game called "JAW in Attacking Earth's Food Supplies" when I began archiving QuickBASIC games a few months ago. The game looks quite good from a player perspective: it features a proper menu, support for FM Synth, a save/load feature, tidy loading screens, a high scores system... it even has a nicely done instruction screen covering the back story and how to play the game.
The game itself is an arcade side-scroller in glorious EGA where you play as JAW, a big red blob with large set of pearly whites set out to travel to Earth and clear the path for an imminent invasion. Indeed, your planet is all out of food and your only chance to prevent mass starvation is to sink your teeth into juicy humans; and this is where the plot gets amazing. The "foods" of Earth are aware of JAWs and they began to throw fast food and shit into your direction like a bunch of chimpanzee at the zoo showering girl scouts in feces (what a terrible analogy).
With such a premise, the gameplay is exactly what you'd expect: move JAW around, eat hamburgers, drink sodas, and avoid the piles of Scrappy-doo-doo flying your way. There is no bonus (except for a life up every 10000 points), no sense of progression (despite an increasing speed all through each of the nine stages), and no variation (it's always the same three items flying your way at random). And that's "JAW in Attacking Earth's Food Supplies Enhanced Version" for you.
As I progressed through the game, I thought rewriting it could be a nice way for me to get back to QuickBASIC programming. In the ReadMe file, Tiido was eager to have someone rewrite his code, which was equally enticing.
Menus from hell and other scary tales
At first glance, JAW's code is a confusing mess of GOSUBs, GOTOs, obscure variable names, and random atrocities. Tiido explained on Pete's QB Site that he learned the language from a (then) 20-year old manual... which explains a few things. The level of attention, dedication and time that was put into the game (as a final product) is genuinely heart-warming considering the terrible code lurking in the shadow like a thousand centipedes under your bed pillow.
The gap between the presentation and the code is a common thread amongst many young programmers. There's definitely more motivation than skills and problems are often solved in the most (or least?) straightforward way. Menus, for instance, are coded on a case-per-case basis, and cursor movements are linked to each specific menu. Obviously, the code becomes sprawling when special things need to be displayed (toggle "ON/OFF" switches or counters for instance).
The original code also lacks functions and sub-routines, which means that every variable is virtually shared since they are defined in the main (and only) program. New variables are introduced as the listing progress; named in an esoteric manner, those temporary variables are being used in multiple places for completely different effects.
There's also no user-defined types and each food item has its very own set of variables, bearing terribly generic labels such as YYB, YYB2, XXB (for burgers) and YYD, YYD2, XXD (for drinks). The lack of data consolidation makes it impossible to handle each and every item in a loop, and thus require more and more lines of code to process. Any new item the programmer wants to add will force him to create even more variables. Obviously, there are no arrays either (except for FM Synth chip sound effects and images storage, but that's a given).
Assets would have benefited from other structures. The art is fine (bright, expressive and charming even), but stored as 8-bit per pixel bitmaps while the graphic mode only supports 4-bit per pixel. As the data needs to be converted before usage, it makes for painfully slow loading times; After listing all this, I realize those topics would definitely warrant a few notes in the future.
What's been done
The new code pretty much covers the previously mentioned flaws and also features better keyboard support (thanks to MultiKey, a piece of legendary assembly code by Milo Sedlacek and Joe Huber Jr.), proper box-based collisions, and time slices to ensure the game always runs at the same speed regardless of CPU usage (I've made some stupid decisions in that regard).
So there you go. It's far from perfect, nothing too fancy, and that's still a decent way to get back to QuickBASIC. The download includes both source code (which works in QBasic 1.1, and QuickBASIC 4.5 using the "/l" parameter) and MS-DOS binaries. If you plan to launch it in DOSBox, you'll be fine with a simple core CPU running at 3000 cycles or more.