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).

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.