How do I go from a general idea to a specific draft of a design?

Question

Before starting planing your code, the data structures, the class hierarchy, you need to have a clear idea of what you want for your game.
I came across with an idea for a game, but it is too general.

I think every game starts with a general idea, but how did they take that general idea and then the came up with games like Imperium Civitas... I'm refering to the actions you can or can't do, the events, in-game materials etc.

I wonder how you should engage a blank paper. Where you should start? Is there a chain of steps that you have to follow? Thanks.

(My idea is much more simpler than Imperium Civitas)

Answer 1

My advice would be not to try to delve into too much details yet.

Get a general feel of what type of game you want, with a core gameplay feature that you really want.

Once you know what the main gameplay will feel like, start coding. In my opinion, it's very important that your whole idea at first is simple. Don't start and try to make something very complicated with complex gameplay and content. Start out small.

An example of this would be if you wanted a 2D platformer with the core gameplay element being magic spells for the main character. What I would do is I would go progressively through it, like so:

• Create quick and dirty placeholders for the level tiles (i.e. don't build too much content yet, avoid spending too much time on art and don't make too many assets). So, say, start out with some very simple blocks.

• Make a level system, which you load in the code at first.

• Allow the level to be loaded from a file (to make it easier to test).

• Add a main character.

• Implement physics for your character (tile collision and gravity).

• Allow the character to move and jump.

• Add very basic spells.

• Add enemies, make a level editor, replace placeholders and add content, etc.

You see, you follow a path where you add new small things everytime. Not only does it keep you motivated because you can feel your progress but it also prevents you from falling into the trap of wanting to implement so many complex things at once and getting lost.

TL;DR: Get a general feel of what type of game and core gameplay elements you want (but make sure that they're not too complex) and simply start coding, by making sure that you don't delve into too much details at first. When you have your working prototype, you'll know what you want in your game, since you'll have something to work with. From there on, keep coding!

Answer 2

(I'm an amateur)

For the two games I completed, I started with a simple but fixed idea for the gameplay. This first idea wasn't necessarily good, but it was doable, and not too difficult. Once that was completed, I thought of different directions the gameplay could go that might be better, and started trying them out. In both cases, many of the things I tried proved to detract from what was fun about the game, and I ended up discarding them. This was necessary -- no feasible amount of planning can ensure that the idea is good without actually trying it.

The key for me was to have a working and "complete" game, even if it's simple and/or not fun, and once that's done, to try other things. It didn't matter if the original idea was the best.

This is probably not the way professional studios design games, I imagine that they generally come up with a complete design doc and follow it, and it either proves good or bad. That's not to say they can't reuse their code or experience in another similar game, but I imagine it's less flexible.