next »

[gunswordfist]

How do you personally do it?

[rotten_tater]

Well, if I'm just starting the game out in the idea/design phase, I focus on the one or two mechanics that would make it special or stand out. Other times, I draw out the idea and simply make design choices from the start instead of worrying about them down the road.

If I'm a long ways along, I let the vision grow out of what I already have done. So instead of making new enemies or mechanics, I further explore what I've already made. It's easier to do, and I generally come up with the best gameplay this way.

I guess I've had less of a vision in my work and more of a feeling. If I do have a vision, I try to keep it pretty flexible so I can actually get the game done.

Your question was a little broad, but I think I was close.

[AndroidScholar1]

I write a game design document, and my brain generally thinks out all the potential problems and tidbits whilst I'm doing it.

For example, I started out as a very crap idea that went in my head as "SHOOTER WITH LOTS OF OPTION AND AN INNOVATION ON THE 2D SHOOTER SCENE" that when I began to write down is so far an 11 page document, and that's only a bit of the story and explanation on the game features and mechanics.

Thinking out the individual bits before hand and writing down the pro's and con's of various approaches to them can help save time later on as well - another example being in a base-building game I'm making where I expanded on what I could do with the concept of "building barricades". I went through several approaches ranging from "click -> building is barricaded" to "static locations in some streets can be barricaded", before finally settling on "click any point on any building wall and connect it to another to make a barricade that spans between the two and gives a feeling of immersion and progression through visual diversity".

I love design documents.

[PlayMeTape]

I don't. Probably should though.

I'm not so good at sitting down and making design documents, I'd rather just get on with it. The idea typically evolves and changes a lot during development. If I come up with something I like I often drastically change the entire gameplay mid-development . For the smaller type of things I'm currently working on I think that works.

But it may present a problem in the future.

[TobiasW]

Bouncing the idea off friends

[CYS]

Basically i just start programming the core mechanics of the game and playtest it tons of times until i got the feel of what im aiming for. In other words, i dont plan at all.

[rotten_tater]

I'm not so good at sitting down and making design documents, I'd rather just get on with it. The idea typically evolves and changes a lot during development. If I come up with something I like I often drastically change the entire gameplay mid-development . For the smaller type of things I'm currently working on I think that works.

I generally don't make design documents either. Only time I make plans is when I need to build engines or other programming stuff (object narratives, etc).

[gunswordfist]

Well, if I'm just starting the game out in the idea/design phase, I focus on the one or two mechanics that would make it special or stand out. Other times, I draw out the idea and simply make design choices from the start instead of worrying about them down the road.

If I'm a long ways along, I let the vision grow out of what I already have done. So instead of making new enemies or mechanics, I further explore what I've already made. It's easier to do, and I generally come up with the best gameplay this way.

I guess I've had less of a vision in my work and more of a feeling. If I do have a vision, I try to keep it pretty flexible so I can actually get the game done.

Your question was a little broad, but I think I was close.

No worries. I made it broad on purpose. Thanks for contributing.

[LemonScented]

My head generally contains a small gallery of screenshots of the game I'm making, maybe half a dozen at most. Sometimes they are more like short (< 5 seconds) video clips, sometimes just a single image. The brain-screenshots are not high-res print quality, but they might give an idea about graphical style, colour palette, some of the things that might seem likely to find in the game. Certainly they imply genre, and although it might not be a genre I was previously interested in, I will dance to that tune, research the genre, work out how to construct that image.

I try to bring those images into focus, work out what they mean, find better ways to describe the pictures in my head to other people using words, try to figure out what sort of game would generate those images. Eventually I can point to something I've got up and running on screen and say "That. That is what I have in my head. Except maybe without the placeholder graphics", and it gets easier. The more there is of the game, the less I have to explain, and the more I can focus on just fleshing out what's already there into what it should be, filling in the blanks.

[The Monster King]

i take a shower and bam they just keep coming, the ideas

so many

so good

gotta... gotta macker game

[TooMuchSpareTime]

Restriction breeds creativity, and I often tend to let technical limitations determine the execution of my concepts. I know that making compromises like that is a terrible way of doing it - especially if it conflicts with a design brief from your boss or whatever - but I do like a good surprise ending, even if it means I end up with something other than what I set out to make.


(Yeah, very often the ending is failure. But something new is always learned.)

[gunswordfist]

My head generally contains a small gallery of screenshots of the game I'm making, maybe half a dozen at most. Sometimes they are more like short (< 5 seconds) video clips, sometimes just a single image. The brain-screenshots are not high-res print quality, but they might give an idea about graphical style, colour palette, some of the things that might seem likely to find in the game. Certainly they imply genre, and although it might not be a genre I was previously interested in, I will dance to that tune, research the genre, work out how to construct that image.

I try to bring those images into focus, work out what they mean, find better ways to describe the pictures in my head to other people using words, try to figure out what sort of game would generate those images. Eventually I can point to something I've got up and running on screen and say "That. That is what I have in my head. Except maybe without the placeholder graphics", and it gets easier. The more there is of the game, the less I have to explain, and the more I can focus on just fleshing out what's already there into what it should be, filling in the blanks.

I have brain screenshots that imply genre too. I haven't gotten to the put it on the screen part though.

[eclectocrat]

obsession.

[ஒழுக்கின்மை (Paul Eres)]

by making it and changing it as i go along; it's more difficult to refine your vision for a game when the game doesn't exist

[namre]

As for me, I first try to explain the game to others. This is where flaws in my ideas begin to surface as I break the idea down to pieces for explaining. This is made more effective if the person I'm explaining it to asks a lot of questions and is interested with the idea.

I don't usually make a design document. But I do place them on my whiteboard. I break down the game idea into little sections that are important to the game.

After that I test it out with a prototype and change as I go.

[ink.inc]

http://www.lostgarden.com/

There's an essay here on the "culling" process that you folks might find particularly useful. Actually, pretty much everything on this site is useful.

[Musenik]

I start with describing the experience I hope the player will have. Distill that down into a sentence or two, and stick with it. In creating arcada mia, I tried three other core mechanics before settling on 'back and forth tactics', to drive the experience of 'living in an Edward Rutherfurd novel as successive generations through history.'

While working on the game, lots of features spring to mind, and I write them down, but if they don't support the experience statement, they get iced. Others get iced simply because I can't fit every appropriate idea into a game and ship it. Already I feel like I'm tackling too much. Three major features and several minor ones remain to do on the main list. Then there's the six pages of tweaks and nuances... we'll see.

Refining a vision means identifying that vision and creating it but no more.

[AndrewFM]

by making it and changing it as i go along; it's more difficult to refine your vision for a game when the game doesn't exist

This. There's no better way to see what things work well for your game, and what don't, other than actually playing the game for yourself. Your game will naturally shape shift into its ideal form the more and more you play-test it.

The most important thing is to allow those changes to take place. Don't let your biases or impatience stop you from throwing an old idea in the garbage, or making something brand new. It's a necessary step in refinement.

[dantheman363]

Putting out prototypes and getting feedback on what is fun and what is not fun.

[Taiko]

Putting out prototypes and getting feedback on what is fun and what is not fun.

Absolutely.  Get your game out in front of someone as early in the design phase as possible.  You'll discover problems with your UI, programming bugs, art/sound pieces that aren't really working, but most importantly whether or not your core idea is fun.  The only way to tell if your game is enjoyable or not is to let other people try it out.