Command-R, The uDevGames 2004 Mascot
As you may know, uDevGames 2008 is now underway. Congrats to Carlos and the hardworking crew at iDevGames on the launch, and best of luck to everyone involved.
Following are some hints and tips gleaned from my experience with the contest, for those entering for the first time, or maybe even veterans looking for some extra advice. I’d say I’m qualified at this point to give it– in 2004, I wrote Kill Dr. Cote for uDevGames, which took first place in the Gameplay category, and landed a publishing deal with Freeverse. It now earns me royalties and also led to my career in the industry.
Know Your Limitations, But Don’t Limit Yourself
If you take one line of advice from this entire article, let that be it. I certainly won’t be the only one to tell you, either. You need to choose an idea that you can turn into a game in three months. If this is your first time in the contest, you’re not going to be able to pull off an engrossing RPG, or a 3D third person action game. You need to keep things feasible. You’ll score higher with a smaller idea that’s fully executed and polished than a half-finished, really complicated idea. In fact, if you’re half finished at the 3 month mark, you will tank. I guarantee it.
That said, you can overdo it. Many people will say that when you start off, you should make Pong. Then move up to something like Pac-Man. Then maybe do something that remotely resembles a game you want to make. I actually do not condone this advice. You should definitely push yourself for uDG. Kill Dr. Cote was a top-down, 3D, sprite-based arena shooter, and it was my first game using C++ and OpenGL. The fact that I loved the idea so much inspired me to work harder on it, which would not have happened if I had tried to make, say, a Breakout clone.
Also, score wise, even well-done ideas that are very un-ambitious will not rise to the top. For instance, a game I very much enjoyed playing in the 2004 contest was PictureFrameX. It was a Mac version of a solitaire game. For all intents and purposes, there were no visual flaws with the program. It was a perfect solitaire game, and it never saw top marks in any category. So definitely aim high, but always realize that whatever you come up with, you have to follow through and make.
Prototype Early
Plan your development process to be iterative. That is, get a playable version of your game as early as possible. That playable version is called a Prototype. Love the prototype. That will tell you if your idea is fun, and you will get ideas on how to make it more fun. You can distribute the prototype to others for feedback, and THEY can help you make the game more fun.
The “iterative” in the dev process means that you will be working to “iterate” on your prototype. You will concentrate on making a version that is playable that adds something to your current version. As long as you focus on that, you will always have something playable when the three months comes to an end.
The wrong way to do it would be, say, to spend a month designing everything, spend a month making a game engine, then finish up the game on month three. It’s a natural way to think, but realize you have over TWO MONTHS before you can even play your game! If it’s not fun, you’re screwed! So prototype fast, and get people playing it! And if it’s really, REALLY fun, they might even play your game instead of working on their own 
Make A Game, Not An Engine
This is also important. You’re here to make a game. Not an engine. You can write the prettiest, best-designed code in the world, but if your game isn’t fun, you will tank.
During every game I’ve made, the dev process has been in two phases. The first is the foundation phase. This is where you write reusable code, get each system of your game running in harmony with the rest, and generally build things out of stone. The second phase is a balls-out code-like-a-bat-out-of-hell phase where readability and interoperability be damned, and to the blazes with reusability: the code has to work, it has to work for this one game, and it has to work RIGHT NOW. You need to recognize that you will go through both phases, and that’s fine. At some point, that meticulous engine you’ve designed will have shit code sprinkled everywhere in it by the time you’re done. You have to learn not to hold it sacred, and when you’re at that point, you code what you need to code to get the game working.
Pace Yourself
Three months is a long time, and you need to pace yourself so you minimize the time you spend burned out, and also not lose interest in the game. Make no mistake, this contest will drain you. You WILL burn out. You WILL get sick of your game. Pacing yourself will prevent you from completely crashing and burning halfway through.
uDevGames, like any good play, has three acts. A beginning, a middle, and an end. Conveniently, it’s a three month contest, so you can consider each month to be a certain act.
Month One is when everyone flies out of the gate. Everyone is excited about their project, everyone’s working on full tanks. You’ll see some prototypes and mockups flying about. Energy is high. During this month, you’ll want to have a solid playable game. If that seems like a fast amount of time, that’s only because you’ll want to be prepared for Month Two.
Month Two is the valley. You will burn out in Month Two. Your energy reserves will be used up, and personal issues will affect you more than usual. During this month, your job is just to stay focused, and keep iterating. Leave a few fun things to do for this time. When I burned out from coding Kill Dr. Cote, for instance, switching over to composing music was how I kept my focus. If you don’t have a prototype by Month Two, you’re in danger of fizzling out completely.
Month Three is the race to the finish. Everyone’s got their energy back, and everyone’s going apeshit trying to finish their game in the deadline. This is where you will need to start drawing lines in the sand. That is, you need to freeze features at some point during this time. Freezing features means you’re adding no more new elements to the game, and you’re instead focusing on bug fixing and adding polish.
Remember The Big Picture
Us programmers love little details. It’s in our nature. We love writing that brilliant line of code. Or a wicked cool function. In a project of tens or even hundreds of source files, we love looking at a few lines at a time. But it’s easy to lose focus like that, and get lost in the minutia. Succeeding at uDevGames means keeping your eye on the prize, and remembering that you’re here to make a GAME.
Say we’re solidly in month three. It’s go time. The end is in sight. But you have a nasty bug with the physics you’re working on for your game. It seems in one strange condition, it behaves incorrectly. You don’t know why. You’ve torn up your code looking for the cause. At this point, you might be tempted to alter your system in such a way that this weird condition now behaves. This may not be the best course of action. In month three, you will probably want to just slap a band-aid on it, and focus on other aspects of your game that are lacking. Like how there are no menus, at all. Or maybe, you may even need to just ignore the bug, since it might not be as bad to others as it is to you.
Break everything down into easy tasks
As I mentioned, us programmers love little details. Logical instructions. But the development cycle of a game is hardly that. It’s very subjective, artistic, and chaotic. You will need to take that chaos and break it down into steps in order to do well.
So say you’re making Pac-Man. You may first break it down into the following pieces: The Maze, The Player, The Dots, The Enemies, The Powerups. But that’s not enough. You will have to break the maze up further: Drawing it, creating it, being able to access where the walls are for the player/ghosts, etc…. You’ll have to break the player up into: Drawing it, controlling it, dying, respawning, and so on.
The more you break down these steps, the easier each one is to process. You can better estimate times needed to complete each task, and you can also get a better sense of progress when you can complete one smaller task instead of working vaguely on a larger one. What sounds better, “I worked on some player stuff”, or “I added player dying and respawning”?
In some extreme cases, you will need to break things down into trivial steps. During the second month in 2004, I was burned out, and literally had to focus on the step of “Open Xcode, Open File x” in order to get momentum going. No shame in that. Do it. If the step before you seems too big or complicated, break it down until it’s the size of something you can digest.
Blog Publicly
The uDevGames site has developer diaries. Use them. Stay connected with your peers, your players, and yourself. Document what you’ve gotten done, what you’re going to work on, and how you’re holding up. This is all precious data that you can use later on. You’ll also build up hype for your game. Plus, it’s fun.
There is a section in the uDevGames site for past developer diaries. If these get posted, I recommend you read through some of them. Remember that precious data I talked about? You can collect that from everyone else. Pay attention to the dates, and recognize which entries are from Month One, Two, and Three.
There’s another cool trick that used in 2004 that may not be totally ethical, but provided great results. In 2004, I often blogged about features I added– BEFORE I added them. “But Fic,” you say. “Isn’t that lying?” Maybe so, but what that does is put you in a position where you then HAVE to deliver that feature. You’ve already said you did it! In my case, that added pressure helped me to implement those features faster, so I wouldn’t be caught lying! :) Of course, there’s always the risk of that happening, in which case the whole trick will backfire, so use with caution!
Good Luck
That’s all for now. I will definitely have more advice for you as we get on in the contest. Stay tuned to this site, and I’ll help you follow through with your game idea, help you with more concrete things such as making sure you’re distributing a working, double-clickable app that conforms to the rules, and how to finish up the contest with a bang. In the meantime, best of luck to you. This is your chance to show us all what you’re made of!
Until then,
FIC OUT.
So if you’ve read my previous post, you are familiar with the three ideas I’ve been going between for the uDevGames contest. If you haven’t, here they are in a nutshell:
