Chances are you haven't heard about Larry the Dinosaur (who?). Larry the Dinosaur ain't as popular a character as Mario or Sonic, by no means. He ain't even copyrighted or trademarked, and there are even other "Larry the Dinosaur"s out there on the internet which serve to confuse to meaning of his existence. Anyway, Larry lives in the Cretaceous period (about 65 million years ago) -- the last age of the dinosaurs. He isn't quite like the dinosaurs you see in books. This is because, in his universe, dinosaurs have evolved from the monstrous behemoths in Jurassic Park to intelligent, bi-pedaling beings capable of ordering pizza and organizing LAN parties. It's the information age...like now...but with dinosaurs!
Larry is green, mean, and he favors a pump-action shotgun to face off against his enemies. The enemies are, but of course, aliens! Space aliens that is. They've traveled light-years across space to harvest Earth for its precious resources. And the dinosaurs won't have it! So in a typical heroes-journey fashion, Larry becomes the hero through major ass-kicking and saves Earth from total annihilation. And it all started with drawing lines (what?).
You see, it was the year 2000. I was programming in an ancient language then known as Microsoft Qbasic. This program let you, in a variety of ways, destroy brain cells with each line of code. If you were lucky, you could push out an executable and upload it to the internet before you lapsed into a coma. The net result was thousands of permutations of whiny teenage-emo sociopathic brain-dead sludge, and it was all disguised as downloadable games. Larry the Dinosaur was such one permutation.
 |
| The rock monster makes its first appearance. |
Anyway, didn't I mention something about lines? Back when I had some brain cells, I was painting a scene in Qbasic using line, circle, and paint commands. You see, you can enter a line of code like so:
LINE (10, 10)-(100,10), 2
That line of code would draw a graphical line from 10 pixels across and down to 100 pixels across and 10 down (a horizontal line, basically). What is this, you say, Battleship? (I hear the game is now the movie; god help us).
The "2" at the end specifies the color: 1 is blue, 2 is green, 3 is cyan, 4 is red, and so on. The Circle and Paint commands had similar syntax.
So, using these primitive commands, the scene I was painting had a blue sky and purple mountains standing atop green grass drawn in a zig-zag pattern.
This scene needed a playable character. So at the cost of billions of brain cells I coded a character out of horizontal lines. He was 16 pixels tall and he looked like a green lizard. I hooked the character to the keyboard so that he moved left when you pressed the left arrow key and so that he moved right when you pressed the other...uh...stupid arrow key (sorry, some synapses failed to fire there for a second). There was just that one graphic of the lizard dude—there was no animation—so it looked like he slid across the ground on wheels when he moved.
 |
| Spiked! It's way too easy to fall onto these things. |
My cousin stopped in that day and saw what I was working on. He was a programmer too and, in fact, was the one introduced me to Qbasic...and I've been in recovery ever since. Anyway, he was impressed with what he saw. This encouraged me to continue developing this program into a game.
It never happened.
Instead, what remained after a couple days was a little demo with a couple scenes you could cross and a boss at the end. Somewhere I coded the functionality to shoot and I think I gave him a shotgun from the very first graphic. The boss was a large machine that fired large metal balls that you had to jump over whilst firing back to destroy the machine. It was pretty cool. I wish I still had the program. Sigh. I lost it a long time ago.
The finished game that you can download right now (but please God, don't!) was a new game altogether. I started over from scratch, only the ideas (character, setting, boss, etc.) were ported over (and expanded upon). For starters, I used sprites instead of line-statements for playable and non-playable characters. The scenes were still rendered with primitive line, circle, and paint statements—which is a slow way to render a scene—but since it was a screen-by-screen scrolling game (as opposed to pixel-by-pixel), waiting a second for the scene to render wasn't an issue and it even looked cool to see it compose.
I added bad guys, additional bosses, and even in-game plot sequences. I even broke the game into three separate ambient episodes with three levels each. Sounds cool, right?
 |
| Screen shot from Episode 2. Sombreros, baby! |
But the game had its problems; and there were many! The game was poorly executed. Controlling the player felt awkward. Jumping was difficult to get a hang of. The keyboard handler was shotty; you couldn't hold down two keys at once, so you couldn't run and jump at the same time; instead, much like slamming on the breaks of a car, jumping brought Larry to a complete stop; shooting did this too. You were able to control Larry while he was in the air, but the transition from running to jumping was horrible.
Another issue is that it wasn't tested, so it sucked. Ok, my brother did test it a couple times, but I was arrogant and didn't really listen to his feedback. The game was so impossible that only I could beat it. At the time I thought it had a reasonable difficulty, but there were so many instances that relied on exact timing to avoid death. It had very unforgivable gameplay.
The game was confusing to understand as well. The idea was that you had spare amounts of ammo and you had to jump over enemies to conserve your ammo for obstacles later on that did require use of the shotgun. Many people complained that there was never enough ammo. Again, I didn't listen because "there was clearly enough ammo." Maybe there was, but I could have implemented ways to hint or afford the player to understand this relationship between jumping and ammo. At the very least I could have opened some dialogue to understand the complaints; maybe there was a bug I wasn't aware of?
On top of this the game needed to be configured to run on other computers. What does this mean? It means that it ran perfectly fine on my 16mhz 386, but it ran way too fast on a 486 and bolted on Pentium computers. I added a speed control to the title screen that allowed you to adjust the speed: it showed an animation of a running Larry and you pressed '-' or '+' to slow the animation down or to speed it up. When Larry is animating at a reasonable speed the game was calibrated and you could play it. The glaring problem with this approach, however, is that nobody else knew what the appropriate speed was. Was Larry supposed to be running briskly or casually? Even trying to figure out how to use the speed control was difficult: Larry could be running so fast that he doesn't appear to be running at all, making it even more confusing.
 |
| The second screen of level 2: ideally Larry's running speed is slightly faster than the rock monsters', so jumping over them should be no problem. But if the speed variables weren't configured just right, this simple task would be impossible: you could never outrun or clear the monsters when you jumped over them; so if you were out of ammo you had no other way to progress...you were screwed. |
And that is the story of the first game. It received fairly negative reviews, and one person dedicated a whole web page to the game and how much it sucked. Really, I'm not kidding! It's no longer on the web; I wish it was -- it was a good laugh. Someone actually spent some time putting that page together. It was a nice tribute.
