ID:116030
 
Keywords: design
I've been trying pretty hard since my last entry to pick up from where I left off on my old project, but I have as of yet been unable to penetrate the surface of what exactly I'd like to do with it. So, instead, I'm going to wax philosophic about design today.

Cycles

Game 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 Artifact

However, 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 Process

So 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.
Very scary. That video made me piss on myself.
Excellent, all according to plan. That was a significant lack of awesome leaving your body. Today, you are 20% cooler.
you said alot of big words but then there was a video so then it made sense
Thanks, I get that a lot. The Internet is a wonderful place.
Being completely honest with yourself, do you think you'll ever actually finish a game?
I believe that, so long as I keep trying, there's hope. After all, the contrary stance disproves the whole, "where there's a will, there's a way" thing.

It's not like I don't know how. You could look at the "mecha game framework" and pathfinding library I made for proof enough on that.

I think the main thing that's holding me back is my standards. I could have made an easy concept ages ago. I could code really easy game in under an hour. But I don't want my game to be easy, I want it to be good.
Sounds like you may need help then. If you have high standards, you may need a few people to help you meet them. Ever thought about working in a team?
Yes, indeed. Although the trouble with working on a team is they kinda expect me to contribute. When I can't even motivate myself, it feels a tad wrong to sign up for one pretending I'd be a reliable contributor to a team.

As I write this, I've resumed work on my game. We'll see how far I get, but I've got a focus on simplicity here which just might work if I can get myself to stick with it for a day or two.

Though I've been considering dabbling with Flash lately, I do not want to leave BYOND without having a great game to maintain on it, and also I suppose the kind of game I want to make is going to be an online tile-based game: BYOND is already 90% of the way there! Consequently, I've stuck another year on my account membership.