Three good project habits
Today, I'd like to share some habits I use for software development. These are version control, logs, and bug tracking.
Version Control
If you haven't started using this, now is a good time. What is version control? It's basically a backup program. Instead of having backup files and folders -- if that's been your backup system -- version control takes a snapshot of your project with every change you make. Every snapshot is a version of your project in development, and you can go back to it at anytime.
I used to backup my projects with zip archives (backup-2012-01-01.zip, for example). This is better than nothing, but frustrating. If I went of the rails on some new feature and need to roll back, it might be to a backup a week or month ago -- whenever I saved it last. It's too much work to back it up every day, let alone for every change this way. It can be demotivating to work back to where you were from when you last backed up (which could have been days, weeks, or longer). But with version control, every change is recorded, so I don't run into this problem -- or if I do it is just a couple changes needed to get back to where I was.
I use Git. If you develop on Windows, then Mercurial is a good alternative. SVN is okay, but Git and Mercurial are much better. This article isn't a tutorial on version control. You're on your own here, but there are great articles on the web. Just Google them.
Keep a Log
Keep a log of your project. I don't mean some boring summary every day. Whenever you make a change, just note it. This makes it easy to get back up to speed in case you left your project for longer than a week. You can look back at what you did without struggling to remember.
Version control programs let you take notes with each commit (version, snapshot, etc.). I use this feature in Git to keep notes on the changes I make. Sometimes it's just a one-line summary, other times a couple paragraphs. Writing something someone else would understand is a good rule.
Here's an example of some notes for Toadman 3:
commit 561f32bd9b5ad211055b53d08e68a87e9d066b94
Author: Joe King
Date: Sun Nov 18 12:09:53 2012 -0700
Add title background
This will be used for the game menu.
commit 44b1af17d755e8f9d0630e5f6ce31ae7c4b7404d
Author: Joe King
Date: Sun Nov 11 20:46:42 2012 -0700
Add font module
I consolidated the font rendering responsibilities into this module.
I also added a text centering method.
commit b840795611af50f19dc6c350f70f2ed1e8a28107
Author: Joe King
Date: Thu Nov 1 23:01:26 2012 -0600
Fire puffs of smoke when tree is destroyed
It looks cool and gives a more rewarding feel to the destruction.
commit 1705174faa5288f44fb6c83fa48b5f0d9e3a8a28
Author: Joe King
Date: Thu Nov 1 22:58:22 2012 -0600
Give ice-brick graphics winter theme
For the ice-brick levels, I updated the tiles to reflect a more winter
type of theme.
Keep track of your bugs!
Write down every bug you encounter. These are easy to forget. Yes, you don't completely forget all of them. But it's easy to release a demo with some bug you meant to fix, sometimes finding that no one could get passed level one because of it.
Not only this, but I bet you'll record more bugs than you thought you had. You can only juggle so many bugs in your head at a time; it's easy for the not-so-annoying ones to slip under the rug. Once you clear your head of the bugs that are currently bothering you (by writing them down), you're able to spot more bugs. These might have been bugs you spotted before, but subconsciously ignored because of more pressing bugs.
Once you have them all written down (or as many as you can), you now have a list of bugs you should fix before releasing your game. Or you could at least prioritize them and take care of the ones that are worth fixing.
Basic Gaming Issue #9
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.
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.
Subscribe to:
Posts (Atom)