I wrote an article for Basic Gaming. It's about making code organized and reusable. Exciting, I know!
Checkout the latest issue, or go straight to my article here.
Toadman 3 is on Facebook!
Have a Facebook account? Good! Then "like" the Toadman 3 page to get awesome updates in your news feed:
http://www.facebook.com/toadman3game
http://www.facebook.com/toadman3game
Toadman 3 -- still breathing
 |
| A recent screenshot. |
A couple months ago, I continued work on Toadman 3. I've made a lot of progress since then. I'm hoping to have this finished within the next six months.
I'm developing the game on Linux now. It'll still be playable on Windows, but Linux is a much better development environment. I'm also using Git to version my game. It's an excellent tool for version control.
The game has 3 to 4 levels at the moment (some are incomplete). I've added many updates: bug fixes, power-ups, joystick support, and so on. A lot of the work has been re-factoring the code I wrote in 2009. I've applied many OOP concepts I've learned throughout the years. The result is code that is cleaner, powerful, flexible, and simple to build upon. The game has been fun to work on.
I'm trying to wrap this game up for a version 1.0 beta release in the next couple months, after which I'll continue working on it for another 3-6 months until I am happy with everything. This is different than my previous games where I release it and move on to something else. Rather, it'll be an ongoing beta for a period of time where I'll continue to apply patches and updates as people test and provide feedback. I'm hoping to have something masterfully polished -- and masterfully a by the end.
Larry the Dinosaur: Prototype to Crappy Game
Today I will discuss how I created the character of Larry the Dinosaur, the first game featuring him, and some other fun stuff.
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.
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.
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?
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.
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.
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.
Finish what you start
Finish what you start! And I know what you are thinking: easier said than done. Right?
Let me elaborate.
I don't mean to throw away hours of your life on something you've grown to hate. That's for EA employees. At least they get paid. You, on the other hand, your time is precious, even more so if you have a full-time job, school, a family to support, or any combination of these. You could die tomorrow! So it's in your best interest to put your free time towards something you love.
This is why it's very important to finish what you start. Because, in the end, it matters whether your time went towards a proud achievement or a half-baked idea, a cool game that is enjoyed by millions over the internet or another project put on hold indefinitely.
But is it really that simple, to finish what you start? Is it simply a matter of dedicating more time and willpower to a project? I don't think so. Believe me. I've tried. Simply "trying harder" doesn't work.
So what does?
You need to guarantee that you will finish your project before you start.
Is this possible? Theoretically speaking, no. But it should be a goal, even if it's an impossible one.
You must assess how much time you can dedicate to your project every week. You must have a clear vision of your project, from start to finish, the more detailed the better. And you must estimate how many hours you project will take.
Will it take six months, a year, maybe more? Are you disciplined enough to work on this project consistently for an entire year, or will you lose interest after a couple months? Knowing yourself is essential.
I will lose interest after three months. That's my limit. So if I estimate that my video game will take six months to finish, then I have a problem. But I don't have to drop the project. I just need to alter my plan and re-evaluate my time. And there are some options for this.
If you don't have the time then don't do it.
The simplest is to cut back: drop unessential levels and features, forget multi-player, or reduce the complexity of some game feature like artificial intelligence. These are nice features, but your game can do without them. Simply put: if you don't have the time then don't do it. Stop! I know you may not like that statement, but don't send me hate mail just yet; there is a silver lining to this method which I will explain.
This doesn't mean that your game has to suffer so much that it becomes a minimalist piece of junk. Often you'll be cutting out features that don't affect the core theme or tone of your game. You can still have awesome gameplay, story, or graphics; but decide which is most important, figure out what you can do with the time you have, and then do it.
The good news is that, if on a later date you want to expand upon your game and include that awesome feature, there's nothing stopping you! In fact, you have a complete game to expand upon. So if that feature is too hard or just doesn't work out, then no problem! Your game is still good to go. Not to mention it is also much more fun to tweak a fully functioning game -- an additional motivational factor to help you add that extra zap and polish wherever your game needs it.
The major benefit to planning this way is that it forces you to develop what you need first, then what you want. And what you need first and foremost is a fully-functioning game. No one cares about your award-winning pizza-delivery AI system if they can't play your finished game to see it.
Dream big! But live in reality.
It's all too easy to dream big, way big! This is good. It fuels creativity and gives you tons of ideas to play with. But you need to understand just how many man-hours are required for your "big dream." Usually the games I want to make would, in reality, take a good couple of years with a team of 50. So unless I dedicate the rest of my life to making that one game, it just won't come to fruition. This is why so many newcomers to programming, fuelled by the dream to make the next Quake or Half-Life, never get off the ground. The amount of time and dedication to complete something like that is staggering. It took thousands of man-hours with large teams of very smart people to make those games; so why would you -- one very smart person indeed -- be able to do the same in roughly the same amount of time?
I'm not saying you can't have that "big dream" of that awesome game of yours. Just be realistic about it. Valve, after all, shipped Half-Life within a couple years; but they were smart about it and put together a team of very smart programmers, artists, level-designers, you-name-it! It wasn't a one-person job.
So I guess what I am saying is don't plan a project that'll take a large group of people working full-time to accomplish. You are, after all, only one person. Unless you plan to take a path similar to Valve, keep it simple.
The most bang for your buck.
Starting a project without a plan is tempting, but in the end, even if you do finish it, many hours are lost from feature creep, changes in design, changes in code, and who knows what else. Time is too precious. Each of the above points are tools to help you make a plan to guarantee that you'll finish your project with what little time you have. They're designed to give you the most out of your hours -- the most bang for you buck.
Be realistic and honest with yourself, your time, and your expectations. This is one reason why designing and planning your game beforehand, in as much detail as possible, allows for a smoother development process: you better understand what to expect, how much time it'll take, and which features to prioritize.
Likewise, when you make a plan for your game, you may find that you're just not interested enough to spend three or more months on it. That's ok! Better to find out then rather than three months later. Keep working on other ideas until you find something your happy with that you know will be worth you time.
Again, there are no guarantees. It's difficult to accurately estimate how much time a project like a video game will take. And unexpected issues are always a possibility. Many people underestimate simply because there are so many details to account for, and accounting for all of them can be challenging. It's a skill that takes practice. And it is much, much better to have a plan than to shoot from the hip. Trust me. You'll find out sooner or later.
So plan accordingly, and spend the time saved on other wholesome activities like spending time with friends and family, going to the movies, or even exercise (you know that thing where you move parts of your body and it supposedly makes you look and feel better).
Let me elaborate.
I don't mean to throw away hours of your life on something you've grown to hate. That's for EA employees. At least they get paid. You, on the other hand, your time is precious, even more so if you have a full-time job, school, a family to support, or any combination of these. You could die tomorrow! So it's in your best interest to put your free time towards something you love.
This is why it's very important to finish what you start. Because, in the end, it matters whether your time went towards a proud achievement or a half-baked idea, a cool game that is enjoyed by millions over the internet or another project put on hold indefinitely.
But is it really that simple, to finish what you start? Is it simply a matter of dedicating more time and willpower to a project? I don't think so. Believe me. I've tried. Simply "trying harder" doesn't work.
So what does?
You need to guarantee that you will finish your project before you start.
Is this possible? Theoretically speaking, no. But it should be a goal, even if it's an impossible one.
You must assess how much time you can dedicate to your project every week. You must have a clear vision of your project, from start to finish, the more detailed the better. And you must estimate how many hours you project will take.
Will it take six months, a year, maybe more? Are you disciplined enough to work on this project consistently for an entire year, or will you lose interest after a couple months? Knowing yourself is essential.
I will lose interest after three months. That's my limit. So if I estimate that my video game will take six months to finish, then I have a problem. But I don't have to drop the project. I just need to alter my plan and re-evaluate my time. And there are some options for this.
If you don't have the time then don't do it.
The simplest is to cut back: drop unessential levels and features, forget multi-player, or reduce the complexity of some game feature like artificial intelligence. These are nice features, but your game can do without them. Simply put: if you don't have the time then don't do it. Stop! I know you may not like that statement, but don't send me hate mail just yet; there is a silver lining to this method which I will explain.
This doesn't mean that your game has to suffer so much that it becomes a minimalist piece of junk. Often you'll be cutting out features that don't affect the core theme or tone of your game. You can still have awesome gameplay, story, or graphics; but decide which is most important, figure out what you can do with the time you have, and then do it.
The good news is that, if on a later date you want to expand upon your game and include that awesome feature, there's nothing stopping you! In fact, you have a complete game to expand upon. So if that feature is too hard or just doesn't work out, then no problem! Your game is still good to go. Not to mention it is also much more fun to tweak a fully functioning game -- an additional motivational factor to help you add that extra zap and polish wherever your game needs it.
The major benefit to planning this way is that it forces you to develop what you need first, then what you want. And what you need first and foremost is a fully-functioning game. No one cares about your award-winning pizza-delivery AI system if they can't play your finished game to see it.
Dream big! But live in reality.
It's all too easy to dream big, way big! This is good. It fuels creativity and gives you tons of ideas to play with. But you need to understand just how many man-hours are required for your "big dream." Usually the games I want to make would, in reality, take a good couple of years with a team of 50. So unless I dedicate the rest of my life to making that one game, it just won't come to fruition. This is why so many newcomers to programming, fuelled by the dream to make the next Quake or Half-Life, never get off the ground. The amount of time and dedication to complete something like that is staggering. It took thousands of man-hours with large teams of very smart people to make those games; so why would you -- one very smart person indeed -- be able to do the same in roughly the same amount of time?
I'm not saying you can't have that "big dream" of that awesome game of yours. Just be realistic about it. Valve, after all, shipped Half-Life within a couple years; but they were smart about it and put together a team of very smart programmers, artists, level-designers, you-name-it! It wasn't a one-person job.
So I guess what I am saying is don't plan a project that'll take a large group of people working full-time to accomplish. You are, after all, only one person. Unless you plan to take a path similar to Valve, keep it simple.
The most bang for your buck.
Starting a project without a plan is tempting, but in the end, even if you do finish it, many hours are lost from feature creep, changes in design, changes in code, and who knows what else. Time is too precious. Each of the above points are tools to help you make a plan to guarantee that you'll finish your project with what little time you have. They're designed to give you the most out of your hours -- the most bang for you buck.
Be realistic and honest with yourself, your time, and your expectations. This is one reason why designing and planning your game beforehand, in as much detail as possible, allows for a smoother development process: you better understand what to expect, how much time it'll take, and which features to prioritize.
Likewise, when you make a plan for your game, you may find that you're just not interested enough to spend three or more months on it. That's ok! Better to find out then rather than three months later. Keep working on other ideas until you find something your happy with that you know will be worth you time.
Again, there are no guarantees. It's difficult to accurately estimate how much time a project like a video game will take. And unexpected issues are always a possibility. Many people underestimate simply because there are so many details to account for, and accounting for all of them can be challenging. It's a skill that takes practice. And it is much, much better to have a plan than to shoot from the hip. Trust me. You'll find out sooner or later.
So plan accordingly, and spend the time saved on other wholesome activities like spending time with friends and family, going to the movies, or even exercise (you know that thing where you move parts of your body and it supposedly makes you look and feel better).
Larry the Dinosaur 2: Behind the Scenes
After my last post about the happenings after Larry the Dinosaur 2 was released, I realized that I didn't say much about the development of the game. I will now.
The first attempt at Larry the Dinosaur 2 never made it past a playable demo. But it was distributed online. It was awesome.
Everyone liked it, so what happened? I don't remember. I can only guess that it suffered the fate of many playable demos that were never completed as full games, that fate being this: the demo is only the beginning, to complete it is a full-time job. It's easy to slap together a rather-promising playable demo over a night or two. And it's easy to fool yourself into believing that you can expand upon it just as easily and, with a just little more effort, finish a work of pure awesomeness.
But the truth is--if it only took you a day to make a playable demo--it's probably running on top of some code you ordered through the drive-thru. This is not always the case, but it was for me.
Maybe it seemed like to much work to complete it. Maybe the code was such a mess that I couldn't expand upon it without a zillion bugs coming out of the woodwork. But somehow, the game vanished, people were let down, and so was I.
Then the summer came. Sunny skies and warm weather. Maybe it was too warm and it cooked my brain, but I thought that making a prequel to Larry the Dinosaur would be awesome! I'd call it, Larry the Dinosaur: Zero (original, right?). This would have pixel-by-pixel scrolling whereas the last attempt had only static screen-by-screen progression like Larry the Dinosaur 1.
I charged at it as furiously as I had the last. And it was awesome. I had a playable first level. It was plush and green. It had animating waterfalls and pixel-by-pixel scrolling. It even had a boss at the end of the level you had to defeat; it looked like a giant mutated mosquito and it flew across the screen as it dropped slimy spit balls that Larry had to dodge.
Well, you might ask, what happened to that one. It got erased!!! Yes. I didn't back it up regularly. I was heart-broken...and also pissed at Linux for erasing my hard drive when I just meant to install it on another partition.
Whatever. It was my fault; it's never a wise idea to keep only one copy of your code. I did think about backing it up, just in case, but I ignored my brain and let stupid take over.
So that brought me to my third attempt at another follow-up to Larry the Dinosaur 1. I had an idea and spent all night developing a...wait for it...playable demo; didn't I mention something about those earlier? Anyway, it had pixel-by-pixel scrolling and I think you could run around and shoot at things.
So how did this one make it to the finish? It didn't. At the time, "complete" meant to me a game that takes hours for the player to complete, not just 15 minutes, and the game seemed stretched thin even at that length. So I bought some wrapping paper and a bow and released it online under the guise that it was "complete." Though, there was no "real" plan, so technically it was complete at any time I wanted it to be.
Ok, so if I didn't finish it, how did I make it past a playable demo? Well, for starters, I had some practice: it's much easier to do something over once you've done it before. I already made some programs that had playable characters running around shooting at things, those were known as the last two attempts, so getting up to speed was easy. And I also wrote better code. The code was still bad, but a bit better than what I had done before.
I didn't know what I was doing (not that I ever do). The game could have failed just as easily as the other two. I just started coding-a-blazing.
It started the same as the other too. So why did I this one make it to the finish line? Did I just get lucky? Maybe. Or maybe I was just smart enough this time to not start over and to backup the game.
Actually, now that I think about it, those are the two major mistakes I made that contributed to the games not being completed.
It makes sense, doesn't it? I assume I cancelled the first demo because I lost interest or because I was tempted to start over and "make something better." I put that in quotes because I think, if I finished the first demo, it would have been just as good in its own way. It's all to easy to fool yourself into thinking that you should just scrap everything and start over because you dream bigger, or possibly because you received some negative feedback from someone. Don't do it! Finish it, even if you cut corners, and you'll be happy that you did.
The second time I failed to properly backup my code. I'm sure I had some copies on my computer. But I lost everything on my computer! So always backup your code to removable storage or to the internet. Better yet, learn source control!
So I take that back. I don't think it's a bad thing to start from a playable demo. After all, that could be the spark that ignites your drive to finish the game. Don't worry too much if your code is messy, you can always clean up afterwards.
The first attempt at Larry the Dinosaur 2 never made it past a playable demo. But it was distributed online. It was awesome.
Everyone liked it, so what happened? I don't remember. I can only guess that it suffered the fate of many playable demos that were never completed as full games, that fate being this: the demo is only the beginning, to complete it is a full-time job. It's easy to slap together a rather-promising playable demo over a night or two. And it's easy to fool yourself into believing that you can expand upon it just as easily and, with a just little more effort, finish a work of pure awesomeness.
But the truth is--if it only took you a day to make a playable demo--it's probably running on top of some code you ordered through the drive-thru. This is not always the case, but it was for me.
Maybe it seemed like to much work to complete it. Maybe the code was such a mess that I couldn't expand upon it without a zillion bugs coming out of the woodwork. But somehow, the game vanished, people were let down, and so was I.
Then the summer came. Sunny skies and warm weather. Maybe it was too warm and it cooked my brain, but I thought that making a prequel to Larry the Dinosaur would be awesome! I'd call it, Larry the Dinosaur: Zero (original, right?). This would have pixel-by-pixel scrolling whereas the last attempt had only static screen-by-screen progression like Larry the Dinosaur 1.
I charged at it as furiously as I had the last. And it was awesome. I had a playable first level. It was plush and green. It had animating waterfalls and pixel-by-pixel scrolling. It even had a boss at the end of the level you had to defeat; it looked like a giant mutated mosquito and it flew across the screen as it dropped slimy spit balls that Larry had to dodge.
Well, you might ask, what happened to that one. It got erased!!! Yes. I didn't back it up regularly. I was heart-broken...and also pissed at Linux for erasing my hard drive when I just meant to install it on another partition.
Whatever. It was my fault; it's never a wise idea to keep only one copy of your code. I did think about backing it up, just in case, but I ignored my brain and let stupid take over.
So that brought me to my third attempt at another follow-up to Larry the Dinosaur 1. I had an idea and spent all night developing a...wait for it...playable demo; didn't I mention something about those earlier? Anyway, it had pixel-by-pixel scrolling and I think you could run around and shoot at things.
So how did this one make it to the finish? It didn't. At the time, "complete" meant to me a game that takes hours for the player to complete, not just 15 minutes, and the game seemed stretched thin even at that length. So I bought some wrapping paper and a bow and released it online under the guise that it was "complete." Though, there was no "real" plan, so technically it was complete at any time I wanted it to be.
Ok, so if I didn't finish it, how did I make it past a playable demo? Well, for starters, I had some practice: it's much easier to do something over once you've done it before. I already made some programs that had playable characters running around shooting at things, those were known as the last two attempts, so getting up to speed was easy. And I also wrote better code. The code was still bad, but a bit better than what I had done before.
I didn't know what I was doing (not that I ever do). The game could have failed just as easily as the other two. I just started coding-a-blazing.
It started the same as the other too. So why did I this one make it to the finish line? Did I just get lucky? Maybe. Or maybe I was just smart enough this time to not start over and to backup the game.
Actually, now that I think about it, those are the two major mistakes I made that contributed to the games not being completed.
It makes sense, doesn't it? I assume I cancelled the first demo because I lost interest or because I was tempted to start over and "make something better." I put that in quotes because I think, if I finished the first demo, it would have been just as good in its own way. It's all to easy to fool yourself into thinking that you should just scrap everything and start over because you dream bigger, or possibly because you received some negative feedback from someone. Don't do it! Finish it, even if you cut corners, and you'll be happy that you did.
The second time I failed to properly backup my code. I'm sure I had some copies on my computer. But I lost everything on my computer! So always backup your code to removable storage or to the internet. Better yet, learn source control!
So I take that back. I don't think it's a bad thing to start from a playable demo. After all, that could be the spark that ignites your drive to finish the game. Don't worry too much if your code is messy, you can always clean up afterwards.
Larry the Dinosaur 2: Nine Years Later
It was Halloween evening, October 31st, 2002. A game I had been working on since the summer was almost finished. I wanted to released on this day, for some odd reason. Honestly, it still needed a ton of work; it had many bugs, and it had some poor design issues that needed to be addressed. But at the time, my programming skills weren't too great and I had enough of the project. I played through the game several times that night, fixing up what I could, and then I submitted it to various sites. The game was Larry the Dinosaur 2.
It received fairly good feedback from the then Qbasic community. Amongst other 2d platform games developed in Qbasic, Larry the Dinosaur 2 held up well. It mixed action and puzzle elements and had a progressive story line that rewarded you with cut-scenes at certain points throughout the game. You could pick up and drop items; mixed items with other items (shotgun shells mix with the shotgun to increase your ammo supply, for example). You could fight enemies with your fist, pistol, shotgun, machine-gun, or desert eagle. There were non-playable characters that served the narrative. There was a villain, a friend, and a could-have-been-worse script.
Outside the world of Qbasic the game received positive feedback as well. It was posted on the front page on freedownloadscenter.com (http://www.freedownloadscenter.com/Reviews/r912.html). Somehow my game fell into the hands of someone there and it hit all the right notes with him (or her), and so he gave it a pleasant review. It was really a surprise to find my game on the front page of a non-programming related website.
In addition to the online review, I was contacted by a representative of a German game magazine, who wanted to publish a blurb about in their next issue. I don't remember what it was named, but I couldn't find the magazine online. I had to sign a disclosure agreement, so that makes it true right? Well, maybe. I don't think anyone would waste their time if it wasn't real, so probably. If I ever find it I'll have to post about it.
I also had another representative call me, but this guy was trying to promote an anti-spyware program and wanted me to place an ad. Here's how it worked: when anyone clicked on the link to download the game, it would first direct them to an offer page, giving them the chance to buy the anti-spyware program, or to continue and download the game. A bit annoying if you are just trying to download the game. However, if anyone bought the anti-spyware program I'd get like half the profit. The ad page tracked stats and I was able to see just how many downloads my game was getting. Heh, it was actually what made me decide to stop the ad placement and just go back to a direct download. I got about (or over) 3,000 hits. Holy shit! But...the stats showed how many people made it to the ad page versus how many people continued on to download the game versus how many people bought the anti-spyware program. About a third of the people who made it to the ad page gave up and didn't download the game. So yeah, 2,000 downloads is still a lot. But man, I lost a thousand downloads! The good news is that one--yes, just one--individual out there (out of the 3,000) bought the anti-spyware program. I received a check in the mail for eleven and something dollars; I should have framed it, heh. My brother joked at how that meant that it averaged to about fractions-of-a-cent per hour of the time I spent making the game. Whatever, that was an exciting time. At least I made something! And after seeing those stats, it just wasn't worth it, I wanted more people to download my game! So I removed the ad-placement and just made it a direct download again.
Unfortunately, the game download was hosted on a server of a shotty ISP. Back then I was using dial-up. The terms of the contract stated that if I went over 90 hours (or some number) per month, my account would be deactivated and I'd have to call in to reactivate it; this means downtime--no one can download the game when my account is deactivated. The downtime wasn't the bad part. The bad part was that they wouldn't just reactivate my account; they have to create an new one with a new user name, each time! Part of the URL to download the game had my user account name as part of it. The original download link, when my user name was joeking1, was http://users.sisna.com/joeking1/deltacode/downloads/dos/ld2v10.zip. So the first time we went over the hours and my account was deactivated, the download link became invalid. I could reactivate my account but those bastards wouldn't give me my old user name back, so the new download link was http://users.sisna.com/joeking2/deltacode/downloads/dos/ld2v10.zip. Only the user name changed, joeking1 to joeking2, but that's all it took to kill the traffic my game was getting. Then the user name changes went on and on, to joeking3 and so on each time we went over the limit. I couldn't control my brother's activity--yes, I blame him!
If only the ISP was the issue; but no, no matter how many times I contacted freedownloadscenter.com to update the link to the new one, they wouldn't do it. Instead they just posted the text from my email on a new page of their site. Who does that? (it's still up: http://www.freedownloadscenter.com/Games/3D_Action_Games/Larry_The_Dinosaur_2.html)
So the awesome downloading spree was over. No one could download my game from there anymore. The excitement was short-lived. Another drawback about this whole experience is the compatibility of the game. You could run it on Windows 98 and only Windows 98. It was a DOS game at its core, but the sound drivers were written for Windows, so you needed a Windows 9x system to run the game; you couldn't just run it in DOS alone. If you had Windows XP, you could run it, but without the sound. I've tried on Vista and 7 and I can't get it to run at all. And DOS emulators don't work because of what I said about the sound drivers (though you can still play it without the sound). It's like a catch-22. And Windows 98 was already an obsolete system by the time it was released anyway, so the game didn't have much of a life span.
Though some few years later it came back into the spotlight for a brief moment and received an in-depth review on Qbasic Express (http://www.petesqbsite.com/sections/express/issue9/index.html#larry2). It was much appreciated. :)
Every once and a while I'd google the game and find some discussion of it pop up hear and there. Nothing substantial, but any talk about it made my day. Even with all its issues, it was still well-made enough that quite a many people were able to enjoy. So happy 9th anniversary, Larry the Dinosaur 2! You will live on in my mind as a glowing achievement of someone who had way too much time on his hands.
You can still download the game of course! I'm not hosting it; however, you can find it on any of these pages (or just do a Google search):
A special thank you goes out to all who are hosting a download of the game on their site.
Hold on one second! What about Larry the Dinosaur 1 or the uncompleted Larry the Dinosaur 3? Good question! Those are each a story of their own. I'll post about them soon. Until then...
 | |
| The title screen. |
It received fairly good feedback from the then Qbasic community. Amongst other 2d platform games developed in Qbasic, Larry the Dinosaur 2 held up well. It mixed action and puzzle elements and had a progressive story line that rewarded you with cut-scenes at certain points throughout the game. You could pick up and drop items; mixed items with other items (shotgun shells mix with the shotgun to increase your ammo supply, for example). You could fight enemies with your fist, pistol, shotgun, machine-gun, or desert eagle. There were non-playable characters that served the narrative. There was a villain, a friend, and a could-have-been-worse script.
 | |
| The story is revealed through in-game dialogue. |
Outside the world of Qbasic the game received positive feedback as well. It was posted on the front page on freedownloadscenter.com (http://www.freedownloadscenter.com/Reviews/r912.html). Somehow my game fell into the hands of someone there and it hit all the right notes with him (or her), and so he gave it a pleasant review. It was really a surprise to find my game on the front page of a non-programming related website.
In addition to the online review, I was contacted by a representative of a German game magazine, who wanted to publish a blurb about in their next issue. I don't remember what it was named, but I couldn't find the magazine online. I had to sign a disclosure agreement, so that makes it true right? Well, maybe. I don't think anyone would waste their time if it wasn't real, so probably. If I ever find it I'll have to post about it.
 | |
| The weapons locker. |
I also had another representative call me, but this guy was trying to promote an anti-spyware program and wanted me to place an ad. Here's how it worked: when anyone clicked on the link to download the game, it would first direct them to an offer page, giving them the chance to buy the anti-spyware program, or to continue and download the game. A bit annoying if you are just trying to download the game. However, if anyone bought the anti-spyware program I'd get like half the profit. The ad page tracked stats and I was able to see just how many downloads my game was getting. Heh, it was actually what made me decide to stop the ad placement and just go back to a direct download. I got about (or over) 3,000 hits. Holy shit! But...the stats showed how many people made it to the ad page versus how many people continued on to download the game versus how many people bought the anti-spyware program. About a third of the people who made it to the ad page gave up and didn't download the game. So yeah, 2,000 downloads is still a lot. But man, I lost a thousand downloads! The good news is that one--yes, just one--individual out there (out of the 3,000) bought the anti-spyware program. I received a check in the mail for eleven and something dollars; I should have framed it, heh. My brother joked at how that meant that it averaged to about fractions-of-a-cent per hour of the time I spent making the game. Whatever, that was an exciting time. At least I made something! And after seeing those stats, it just wasn't worth it, I wanted more people to download my game! So I removed the ad-placement and just made it a direct download again.
 |
| There are a total of 24 areas to explore, all accessible through the elevator. If I did this again, I would have locked most of the floors at the start, only allowing you to access them via key cards you collect as you progress throughout the game; you'd be introduced to new places progressively instead of all at once and having that confusion of "where the hell do I start?" |
Unfortunately, the game download was hosted on a server of a shotty ISP. Back then I was using dial-up. The terms of the contract stated that if I went over 90 hours (or some number) per month, my account would be deactivated and I'd have to call in to reactivate it; this means downtime--no one can download the game when my account is deactivated. The downtime wasn't the bad part. The bad part was that they wouldn't just reactivate my account; they have to create an new one with a new user name, each time! Part of the URL to download the game had my user account name as part of it. The original download link, when my user name was joeking1, was http://users.sisna.com/joeking1/deltacode/downloads/dos/ld2v10.zip. So the first time we went over the hours and my account was deactivated, the download link became invalid. I could reactivate my account but those bastards wouldn't give me my old user name back, so the new download link was http://users.sisna.com/joeking2/deltacode/downloads/dos/ld2v10.zip. Only the user name changed, joeking1 to joeking2, but that's all it took to kill the traffic my game was getting. Then the user name changes went on and on, to joeking3 and so on each time we went over the limit. I couldn't control my brother's activity--yes, I blame him!
 | ||
| Halfway through the game you meet this nasty guy. |
If only the ISP was the issue; but no, no matter how many times I contacted freedownloadscenter.com to update the link to the new one, they wouldn't do it. Instead they just posted the text from my email on a new page of their site. Who does that? (it's still up: http://www.freedownloadscenter.com/Games/3D_Action_Games/Larry_The_Dinosaur_2.html)
So the awesome downloading spree was over. No one could download my game from there anymore. The excitement was short-lived. Another drawback about this whole experience is the compatibility of the game. You could run it on Windows 98 and only Windows 98. It was a DOS game at its core, but the sound drivers were written for Windows, so you needed a Windows 9x system to run the game; you couldn't just run it in DOS alone. If you had Windows XP, you could run it, but without the sound. I've tried on Vista and 7 and I can't get it to run at all. And DOS emulators don't work because of what I said about the sound drivers (though you can still play it without the sound). It's like a catch-22. And Windows 98 was already an obsolete system by the time it was released anyway, so the game didn't have much of a life span.
 | |
| You can view a detailed description of each item you collect. |
Though some few years later it came back into the spotlight for a brief moment and received an in-depth review on Qbasic Express (http://www.petesqbsite.com/sections/express/issue9/index.html#larry2). It was much appreciated. :)
 | |
| The final boss. Look out, Larry! |
Every once and a while I'd google the game and find some discussion of it pop up hear and there. Nothing substantial, but any talk about it made my day. Even with all its issues, it was still well-made enough that quite a many people were able to enjoy. So happy 9th anniversary, Larry the Dinosaur 2! You will live on in my mind as a glowing achievement of someone who had way too much time on his hands.
You can still download the game of course! I'm not hosting it; however, you can find it on any of these pages (or just do a Google search):
- http://www.phatcode.net/downloads.php?id=114
- http://kentauri.digitalblackie.com/articles/larry2.html
- http://www.qbasic.com/games/dumpbyinput.php?input=Larry%20The%20Dinosaur%202&mode=3
A special thank you goes out to all who are hosting a download of the game on their site.
 | |
| Definitely NOT Larry the Dinosaur 2. |
Hold on one second! What about Larry the Dinosaur 1 or the uncompleted Larry the Dinosaur 3? Good question! Those are each a story of their own. I'll post about them soon. Until then...
 | |
| The end. |
Subscribe to:
Comments (Atom)