The Duelist Goes Gold!
It is done.
I had a lot of fun and a fair number of sleep-deprived nights developing this game. I've already provided a full post-mortem, but here are a few addendums:
Polish is What Separates Indy from Pro
I could think of 100 things to add to this game. A few more minigames, a few tweaks, an extra game mode or two, some more intermediary screens, extra graphical effects and flare, and a bit more polish. And while I was thinking of all the stuff I would have to leave out because of time, I realized that this is what differentiates the professional games from the small hobby games - those little graphical effects count, and those extra game modes had better be there, and that content better show up.
If your game has a lot of depth, people will appreciate that and keep finding ways to have fun. I tossed in about as much as I could get around to, and I think my entry shines a little because of that.
Fonts Suck
Seriously. I tolerated sub-standard graphics in a few instances because (a) I'm not an artist and (b) I'm not a good photo editor and (c) I didn't have time to fool around with that nonsense. But the original font looked prohibitively bad. The second font was unreadable. The third font was not displaying well as a series of textured quads in OpenGL. The fourth font was, again, not readable. I finally got it decent on the fifth font - not pretty, but decent.
I'm Terrible at Guitar
Even if I win and even if I get an internship at RedOctane, they'll never let me get near Guitar Hero because of the insult I bring to the instrument. I spent so much time trying to get decent music, and eventually I buckled and used a synth program for 50% (read: 1 out of 2) of my tracks.
Data Driven Systems Rock Hard
I didn't stress this enough in my post-mortem. It got to the point where to add things in later in the game, I didn't have to look at the code anymore - I just banged together a few text files and I was ready to rock. I still looked at the code, of course - there was constant tweaking and editing and cleaning up - but none of that was related to adding content.
Event Driven Systems Rock Hard Too
I've reemphasized this over and over on this blog, and I'm going to do that again. Nothing satisfies me more than the level of sophistication that introducing event management has added to my code.
Memory Management Systems Rock Hard... Three
I remember a day when I used to argue with pointers - when memory leaks and seg faults were common and hard to track down. When a man could run his program and be almost certain that it would crash at some point, even if that point took some time to get to.
And then I look back and wonder why the hell I hadn't implemented a Smart Pointer. It has to be one of the most beneficial additions that I curse myself for not adding to my C++ games sooner. By no means is it the end-all solution to memory management, but it certainly alleviates 90% of all memory-related headaches.
Writing Things Quickly is Nice, but Writing Them Good is Better
There were a few times when I was tempted to put a quick, dirty hack into my code to get something to work. I always argued with myself, and I won't lie - in one or two instances, that hack made it into the code. But for the large majority of cases, I resisted the urge, and I'm glad I did.
Hacking typically makes things complicated. Debugging gets complicated and understanding code gets complicated and sometimes even writing the hack itself is complicated. And in the end, you've caused more problems then the hack was intended to solve.
Because I avoided adding craziness to my code, it was a lot easier to maintain. Bugs were less frequent and easier to find, and everything just seemed prettier. Had I tried to rush through the development, I could have very easily backed myself into a wall that just required more hacks to get around until eventually adding a simple feature took forever.
When You're Not Coding, You're Thinking About It
Programming is interesting in that it often does not require you to be programming. There were times when I was fed up with looking at my laptop and needed to get away, and so I took a walk or went to the local coffee shop to heckle baristas. And what was I really doing?
Working out code in my head. Working out logic and conditions and requirements. And when I finally got back to my computer, I had the problem so thought-out that I could bang out a solution - a process which, comparatively, takes a much shorter amount of time than thinking through the problem.
Thinking Is No Substitution for Development
This runs somewhat in contrast to my point above. Sometimes I could spend a little too much time at that coffee shop. There comes a point when just thinking is too appealing, and you have to force yourself in front of that computer to start typing. And you have to cut off distractions and resist the urge to 'get up and think some more.' In the end, that code has to get written somehow. While you can work out a lot of problems away from the computer, and it can definitely be a welcome change, you'll invariably work out a lot more when you're actually in the thick of it - creating, debugging, testing, and creating some more.
Finish the Game
It's easy to leave a game in a half-finished state. Neglecting content or leaving obvious deficiencies is tempting sometimes. Hell, I nearly called that font 'finished' at iteration 3 - something which would have clearly hurt me. My game nearly lacked a lot of player feedback which, during testing, I found to be essential to actually playing the game. But they were glaring flaws, and if I wanted any chance of a halfway decent game, they had to be fixed. It's easy to call something 'good enough,' but you must determine if it's actually good enough before you call your game finished.
Finish the Game, I Said
There's a point in development when you realize that your game isn't going to get much better than it is with the time you have left. At this point, it's time to say enough is enough and focus more on tweaking, testing/debugging, and general polish than on cramming in a few half-finished twiddly bits. Near the end of development, I was tinkering with the idea of adding a new duel type or two, but I knew I couldn't get them up to par and still have time to fix that damn font. So I focused on what was important - making my game more presentable and polished.
Make Hundreds of Friends
I can't possibly bring this across more clearly - the people I know are the reason this game got finished. When I was looking for confirmation that my idea had merit, I needed only to look at a comment left on this very blog. When I realized that I couldn't possibly make 20 different high-quality images for the various duelists, my friends were there to back me up and in the process embarrass themselves a bit by being featured in the game. When I was scrambling for a method to create music, my roommate helped me out by letting me use his amp and electric guitar (which didn't actually make it into the game). When I needed expert opinions, I had a friend I could count on to playtest and tell me where I needed improvement, not hesitating to put me in my place when something sucked. When I needed uplifting or motivating, I could send a screenshot over to someone and get a "that's awesome."
Don't Reinvent the Wheel, and Don't Use Square Wheels
Writing your own linked list is great for learning purposes, but the STL's list is usually just as good or even better. Creating your own window is fine, but SDL can do the same thing in about 1/50th the lines of code. DirectSound/DirectMusic may be a great technology, but FMOD is quick and easy.
There a bunch of tools to help you with any job, and you should use the right tool for the right job. In my case, the job was 'finish a small game quick and make it as good as possible.' Obviously, if there was something that could do the same job in less time and fit all my needs, I wanted to use it. I didn't need that extra 1% speed boost or the low level control that some libraries provide. So why spend more time to get it when I could spend that time making the game?
Keep That Toolbox Big
Using glut was not the right decision from the start. It just didn't work properly with the pad. I had to change solutions, and I couldn't waste time moping. Luckily, I knew enough about SDL to switch over relatively painlessly, and if SDL didn't work out, I knew how to create my own windows and use DirectInput.
The point here is this: if I only knew glut, I would've been finished before I even started. I knew enough that if one solution failed me, I had backups. With everything from graphics to sound, I had alternatives available. This is good and should be practiced whenever possible. And if you find out that what you know isn't working but you don't know an alternative, hopefully you're good enough to pick up new technologies fast.
Wow, I think this might have turned out longer than the original post-mortem. I hope I provided some useful information. I could keep going on, but this has already taken me quite a long time to write.
So I'll wrap this up with these short words:
Play the game. Have fun. I was pleased with how it turned out, and I had a great time making it. I hope you enjoy it.
I had a lot of fun and a fair number of sleep-deprived nights developing this game. I've already provided a full post-mortem, but here are a few addendums:
Polish is What Separates Indy from Pro
I could think of 100 things to add to this game. A few more minigames, a few tweaks, an extra game mode or two, some more intermediary screens, extra graphical effects and flare, and a bit more polish. And while I was thinking of all the stuff I would have to leave out because of time, I realized that this is what differentiates the professional games from the small hobby games - those little graphical effects count, and those extra game modes had better be there, and that content better show up.
If your game has a lot of depth, people will appreciate that and keep finding ways to have fun. I tossed in about as much as I could get around to, and I think my entry shines a little because of that.
Fonts Suck
Seriously. I tolerated sub-standard graphics in a few instances because (a) I'm not an artist and (b) I'm not a good photo editor and (c) I didn't have time to fool around with that nonsense. But the original font looked prohibitively bad. The second font was unreadable. The third font was not displaying well as a series of textured quads in OpenGL. The fourth font was, again, not readable. I finally got it decent on the fifth font - not pretty, but decent.
I'm Terrible at Guitar
Even if I win and even if I get an internship at RedOctane, they'll never let me get near Guitar Hero because of the insult I bring to the instrument. I spent so much time trying to get decent music, and eventually I buckled and used a synth program for 50% (read: 1 out of 2) of my tracks.
Data Driven Systems Rock Hard
I didn't stress this enough in my post-mortem. It got to the point where to add things in later in the game, I didn't have to look at the code anymore - I just banged together a few text files and I was ready to rock. I still looked at the code, of course - there was constant tweaking and editing and cleaning up - but none of that was related to adding content.
Event Driven Systems Rock Hard Too
I've reemphasized this over and over on this blog, and I'm going to do that again. Nothing satisfies me more than the level of sophistication that introducing event management has added to my code.
Memory Management Systems Rock Hard... Three
I remember a day when I used to argue with pointers - when memory leaks and seg faults were common and hard to track down. When a man could run his program and be almost certain that it would crash at some point, even if that point took some time to get to.
And then I look back and wonder why the hell I hadn't implemented a Smart Pointer. It has to be one of the most beneficial additions that I curse myself for not adding to my C++ games sooner. By no means is it the end-all solution to memory management, but it certainly alleviates 90% of all memory-related headaches.
Writing Things Quickly is Nice, but Writing Them Good is Better
There were a few times when I was tempted to put a quick, dirty hack into my code to get something to work. I always argued with myself, and I won't lie - in one or two instances, that hack made it into the code. But for the large majority of cases, I resisted the urge, and I'm glad I did.
Hacking typically makes things complicated. Debugging gets complicated and understanding code gets complicated and sometimes even writing the hack itself is complicated. And in the end, you've caused more problems then the hack was intended to solve.
Because I avoided adding craziness to my code, it was a lot easier to maintain. Bugs were less frequent and easier to find, and everything just seemed prettier. Had I tried to rush through the development, I could have very easily backed myself into a wall that just required more hacks to get around until eventually adding a simple feature took forever.
When You're Not Coding, You're Thinking About It
Programming is interesting in that it often does not require you to be programming. There were times when I was fed up with looking at my laptop and needed to get away, and so I took a walk or went to the local coffee shop to heckle baristas. And what was I really doing?
Working out code in my head. Working out logic and conditions and requirements. And when I finally got back to my computer, I had the problem so thought-out that I could bang out a solution - a process which, comparatively, takes a much shorter amount of time than thinking through the problem.
Thinking Is No Substitution for Development
This runs somewhat in contrast to my point above. Sometimes I could spend a little too much time at that coffee shop. There comes a point when just thinking is too appealing, and you have to force yourself in front of that computer to start typing. And you have to cut off distractions and resist the urge to 'get up and think some more.' In the end, that code has to get written somehow. While you can work out a lot of problems away from the computer, and it can definitely be a welcome change, you'll invariably work out a lot more when you're actually in the thick of it - creating, debugging, testing, and creating some more.
Finish the Game
It's easy to leave a game in a half-finished state. Neglecting content or leaving obvious deficiencies is tempting sometimes. Hell, I nearly called that font 'finished' at iteration 3 - something which would have clearly hurt me. My game nearly lacked a lot of player feedback which, during testing, I found to be essential to actually playing the game. But they were glaring flaws, and if I wanted any chance of a halfway decent game, they had to be fixed. It's easy to call something 'good enough,' but you must determine if it's actually good enough before you call your game finished.
Finish the Game, I Said
There's a point in development when you realize that your game isn't going to get much better than it is with the time you have left. At this point, it's time to say enough is enough and focus more on tweaking, testing/debugging, and general polish than on cramming in a few half-finished twiddly bits. Near the end of development, I was tinkering with the idea of adding a new duel type or two, but I knew I couldn't get them up to par and still have time to fix that damn font. So I focused on what was important - making my game more presentable and polished.
Make Hundreds of Friends
I can't possibly bring this across more clearly - the people I know are the reason this game got finished. When I was looking for confirmation that my idea had merit, I needed only to look at a comment left on this very blog. When I realized that I couldn't possibly make 20 different high-quality images for the various duelists, my friends were there to back me up and in the process embarrass themselves a bit by being featured in the game. When I was scrambling for a method to create music, my roommate helped me out by letting me use his amp and electric guitar (which didn't actually make it into the game). When I needed expert opinions, I had a friend I could count on to playtest and tell me where I needed improvement, not hesitating to put me in my place when something sucked. When I needed uplifting or motivating, I could send a screenshot over to someone and get a "that's awesome."
Don't Reinvent the Wheel, and Don't Use Square Wheels
Writing your own linked list is great for learning purposes, but the STL's list is usually just as good or even better. Creating your own window is fine, but SDL can do the same thing in about 1/50th the lines of code. DirectSound/DirectMusic may be a great technology, but FMOD is quick and easy.
There a bunch of tools to help you with any job, and you should use the right tool for the right job. In my case, the job was 'finish a small game quick and make it as good as possible.' Obviously, if there was something that could do the same job in less time and fit all my needs, I wanted to use it. I didn't need that extra 1% speed boost or the low level control that some libraries provide. So why spend more time to get it when I could spend that time making the game?
Keep That Toolbox Big
Using glut was not the right decision from the start. It just didn't work properly with the pad. I had to change solutions, and I couldn't waste time moping. Luckily, I knew enough about SDL to switch over relatively painlessly, and if SDL didn't work out, I knew how to create my own windows and use DirectInput.
The point here is this: if I only knew glut, I would've been finished before I even started. I knew enough that if one solution failed me, I had backups. With everything from graphics to sound, I had alternatives available. This is good and should be practiced whenever possible. And if you find out that what you know isn't working but you don't know an alternative, hopefully you're good enough to pick up new technologies fast.
Wow, I think this might have turned out longer than the original post-mortem. I hope I provided some useful information. I could keep going on, but this has already taken me quite a long time to write.
So I'll wrap this up with these short words:
Play the game. Have fun. I was pleased with how it turned out, and I had a great time making it. I hope you enjoy it.
posted by Brian Sowers at
1:49 AM
0 Comments:
Post a Comment
<< Home