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.
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. |
Game design ain't everything
I've done a lot of talk lately about planning and design. It is an important step in the game development process; but if you struggle with this part of the process, don't let it become an obstruction. It's meant to help, not to get in the way. Like all things, it takes practice. You do your best with what you can and then you move on. You may not have the greatest design, but at the very least you have a clearer picture of the game you are trying to develop. So whenever you are ready, move on to the next step and have fun! That's what it's all about, right?
Game design on one piece of paper
Can you fit your game idea onto one 8.5x11 piece of paper? I think you should be able to show a good idea of the game with many of its core concepts, from the story to gameplay mechanics to concept art and even some mockups. A stranger should be able to understand your vision of the game by only looking at this piece of paper. Is your game idea strong enough for that? Does it have enough solid ideas and a unified, focused theme? Does it have enough content to go beyond a simple one or two-level demo? If it doesn't meet all of these points, then would it be wise to start coding the game until you do?
When you get down to it, making a game takes a lot of time. Brainstorming ideas of paper takes virtually no time in comparison. It's fun to jump in and start coding something, but having a good idea of what you want to see at the end will save you countless amounts of hours from redesigns of code, graphics, levels, and sound.
The rule of thumb is that the more time you spend designing your game, and the more complete that design is, the more smooth the game development process will go. You realize problems with your design early on; and when you catch them in the design phase, all you need to do is cross them out, so to speak. It doesn't take a massive overhaul of the code, depending on how complex the problem is to fix.
Something I run into when designing is that I realize how incomplete my game is. It challenges me to think about content and ideas to keep the game interesting through to the end. Sometimes I realize that I don't like my idea or the direction I'm taking with the game, so I stop there, and it only took a couple hours of my time as opposed to hundreds of hours developing the game to the point where I realize the same problem.
It does take practice. If you're used to jumping in with both feet and coding your way along, learning to think about the game in the design process can be frustrating. You don't "see" your game in action, but only what's on the paper. However, every problem you encounter along the design process you'd encounter in the implementation (coding) process anyway. Designing your game beforehand allows you to tackle all these problems head-on and sort them out beforehand so you have a less frustrating (and more fun) time implementing your game, and a much better chance of following through to the end and releasing a quality game.
When you get down to it, making a game takes a lot of time. Brainstorming ideas of paper takes virtually no time in comparison. It's fun to jump in and start coding something, but having a good idea of what you want to see at the end will save you countless amounts of hours from redesigns of code, graphics, levels, and sound.
The rule of thumb is that the more time you spend designing your game, and the more complete that design is, the more smooth the game development process will go. You realize problems with your design early on; and when you catch them in the design phase, all you need to do is cross them out, so to speak. It doesn't take a massive overhaul of the code, depending on how complex the problem is to fix.
Something I run into when designing is that I realize how incomplete my game is. It challenges me to think about content and ideas to keep the game interesting through to the end. Sometimes I realize that I don't like my idea or the direction I'm taking with the game, so I stop there, and it only took a couple hours of my time as opposed to hundreds of hours developing the game to the point where I realize the same problem.
It does take practice. If you're used to jumping in with both feet and coding your way along, learning to think about the game in the design process can be frustrating. You don't "see" your game in action, but only what's on the paper. However, every problem you encounter along the design process you'd encounter in the implementation (coding) process anyway. Designing your game beforehand allows you to tackle all these problems head-on and sort them out beforehand so you have a less frustrating (and more fun) time implementing your game, and a much better chance of following through to the end and releasing a quality game.
Don't focus on the details
One of my biggest mistakes when it comes to video game development is spending too much...I mean way too much...time on the details. I have this problem. From the start I spend more hours tweaking things like graphics and sound way before there is anything resembling a game. And when I do have something resembling a game, such as a simple one-level demo, I spend even more time messing around with minute details than on moving the game forward.
Everything has to be perfect before I can move forward. The problem with this is if I want to change something down the road; hours of work gets thrown away with more hours of work required for the changes. An example may be redrawing an entire tile set because I decided to go with a jungle level instead of a desert one. Another example would be continually redesigning levels as the game evolves. These all take time and lots of it.
The most effective way to save time is to layout your entire game in advance, and then fill in the details after the core functionality is completed. This pattern not only applies to video games, but to other creative practices as well. Take drawing for example; many great artists will sketch out an outline of their drawing first, then draw the shapes, and finally -- when everything is how they want -- fill in the details. The same logic applies: if I being a drawing by working out the details of every square inch, and if I want to change something halfway through, it's going to take a lot of eraser and time to fix (not to mention the time wasted by all the work that was just erased). This approach just isn't effective anywhere.
So if you're still the perfectionist, then be perfect with the planning and design. Don't move forward with the details until you are happy with your design. Then don't move forward with the details until you have built a robust framework that can support your design. Then once that is all done, don't yet focus on the details until you've built most of the game; use temporary or placeholder graphics and music (they aren't important at this stage; what's important is finishing the game). Then finally, when all there is to do is fill in the details and to polish your game, you can have at it and be rewarded with an actual game when you are done (and not a game still in the making).
These are just guidelines though. "Easier said than done," you might think. I agree. For me, it's a goal and not an actual practice -- a skill to improve upon. What's fun about game development is, well, developing a game and not having to worry about the less-entertaining work of documentation and low-level coding. Though, sometimes documentation and low-level coding can be fun for geeks like myself. But seeing your game in action as you craft it is an addiction.
Everything has to be perfect before I can move forward. The problem with this is if I want to change something down the road; hours of work gets thrown away with more hours of work required for the changes. An example may be redrawing an entire tile set because I decided to go with a jungle level instead of a desert one. Another example would be continually redesigning levels as the game evolves. These all take time and lots of it.
The most effective way to save time is to layout your entire game in advance, and then fill in the details after the core functionality is completed. This pattern not only applies to video games, but to other creative practices as well. Take drawing for example; many great artists will sketch out an outline of their drawing first, then draw the shapes, and finally -- when everything is how they want -- fill in the details. The same logic applies: if I being a drawing by working out the details of every square inch, and if I want to change something halfway through, it's going to take a lot of eraser and time to fix (not to mention the time wasted by all the work that was just erased). This approach just isn't effective anywhere.
So if you're still the perfectionist, then be perfect with the planning and design. Don't move forward with the details until you are happy with your design. Then don't move forward with the details until you have built a robust framework that can support your design. Then once that is all done, don't yet focus on the details until you've built most of the game; use temporary or placeholder graphics and music (they aren't important at this stage; what's important is finishing the game). Then finally, when all there is to do is fill in the details and to polish your game, you can have at it and be rewarded with an actual game when you are done (and not a game still in the making).
These are just guidelines though. "Easier said than done," you might think. I agree. For me, it's a goal and not an actual practice -- a skill to improve upon. What's fun about game development is, well, developing a game and not having to worry about the less-entertaining work of documentation and low-level coding. Though, sometimes documentation and low-level coding can be fun for geeks like myself. But seeing your game in action as you craft it is an addiction.
No code is clean code
Think about it. The less code you can write the better. And I don't mean by cramming lines of code together or shortening variable names; I mean things like consolidating repetitive code into functions, separating game logic and presentation code from the rest of the program into data files (like XML), and being clever with your code like being clever with words on Twitter (keeping it short, simple and to the point).
Cap your time
Here's an idea. Break your project into phases. The first phase is something playable with a couple levels; the second phase adds a bit more and has all the levels, story, bosses, and music implemented; and the third phase is for polishing your game and filling in the gaps.
Now break each phase down into hourly estimates of categories. For instance: planning and design, programming, artwork, level design, music and sound. Here's an example for a small game:
Phase I
Planning and design: 2 hours
Programming: 15 hours
Artwork: 10 hours
Level Design: 10 hours
Music and sound: 10 hours
Phase II
Planning and design: 3 hours
Programming: 30 hours
Artwork: 20 hours
Level Design: 30 hours
Music and sound: 15 hours
Phase III
Planning and design: n/a
Programming/bug-fixes: 10 hours
Artwork touch-up: 5 hours
Level Design fixes/changes: 10 hours
Music and sound touch-up: 5 hours
175 hours! Initially I was thinking it'd end up around 50 hours, but breaking it up into phases showed me that I greatly underestimated that. And when I estimate my hours I like to overestimate, because things aren't going to go as smooth as you think they will half the time. Breaking your game up into phases does 2 things: first, you focus on reaching the end of the phase and not the end of the game's development (so you're less likely to be caught up with feature creep and the like), second your hours are better estimated because you are estimating hours with more concrete markers than just "finishing the game."
Here's the second part of my idea: DO NOT GO OVER YOUR HOURS!!!
Why? Because if you go over the when will it end? Ideas and the quest for perfection always get me spending more time on little details than I should. Also, you if keep to your word, when the time gets close and you're not quite there you will have to finish up with what you have, even if that means putting in plain (placeholder) graphics and just the raw bones of your code. The goal is to reach the end of the phase, not to complete the game. And once you reach the end of the phase, you can assess where you are at and where you want to go and plan your next phase. This type of planning/execution/planning pattern is used in commercial software companies in one form or another; some examples are Scrum and Agile development. There's power in this strategy as it keeps you focused on more realistic (and closer) goals. It also allows for changes to be made if needed (re-planning a phase, for example).
Now break each phase down into hourly estimates of categories. For instance: planning and design, programming, artwork, level design, music and sound. Here's an example for a small game:
Phase I
Planning and design: 2 hours
Programming: 15 hours
Artwork: 10 hours
Level Design: 10 hours
Music and sound: 10 hours
Phase II
Planning and design: 3 hours
Programming: 30 hours
Artwork: 20 hours
Level Design: 30 hours
Music and sound: 15 hours
Phase III
Planning and design: n/a
Programming/bug-fixes: 10 hours
Artwork touch-up: 5 hours
Level Design fixes/changes: 10 hours
Music and sound touch-up: 5 hours
175 hours! Initially I was thinking it'd end up around 50 hours, but breaking it up into phases showed me that I greatly underestimated that. And when I estimate my hours I like to overestimate, because things aren't going to go as smooth as you think they will half the time. Breaking your game up into phases does 2 things: first, you focus on reaching the end of the phase and not the end of the game's development (so you're less likely to be caught up with feature creep and the like), second your hours are better estimated because you are estimating hours with more concrete markers than just "finishing the game."
Here's the second part of my idea: DO NOT GO OVER YOUR HOURS!!!
Why? Because if you go over the when will it end? Ideas and the quest for perfection always get me spending more time on little details than I should. Also, you if keep to your word, when the time gets close and you're not quite there you will have to finish up with what you have, even if that means putting in plain (placeholder) graphics and just the raw bones of your code. The goal is to reach the end of the phase, not to complete the game. And once you reach the end of the phase, you can assess where you are at and where you want to go and plan your next phase. This type of planning/execution/planning pattern is used in commercial software companies in one form or another; some examples are Scrum and Agile development. There's power in this strategy as it keeps you focused on more realistic (and closer) goals. It also allows for changes to be made if needed (re-planning a phase, for example).
A programming language is not a game development framework
I think many people fall into this trap. You have an idea for a game, so you start coding. Everything goes well at first and by next week you have an awesome demo to showcase your upcoming game: your player can do some awesome moves, the graphics are slick, and it all looks promising. But then...months go by and progress has sharply declined. Sometimes there is nothing more to show. What happened?
From the programming side of things, the game starts to collapse under its own weight -- the code structure that supported the demo cannot handle the complexity of a complete game; and building upon such a flaky framework leads to mounds of spaghetti and buggy code.
There are many assumptions, but I believe the core issue is that the programmer relies too much on features of the programming language rather than a well thought-out and planned framework to support the game. What does this mean? I'll explain.
The idea of a game framework (sometimes referred to as a game engine) is to have you only writing code that deals with the game logic, fun stuff like: weapon properties, special moves, power-ups, level dynamics, etc. That's all you need to define your game anyway, and you send that game data to the framework (or game engine). The framework is the inner-workings of the game. It consists of helpful methods (subroutines or functions) that load levels, organize and render graphics, calculate objects on the map, churn the physics for each frame, and so on. It's important to keep the framework separate from the game logic by providing an interface. The interface is a set of methods that you use to send the data the framework needs to run a game and nothing more. One example is a method that accepts a file name of a map to load for the current level. Another example is a method that accepts properties for an object and then creates and adds that object to the map (like for a demon that throws fire you'd pass its strength, speed, skill, etc.); the framework would then be responsible for rendering and moving the demon under the rules you provided (through another method). The idea is that the game logic is separate from the lower-level logic that the game is running on top of; and you communicate with the framework via its interface. When people try to code these two parts together...well...it gets messy.
A suitable framework for your game should be developed first or in phases as the game progresses. If you are not sure how to go about it then you can look at some examples. Old-school games like Quake have their source code available. Use of frameworks apply to web design as well, so if you understand web development check out the source code for frameworks like Wordpress or Magento. If you want to save yourself the time of writing your own framework, and you want to jump right into game development, then a quick search of Google for "game development frameworks" will give you more than plenty to chew on.
From the programming side of things, the game starts to collapse under its own weight -- the code structure that supported the demo cannot handle the complexity of a complete game; and building upon such a flaky framework leads to mounds of spaghetti and buggy code.
There are many assumptions, but I believe the core issue is that the programmer relies too much on features of the programming language rather than a well thought-out and planned framework to support the game. What does this mean? I'll explain.
The idea of a game framework (sometimes referred to as a game engine) is to have you only writing code that deals with the game logic, fun stuff like: weapon properties, special moves, power-ups, level dynamics, etc. That's all you need to define your game anyway, and you send that game data to the framework (or game engine). The framework is the inner-workings of the game. It consists of helpful methods (subroutines or functions) that load levels, organize and render graphics, calculate objects on the map, churn the physics for each frame, and so on. It's important to keep the framework separate from the game logic by providing an interface. The interface is a set of methods that you use to send the data the framework needs to run a game and nothing more. One example is a method that accepts a file name of a map to load for the current level. Another example is a method that accepts properties for an object and then creates and adds that object to the map (like for a demon that throws fire you'd pass its strength, speed, skill, etc.); the framework would then be responsible for rendering and moving the demon under the rules you provided (through another method). The idea is that the game logic is separate from the lower-level logic that the game is running on top of; and you communicate with the framework via its interface. When people try to code these two parts together...well...it gets messy.
A suitable framework for your game should be developed first or in phases as the game progresses. If you are not sure how to go about it then you can look at some examples. Old-school games like Quake have their source code available. Use of frameworks apply to web design as well, so if you understand web development check out the source code for frameworks like Wordpress or Magento. If you want to save yourself the time of writing your own framework, and you want to jump right into game development, then a quick search of Google for "game development frameworks" will give you more than plenty to chew on.
Back from hiatus
A good amount of time has passed; life happens...you know. Even so, I could have kept up on this blog. There is nothing new gaming wise. There are a lot of days where I am irked by the fact that I haven't release anything...not even a simple game...since 2007. What's the big deal? Why is it so hard to finish something today? Blah blah blah, whatever.
Anyway, I'm back and am going to give this blog another shot. Weekly postings about...I don't know...stuff. Good strategies for game development may be the focus for a while. I'm not writing another line of code until I have my next game on paper! Seriously, like a solid plan that'll get something done, and soon.
Anyway, I'm back and am going to give this blog another shot. Weekly postings about...I don't know...stuff. Good strategies for game development may be the focus for a while. I'm not writing another line of code until I have my next game on paper! Seriously, like a solid plan that'll get something done, and soon.
Subscribe to:
Posts (Atom)