Quote:

Original post by krez personally i consider it a serial killing game :)

That is the beauty of Fable. It is a different game for different people (or at least two games: Good and Evil).

Hmm, maybe I should rent an X-box and Fable next week. Anyway, a lot of these suggestions have been very useful, I'm impressed with how helpful everyone's responses have been so far! :) Keep up the good work, if we get enough material here I'll compile it into a journal entry on how to design gameplay.

Quote:

Original post by N8dunn it might be an ass-backwards way to go about it, but why don't you imagine a session in the game? think about how you envision it being played, and then pick out the key elements that you need. once you have that, you can break it down into subelements.

I second this. A vital part of any design document is the 'five minutes of play,' preferably with concept screenshots and the like, to give the reader an idea of what it would be like to actually play the game. And there's nothing that says you can only have one - you could have an entire section of your doc with six gameplay extracts spelled out, totalling a full half-hour section of the game. Provided you don't chose extracts that are too similar, you can demonstrate all the core aspects of the game.

As far as formal theory goes, I recommend Game Design Workshop - it's written by the people who run the workshops at GDC. They break a game down into two groups of elements - formal and dramatic - and then break each of those sets down into individual elements. I can't remember it all offhand but their formal elements were something like: Players, Procedures, Rules, Objectives, Boundaries, Confict, Resources, and Goals.

To be honest, though, it doesn't really matter. How about an 'Agile Development' approach to your design doc - just get all the material written down, and then 'refactor' the way the information is grouped and laid out later on?

Quote:

Original post by N8dunn it might be an ass-backwards way to go about it, but why don't you imagine a session in the game? think about how you envision it being played, and then pick out the key elements that you need. once you have that, you can break it down into subelements.

I don't think this is ass-backwards at all - I think it's essential to have some kind of vision of the gameplay, and how it is to be played as early in the development as possible.

I also find it quite helpful to start writing a usermanual/tutorial well before even starting the game. You'll quickly figure out which details you need to spend more time thinking about, and it will force you to put pretty much *everything* down in order to make it understandable to a newbie. If you just write it for yourself, theres a risk you'll leave important yet seemingly trivial stuff in your head which you may well forget about later.