I'm looking for a "process" to come up with a game design -- does anyone have one they would be willing to share? Or perhaps URL/books/suggestions about doing the game design?

Mind you, I'm not looking for stuff like UML. I'd like something that takes your idea for a game and helps you to design the play and story aspects of it -- something to help you evaluate how fun it would be before you even get to the technical design phase.

Thanks
Anthony

Some paper, some colored pens/pencils, and the floor or a table.

This book:
http://www.amazon.co.uk/exec/obidos/ASIN/0735713634/ref=sr_aps_books_1_1/026-0565310-3795614
gives some kind of structure to the process, and migh be helpful. Not as a guaranteed formula for success, but maybe as a tool for you to develop your own process.

I personally don't agree with all of it, but I certainly agree with some. Read it, and pick out the pieces you find useful...

... or just do what Mark suggested; pen, paper and some thinking is really all it takes :-)

We use a white board and at least three different colored pens. :)
-Scorpio

Originally posted by Scorpio
We use a white board and at least three different colored pens. :)
-Scorpio

Hey, I should be good to go then! I have a whiteboard and 9! colored markers!!

Seriously though, I'm looking more for a process than anything else. I don't believe in one-size-fits-all solutions, but I'm kind of at a loss for where to begin. I'm more of a structured type of person; I like to know where path and milestones are, if you will. :)

Mark, Scorpio, when you start working on your game design, what are the steps you go through as you do your "stuff"?

Originally posted by Mattias
This book:
http://www.amazon.co.uk/exec/obidos/ASIN/0735713634/ref=sr_aps_books_1_1/026-0565310-3795614
gives some kind of structure to the process, and migh be helpful. Not as a guaranteed formula for success, but maybe as a tool for you to develop your own process.

I personally don't agree with all of it, but I certainly agree with some. Read it, and pick out the pieces you find useful...

... or just do what Mark suggested; pen, paper and some thinking is really all it takes :-)

Thanks for the link; I'll check into it! :)

Heh, I'm not a fan of ad-hoc processes, and since I'm coming from the business side of the development world I don't have any experience with game design docs/processes. I'm hoping to get some ideas from people who have been there.

Thanks

Originally posted by Justiciar
Scorpio, when you start working on your game design, what are the steps you go through as you do your "stuff"?
Since HipSoft has 3 people, it's always a discussion and not a solo event. I think this helps a lot (especially since we've all worked with each other for over a decade now).

We usually start out by talking about our target audience and gameplay mechanics we think we could use to make a game. We usually focus on a core gameplay element and then talk about themes and modes that could fit well with the idea(s).

Our sessions are usually informal and the result is usually another working title on our white board with a bunch of sketches and diagrams that probably wouldn't make much sense to anyone else.

Also, we tend to validate a core gamplay concept but them make lots of changes to the design as the game is under development. Puzzle Express (which just shipped today! http://www.hipsoft.com/pe.html) was originally going to have a delivery truck theme. We first made a themeless prototype to make sure the core gameplay concept was actually fun when the ideas we talked about were translated into software.

The theme later changed, pictures were added, a second mode, etc. etc. but the core gameplay concept didn't really change...and that's what we probably talked about the most during our initial design discussions. This process has worked really well for us.

This process has also saved us time: We had an idea a while back that sounded good so we spent a day and made a prototype of the core gameplay concept. Playing it on the computer sucked so we scrapped it. This potentially saved us from wasting significantly more time.

I Hope this rambling is somehow helpful... :)
-Scorpio

Thanks, it helps quite a bit!

As an aside, I tried Puzzle Express, and I'm really impressed with it! Top notch production and play values.

When possible, I try to describe the player's experience. Instead of writing a design document where you put all features in categories, you get a document that reads like a walkthrough of the game. Tadhg Kelly describes something similar in his blog: http://particleblog.blogspot.com/archives/2003_12_01_particleblog_archive.html#107129869013127047.

It might seem that this method won't work with a puzzle or arcade game, but that's not true. You can describe how the player is introduced to the different game rules. This way you won't use game concepts that you haven't explained to the player yet. Also, once you have a working piece of your game, you can test if your assumptions are correct; if a player actually does pick up the rule you want him/her to learn at that point.

Once you have your basic idea ready, build a prototype. It's very important to have a working model of your game so that you can test, test, test. Ask someone to play your game. Don't explain anything about it to them; don't tell them the rules, not even when you are planning a tutorial but haven't gotten around to it yet. It's very valuable to see if someone can pick up the game without any help. Redesign the parts where the player is at a loss and ask someone else to try it now.

If you want to see some examples of classic game design documents you should check out Al Lowes' archive:

Al Lowe Game Design Documents (http://www.allowe.com/gamedesign/index.htm)

Here he has many of his classic game design documents from his early days at Sierra. Very good reading.

Also, Gamasutra (http://www.gamasutra.com) has some examples that are very good to get the mind going.

Hope this helps.

Thanks everyone; you've given me some really good places to start!

Both Kelly's and Lowe's notes are interesting reads, and they gave me some really good insight into the game design process and documentation.

Anthony