What Is Your Game Design Technique?

I will start by saying there is no correct technique. That will change with every team and every project. I can only offer a suggestion.

I think you've got these first two steps backwards. You will come up with a great idea, spend all this time on documentation, and then finally create a prototype, only to find out that while it sounds good on paper, it isn't fun. Now you've done a lot of work which you won't want to throw away, and you may end up trying really hard to make the game fun but fall short.

If it was me, I would pair up a designer and an artist, and have them create some prototypes. If you're not a programmer, just do it on paper. Exchange the games, play them, and see what you guys like. Once you've got a fun core idea, then you do all the documentation stuff.

I am speaking from experience here, having made many games that just aren't as fun as they were in my head.

Waterfall or agile? That's the first thing to decide :)

Tip: Agile is the correct one.

Next, how many times you have failed already? It changes things, unless you are overgod (there are some people like that), you will fail several first projects. So for first time failure the critical part is a strict deadline (if you are pressed on time), since you want to fail fast, early and a lot (on the other hand going on with a long project doomed to failure gives you some additional experience). After you finished your first game you can give yourself some more slack (but not too much :D).

Basicly, determine your time budget, this is the most important aspect that will affect the whole design process.

Next, get a decent solid idea before you start (it's highly recommend to talk about it with others - not your team). You don't want to invent core features after you started the project (I make this mistake over and over again and always pay for it :D So, don't be like me :)).

Then determine your financial budget (how much money you are willing to put into it before you get any sales - if that's your first project set it at "0" :)).

Once these are covered I start the project:

1) I write down all core design goals and explanation of some mechanics (not all). Also I research the "marketing" part (who will play my game, track appropriate forums, websites of that genre, fan groups, etc).

2) Then I decide on release date (extremelly important!) and the price.

3) Then I make a prototype.

4) If prototype is good I proceed, if not the project is scrapped.

5) I decide on some sort of overall shedule, at least the milestones like alpha, beta, crowdfunding/greenlight (if needed/planned), final release, etc. Also look for contractors (artists in my case).

6) Then I make the game (if lucky :D) adjusting it/redoing as needed.

7) If the game was not cancelled by now I do the release (and all alpha/beta/whatever). And... go on vacations :D

8) Then, after release I end up in a hell, bug fixing, missing urgent features, etc, etc. All the usual pile of stuff that pop up after you thought you made the game.

9) After like 6 months it all calms down and I only maintain the game and can proceed with another one.

But if you have no release date how do you know how many features you can put into the game? Or what genre you can afford to make? You need to know first if you will be doing the game 10 years or 2 weeks :)

Besides, what's the point of making a prototype that you later asses it would take too long for you to finish and you can't afford?

It does not matter if my prototype of a World of Warcraft clone is fun or not if I have nowhere near resources to make that kind of game :)

No documents. No documents.

We have a solid general idea of what the core gameplay goal is. Early on, this can shift and adjust and tweak every week or two. And then every month or two as prototypes crystallize, it's all about playing them with a very harsh judgement, and deciding what is or isn't fun. It's completely iterative, and we never quite know where the game will wind up. But on paper designs do nothing for me.

Iterative design:

http://christophermpark.blogspot.com/2009/10/iterative-game-design-right-way.html

Waterfall or agile? That's the first thing to decide

if you think about it, is waterfall even really possible in game development?

stuff (hardware, techniques, etc) changes so fast, and game designs change so often that i'm not sure its even possible to simply design, it type it in, debug it, profile and optimize, then release. being a development method originally developed for applications, not games, waterfall doesn't include playtesting and balancing in the process, a step which is not required in applications, but almost definitely required for games (unless you're making a chess clone or something).

But if you have no release date how do you know how many features you can put into the game? Or what genre you can afford to make? You need to know first if you will be doing the game 10 years or 2 weeks
Besides, what's the point of making a prototype that you later asses it would take too long for you to finish and you can't afford?

It does not matter if my prototype of a World of Warcraft clone is fun or not if I have nowhere near resources to make that kind of game

i figure out that kind of stuff before i prototype.

i start with a game idea.

then a feature list.

then comes:

"ok, how long will this take?" (time required)

"whats the market?" (popularity)

"how much would it go for?" (price)

"how much might i make?" (expected sales)

"is it worth it?" (time required vs expected sales)

i actually very seldom prototype things, only when its something new and untried, and i'm not relatively sure about it. and that only comes after i have a game idea, a feature list, an idea how long it would take, and it looks like it might sell well enough to be worth making.