This didn't really seem to fit anywhere so I put it here in the lounge.

When you start making a game, do you go through planning the whole thing out (story, characters, controls, graphics) in detail or do you just start programming based on a general idea of what you want to create?

I ask because I've been doing the latter and have ended up making tech demos, not games. See, I get the original idea and it seems pretty good so I start programming. I get to the point where everything is fairly well in place. I've got a world loading, the player can control his character and shoot/use powers/change weapons/whatever, enemies load and respond to the player, collisions work, etc. All I need is content creation: building levels, more enemies, and creating a story for the game. This is where I get stuck. The original idea seemed good but I can't seem to go anywhere beyond basic game-play with it. It's really frustrating. I was wondering if it's better to not start work on programming and force yourself to get a whole plot and everything before starting. This, however, is very difficult for me. I view myself as one of the least creative people I know and it's just annoying not being able to go anywhere with my games.

Thanks for your input.

I can't really speak for games, but I try to map out a rough design of the code and features of the software in my head (and maybe on paper if it's particularly complex) and start prototyping/iterating after that. Invariably I'll run into issues (both logical and structural) and will have to redesign parts of the original architecture I had in mind. Then if you keep this stuff in the back of your head when you're not working on it, you tend to think about it subconsciously and eventually converge towards something you like. Which may be very far from what you started with, but it's usually for the better.

In other words, no initial design survives contact with its implementation. So, in my opinion, don't waste your time drawing elaborate UML diagrams at the start, because you'll probably have to modify it quite a bit to get something that works, is efficient, elegant, simple, extendable, etc.. Plus most games (or any software of any kind) aren't built to completion in a single coding run, so you have ample time to make more or less major changes to the code, storyline, or art as you progress on the implementation.

So, yeah, I'd say do a minimum of planning, but don't go overboard with preparation. The code isn't going to write itself, and any extra work you spend perfecting your plan is not going to pay back since you'll have to do it again while developing anyway. Also very important, but apparently many people don't do it: when you run into a deep problem, don't just hack around it. Put the keyboard away and think about what is going on. In these situations you'll usually find that your initial design has failed in some way, and you need to make some modifications at that point.

Now that was from the software design perspective. For the gameplay, I'm not sure how useful a large GDD is but I would assume it is important to at least have a clear idea what you want the game to be about. Most games can start with the concept of a player shooting generic enemies, but a game is little fun without flavour and personality.

When I start a project, small or large I make sure I have a project outlining it, it can be simple at first, but it is very important to research and add to the project outline when necessary.

Researching is important, if you cant do something research into it, break it down and do it. Just as "Make Game" is broken down in many tasks, so is "Make Enemy", you just need to start asking questions, then add them to your project outline, for example, Is the enemy 2d / 3d? How will you upload assets? How will the texture be done? What tool will you use to do the art / modelling? Mid way while working on your enemy you may learn something new like animations / bones etc, you then break that down and add it to the list.

A project is really a giant tree where you can only focus on one leaf at a time, the second you work on one a branch with more leaves might grow. Just make sure your project outline is being focused on and is used to add / remove / extend tasks. When things get tough break down that task and work on the small tasks. One thing I will suggest is sticking to a design you can follow, when projects get large the worst thing you would want happening is being unable to follow your own code because its all over the place

Lol, well, since I am not a programmer and I am a designer, planning first is pretty much the option I have to go with. For me it's more a question of, how complete does my plan need to be before I recruit and/or hire other people to do various parts of the development? Because I myself am only interested in being recruited to projects right at the beginning so I can have a share in the design, or at late alpha/early beta so I can make content to plug right into an already-working system. But other people seems to feel differently, depending on what parts of developing the game they want to do or not do. Artists who aren't designers tend to not give a damn about whether there is any programming, but want reference images to establish style, technical specifications about image sizes and types needed, and a detailed list of what pieces of art need to be made. Programmers who aren't designers tend to want both a detailed description of all the different parts of the gameplay and UIs/layouts to attach their code to for testing and demonstration.

Prototype from the very beginning. Then iterate. So basically what Bacterius already said...

Since putting programming and prototyping first isn't working, then perhaps it would be best to try a different approach. Choose one of your better ideas for a game and just think about it - don't write any code. Think about what you want to achieve with designing the game. Do you want to explore a game mechanic? Do you want to tell a story? Do you want to create an immersive world? Next, think about the mechanics and controls for the game. Is there combat? If so, how does it play out? What moves/abilities can you use? What items/power-ups can you collect? Next, try thinking about the content of the game. What is the setting/era? Who are the characters in your game? What do they look like and what are their personalities? Is there a story? If so, how does it develop? How are the levels designed? How many levels/worlds are there?

You should ask yourself as many of these kinds of questions as you can before even making a prototype. In the early stages of this creative process, I recommend to not even write down any ideas you may have. Many of your ideas will change drastically as you come up with more and more ideas, and over time these ideas will become more solidified. Also, you should give a lot of time to this process of coming up with ideas. You can even work on other projects in the meantime. It might take weeks, months, or sometimes years for larger projects, but at the end of this creative process you should have a fairly solid vision of an original game that you're motivated to create from start to finish.

I have a very loose idea, and I start jumping in and coding it. Usually the idea starts with just a piece of technology I want to make. The game concept forms and changes over time, and so my code has to change, until the concept finally reaches a stable form.

Because I still need alot of experience in higher-level code architecture, I end up re-writing the same pieces of code over and over as the different pieces of the engine don't work together as well as I had planned hoped.