ID:94955
 
Keywords: design, motivation
That's right, I'm going to do a mind-numbing entry on my Get Something Done Challenge project every single day, just to piss off SilkWizard. No, just kidding, though we've engaged in minor sophomorism, I've no grudge against the fellow, he does fine work. Nor do I plan to do daily entries on my GSDC project.

Actually, I felt it would be a good idea to write this out to explain a bit about a difficult matter in game development or any other art: Starting.

funny pictures of cats with captions

I'm not sure which is the harder difficulty: starting a project, or fixing all the problems along the way. Sure, there will be hundreds of minor snags later, but at least you've some logic to base your decisions upon. When you're staring at a blank slate, even if you've a good general idea of what you're going to do, you've no threads to grasp outside of those you yourself create.

Don't feel bad - it's not a matter of talent. Even if your brain is a font of unbridled creativity, even if your inner muse has given you her phone number (you lucky prick) you're still in trouble in that you'll have a hard time deciding which of the billions of cool ideas you should implement.

To these ends, my discovered solution has been this: begin to free write a design document. The goal is to try to assemble a good picture in your head how you're going to put this monstrosity awesome new game together. While your brain is a lot faster read/write ram than a document is, the document is nonetheless is an important tool to help your ideas coalescence and take shape.

It's important not to neglect the design document. You shouldn't even try to code until you've a relatively playable game down on paper. No, not every minor detail, that's just soul crushing, but at least have your major parts of the game down and know how they fit together. Without that document, you're setting yourself up to fail on many fronts: not only would you not know what you're getting yourself into, but you'll probably encounter some unforeseen incompatibility issue that would require you recode a significant amount of your project for it to work.

When you've started coding, you're still not done with the design document. If you've put off working on your game for a few days, this document is great for bringing yourself back up to speed. You'll be looking there every time you encounter a situation where you're thinking to yourself, "okay, I finished that part of the game, what next?" Leave notes to remind yourself what's left to be done. Every time you have a cool idea, tack it on to the end of the document (or a seperate document) in a cool idea pile. Your design document should be as much a work in progress as your game itself is.

Of course, every artist's motivations and methods are different. The Wikipedia entry on free writing helps to overcome "apathy and self-criticism," and perhaps the reason why it works for me is because I'm generally an apathetic, continually self-critical individual. Your hang ups are your own, and you may need to do a bit of soul searching and experimentation if this approach isn't right for you.
Thanks for the heads up on free writing, I'll look into that when I have more time.

No, not every minor detail, that's just soul crushing

I do my design work on paper first. Specifically, pads of yellow lined legal paper on an old beat up clipboard. I do try to get every minor detail written down (and often drawn). I draw out all the windows and parts of the interface that the user will see, and then I write the the details of how they interact (procs / arguments). If I can write something out on paper, then I can program it in ten minutes. It's the things that I don't anticipate, or decisions that change part way through development, that can cause me days of set-backs.
IainPeregrine wrote:
I do try to get every minor detail written down (and often drawn). I draw out all the windows and parts of the interface that the user will see, and then I write the the details of how they interact (procs / arguments). If I can write something out on paper, then I can program it in ten minutes. It's the things that I don't anticipate, or decisions that change part way through development, that can cause me days of set-backs.

That's true. I guess the question is just how comfortable you are with getting the details down. I like to leave myself a little wiggle room, but I definitely come to pay for that if I encounter some unforeseen complication that I really needed to plan out ahead of time.

How does one learn what kind of complications they'll encounter that they need to plan out of ahead of time? It seems trial and error is the most likely way to pick these up.

My currently process is to work out the interface using the 4.0x skin and go from there. It's a little slower than doing it on paper, of course, and not quite as conductive to the imagination.
Geldonyetich wrote:
How does one learn what kind of complications they'll encounter that they need to plan out of ahead of time? It seems trial and error is the most likely way to pick these up.

Once you learn how to program, writing code is easy, and changing code can be very quick. Designing a program takes more time. Reconciling different parts of a programs design which are in conflict takes the most time.

I suggest that you always look at a program as input and output. If a program accepts a certain input and then produces the correct output, then it works. Ask yourself "what can my user do" and "how is my program supposed to react". The code you then write is only to link the user's input with the proper output.
IainPeregrine:
I suggest that you always look at a program as input and output. If a program accepts a certain input and then produces the correct output, then it works. Ask yourself "what can my user do" and "how is my program supposed to react". The code you then write is only to link the user's input with the proper output.

To hear this, I'm reminded of a saying I heard repeated in Game Design, Secrets Of The Sages many times, The GUI Is The Game. What the player sees, and what it outputs in reaction to their inputs, is the game.

Simultaneously, though, I'm a bit of an armchair visionary. I want the game to represent more than stimulus and response. I want it to mean something, and this tends to get me into trouble. Seems I'm ever involved in the endeavor of teaching a calculator to love.

We're in agreement that it's a matter of learning. I've hundreds of hours of hammering BYOND under my belt (and hundreds more hours forgotten from frequent siestas, no doubt) and I'm discovering I'm getting increasingly more object oriented as I practice programming. I'm finding it's important to make my code work for me. I tend to code procedural interfaces like crazy now.