Hey there everyone,
I've been having a hard time completing an idea of mine for a game. The general idea is pretty simple, but i have to make a detailed, complete "instruction manual" on how it would work. However, it is quite hard, especially doing it by myself. How do you guys do it, to complete ideas after you have the "epilogue"?

[Edited by - Little Coding Fox on September 7, 2010 10:51:13 AM]

Quote:

Original post by Little Coding Fox i have to make a detailed, complete "instruction manual" on how it would work

Says who? If you've got some ideas, the next step is to prototype tons of them, so you can try to find what works, and throw out what doesn't.

Post your idea here, and let people grill you on the details. If you can successfully answer everyone's questions, I believe you'll be good to go.

You can try to imagine yourself playing the game. What are you physically doing - clicking, pressing buttons? Are you fighting one or more opponents? If so, what are your opponents, what so you have to do to defeat each one, how long does it take? Are you acquiring and spending resources within the game? If so, what are they, how many, how fast. What do they look like in the game before you get them? What do they look like in your inventory? Do you have to go somewhere or talk to someone to spend them?

Quote:

Original post by Little Coding Fox 1. i have to make a detailed, complete "instruction manual" on how it would work. 2. How do you guys do it, to complete ideas after you have the "epilogue"?

1. No. You don't. A GDD is necessary in order to develop a game, not an instruction manual. A GDD is a description for the developers of how you want them to make the game.
2. Sit down and write. Read http://www.sloperama.com/advice/specs.htm

Quote:

Original post by Tom Sloper 1. No. You don't. A GDD is necessary in order to develop a game, not an instruction manual. A GDD is a description for the developers of how you want them to make the game.

Well, that's what i meant, i added the quotes to 'instruction manual' since i meant that as in, very detailed GDD.

Quote:

Original post by Tom Sloper 2. Sit down and write. Read http://www.sloperama.com/advice/specs.htm

That's also what i've been doing, however i have a hard time in some parts of it, which is why i created this thread to see what do you guys do when you're half-stuck someplace on your GDD.

Quote:

Original post by Cygnus_X Post your idea here, and let people grill you on the details. If you can successfully answer everyone's questions, I believe you'll be good to go.

I was originally thinking of doing that but since it is quite a long write i didnt want to bother anyone with my idea. However, i think i'll do a new thread to do that.

@RDragon: I was originally doing that but i spent too long writing the tech and not the game itself. I'm going to give it a shot and make some prototypes with Ogre as my renderer so i can skip most of the tech.

@sunandshadow: Well, it depends on the game type. E.g., in this case the game will be heavily based on player-created worlds and therefore i dont have a "fixed" world to focus on.

I have found the 80/20 rule to be a good guide.

This is that you will only eveeer get 80% of something completed. In game design this is because during production there will always be unexpected things crop up.

The other thing that has helped is to not aim for a complete design, but increment the designs over time.

I will start off writting some sketch notes that are ideas I have had for a game. This can just be thoughts I have had on existing games, ideas I'd like to see in a game, or even just random things that inspire me (eg: Photos, stories, blogs, etc). The idea here is to not restrict your ideas at all, and let your imagination have complete free reign.

The second part is where I start to consolidate the general idea for the game. This will involve throwing out a lot of the stuf you collected as partof the first part (and by throw out, I don't mean delete it from your computer or chuck the paper it is written on in the recycling bin). What you do is try to identify the general concept of your game and remove anything that is not imediately necesary for it. Usually this can will only be one or rarely two paragraphs (and somtimes onlt a single sentence).

The thrid step is to start an actual Design Document. In this you will take your general idea and start to be more accurate in the description. However, even at this stage don't go into too much detail. The aim is to express in general terms what the player will be doing (think of these as verbs) and what the player will be doing this with (nouns).

The forth iteration is where you start to fill in the details of the actions and nouns (think of this stage as the ajective and adverb stage). IF you game includes guns, then you will start to specify what guns they might have, but stear clear of specifying any values (so no damage values here, but you will want to know what sort of guns the player will be having). It is about specifying what the game play role is.

The fith stage is where you make a first pass at the values needed for the game. BUt this is only a first pass, so don't be too concerned about getting the ballance exactly right.

The sixth stage is getting the basic prototype up. This might be a pen and paper mock up of the game system, or it might be an actual software prototype. It is here that you need to work out if the balance of the game and the feel of the game is to your likeing.

The seventh stage is where you start to develop the game based on the prototype and this is usually seen as the typical Game Development phase.

The eight stage is about pollishing your game for release (even if this is just a free releaase or just for friends). This should be bug fixing and making sure that the game can be packaged and installed.


Now, I know that a lot of programmers will want to add in more steps for the actual coding of the game, but this is about game design, not programming.


Another thing is to understand what gameplay is. THere are many different ways you can come to an understanding of gameplay, and each is dependent on what you think game player is.

I use the idea that gameplay is what the player experiences (does) as they attempt to overcome the challenges in the game.

This is because of the model of games that I have found useful. Games can be seen as the result of what is termed a Magic Circle (wikipedia link: http://en.wikipedia.org/wiki/Magic_Circle_%28virtual_worlds%29), where what is inside the circle (game) is given special meaning only in the conext of the game.

When you use this model you need to specify what exists within that circle and only these things can have meaning within the game. Because of that, any thing that exists in the game (including gameplay) must orriginiate from these components.

The composnts are actions and content (you can see how my design system uses this as Verbs/Actions and Nouns/Content). The actions are the rules of the game, and it is the interactions of rule with rules and content that create the challenges. It is the player's interaction with the rules and content that allows the (give the the tools so to speak) to over come the challenges.

I also use the term "challenge" rather than "Obstacle" because a Challenge is an intentional obstacle where as an obstacle can just be unintentional.

This description of gameplay has, for me, been a very powerful tool for designing games as it allows me to identify and thereofre focus my efforts into giveing the player a better gameplay experience. It also is, as far as I ahve found, to be a very good description of what gameplay is. I have not found a single example that cotradicts this description of gameplay (nothing that have been called gameplay by players is not covered by this, and nothing that isn't called gameplay by players is included in this description.

Thank you Edtharan, helped me out clarifying things about GDD and gameplay.

I go through spells of extreme enthusiasm and torrents of new ideas ... then periods of nothing. Whenever you can- write them down! I work at a Walgreens and have written short descriptions on receipt paper, drawn rough sketches on paper from our office printer, texted a friend of mine ideas, or made notes on my phone.
Actually, a LOT of my ideas have formed while at work because I perform such mind-numbingly monotonous actions half the time I'm there. So I think about how a monster would look: why would it have this? What function does that serve? Would it function effectively if it were a real creature? (Huge horns would weigh a lot- would look unrealistic. They could also create blind-spots in its vision, etc.) How would it attack? (Or motives for characters, plot holes, reoccurring elements or themes, ...)
(Trying to visualize EVERY detail like Sunandshadow said really helps.)

When you're out of ideas (as Edtharan said) watch similar movies or play genre related games. Most importantly though; read. Read a lot. I'd say roughly 80% of my "game" is still in my head. It's formed MUCH better than it was around ... 9 months ago when I started, but I've spent hours reading books and websites.
Just write what you can, when you can. And seriously, check out Tom Sloper's site. Write up a concept paper too. Have one specific idea for ... your hero's back-story?; create a new Word document and write as much as possible in it. When you're out of ideas, go back and read what you already have. Perhaps you dislike the idea now, or you've discovered a way to improve on it, maybe rereading it may inspire you to work on something else now.

I actually like to start with a prototype. The design doc at this point will be no more than a post-it's worth of text.

if the prototype shows some promise, then it's worth writing the doc and developing, if not it goes in the 'ideas vault' for possible future reference.

I would never write a full massive detailed design doc without testing the idea somehow, otherwise you've put all this effort in and it might turn out to just not be fun.. the prototype will be less effort in the long run, if you find the right method to do it (paper or code)