CyclesGame development often gets compared to a cycle.
For example, the refinement cycle: where you complete a game, then go back over it and make it a little better, and again and again, until it's good enough. Sometimes, it never becomes good enough, in which case you take it back to the drawing board.
I've yet to master that cycle because I start refining before the game is complete. Let me tell you: that's a great way to get mired down in complete inability to complete a project.
What do you mean I have to put a video in here or else this wall of text will be completely unreadable?
Alright, for your viewing pleasure, here is the most awesome thing on YouTube circa April 2011.
It's completely unrelated, but now you won't need to view any videos uploaded before that.
Design and ArtifactHowever, I didn't start this entry wanting to talk about that cycle, as I think I already have in the past. No, I wanted to talk about another cycle I'm trying to come to grips with: the cycle between designing a game and coding it.
If you completely design a game first, before you write your first line of code, perhaps even making up a whole board game diorama of it, that's certainly the most structured way to go about it. (It would certainly suit an INTJ.) However, no offense to design advocates, there's a down side to that method: you really don't know how the game is going to feel. You can try to visualize it, but it's just not the same as actually playing it.
Conversely, if you design completely on the fly, while you're coding, you'll have a great grip on how the game is going to feel. However, there's no surer method of painting yourself into a corner. You can get away with that in simple projects where it's easy to visualize the whole thing, but it's a formidable stroke of luck if you get away with this in larger projects. (It helps if you're content with releasing a strange spontaneously developed monster in which the parts do not all work right together.)
The ProcessSo here I believe we have another cycle:
1. You don't completely design, you design enough not to paint yourself into corners. (A tough judgement call indeed.)
2. You don't completely code the game on the fly, you code as far as you have put the foresight into designing.
3. Then you look at your project, how it feels versus how you want it to feel. Now, you're ready to go back to the design stage again.
In a larger operation, this cycle is done somewhat automatically (though communication is very necessary) because you'll have separate people involved in designing and programming.
When you're one-manning it, as I have, you're going to have to switch gears. That's tough for me to do. So, there's another good excuse for me to throw on the pile.