Most people on this forum would disagree with me, because their situation is different. If you are a designer in a 6 people team and you spend a year designing the game that is produced with 1 year you only used 20% time of the team. But if you are a lone guy doing both design and coding and you spend 6 months on designing a 1 year game then you used up 50% of resources on design. That's unacceptable amount.
3 months is awfully long for a hobbist who also needs to spend the time later on the coding and making gfx assets.
In short, if your design will be used by a team of expensive programmers later, go all the way, any amount spent on design will most likely pay off. But if you doing it all alone then the time used up on the design is simply eating up the resources that you could use on the implementation instead.
Yes, but without a good design implementation won't work, and result in even more wasted time.
The whole reason you take time to design games is because it's cheaper to design than it is to implement, at every stage of the development process. It doesn't matter if you're solo or with a group of 50 dudes, you will save time if you work out design issues before implementation.
However! Really, honestly, I cannot stress enough that monolothic design is a bad idea. You don't need to spend a year with dwarven design smiths hand forging the legendary Design Document of Narsil deep in their gilded halls before you think about touching code. Rather, design works well if it is intermingled with the development process. This is actually true for projects of virtually any size, big and small. Even a small game with less moving parts can benefit from not designing the entire thing up front, but rather designing as you go.
When I was in college, I came up with a method for making games that works like this. I'll use the game Sanctum as an example (new FPSTD, First Person Shoot Tower-Defense that came out like a week ago).
1) Conceptualize. Come up with the idea for the game. In this case, it's simply, "Make a tower defense game where you also control an individual ala a first person shooter that fights creep waves along with towers you build, ala a standard tower defense game."
2) Rough design: Come up with a framework design for the game. This encompasses, more or less, the overall mechanics of the game and points out some questions that will crop up in the future. Perspective will be first person, you'll have a couple guns you can switch between (should they have ammo or powerups?). You will fight enemies with standard FPS mechanics (should there be health?). You can build towers to defend against mindless creeps that will suicide run into your base (should I allow mazing or gauntlet style construction? What will be build interface be? Should I implement a top-down view for building?)
3) Identify the core of the game: Most games have a core, or a few cores, that make up the most important mechanics of the game. Likely candidates for core mechanics are actions that players will be performing often, or a mechanic that many other mechanics depend upon. It is very key to identify core mechanics and refine them well; if they suck your game will suck. If your secondary mechanics suck, then your game can still be good with a couple problems that detract from, but do not ruin, the experience. In Sanctum, the core mechanic is the interplay between first person shooter and tower defense, being able to maneuver through your towers and fight alongside them to kill the enemy.
4) Refine and test the core mechanic: Here's where you'll spend a lot of time in the design phase. Try to start off with a simple, but complete, slice of your core mechanic and test the shit out of it. Make prototypes, digital or paper. Make them rough and fast, but good enough to thoroughly test the mechanic. In this case, I'd fire up the UDK and code a rough turret I can place down, just a box that shoots anything hostile near it. Then I'd spawn a bunch of simple bots that run toward me, or even simpler, get some friends to take place of the bots and try to navigate through a turret maze toward me. This should give me an idea whether or not this idea is a dud. It also lets me identify potential problems down the way (moving around turrets is awkward, it's much easier to fight while standing on a turret, my guns seem way more useful than the turrets, etc). Mostly, I'm not worried about exact numbers at this stage, but rather the idea behind specific mechanics. Exact numbers are polish, and should be left for later.
5) Take (or scrap, nothing ever wrong with scrapping) the prototype and build it out into an actual mechanic.
6) Identify the next-most-important design aspect of the game and repeat.
To assist with this, I use a development organization style I call the tier system. I divide up my design into tiers of importance, the lower ones being core mechanics, the higher ones being less important. This helps me decide what to focus on next.
Tier 0:
Turret maze prototype. The ENTIRE game hinges on this working.
Tier 1:
Gun prototypes (different types of guns)
Turret prototypes (different types of turrets)
Enemy prototypes (different types of enemies)
Tier 2:
Construction interface prototype
Tier 3:
Refine enemy types
Refine turret prototypes
Refine enemy prototypes
Tier 4:
Refine player movement
Refine construction interface
Tier 5:
Overall polish
I also, usually, make a tier list for the software engineering side for each task in the design tier list that helps determine how to implement it.
This is a rough guideline to help me make a roadmap of my iterative design->development process. At every tier, I re-evaluate the entire design to see how the pieces are fitting together and redesign mechanics that I feel are becoming clunky. For instance, maybe implementing very fast enemies was really cool, but exposed that it's too hard for the player to move around the maze efficiently to fight them. Solution? Let the player build teleporters at strategic points along the map. This lets you fix problems at the crop up, and identify what changes caused the problem in the first place.
