What is a design and what is an idea?

Tony Richards asked this in a post on the Indy Zen forums:

I’ve been confusing “Game Designs” with “Game Ideas” for many years… and they’re definitely not the same thing.

But what’s the difference? Being a fledgling game designer, I don’t think I’m qualified to answer that question… anyone else have thoughts on the topic?

I’m also an unqualified amateur, so take the following with a grain of salt. It seems that there is a whole continuum of what people call “design”. For some, they hash out some loose ideas and it becomes a “design”. Professionals, or would be professionals, write a comprehensive design document. There is a nice article over on Gamasutra defining what a design document is and another nice one about how to create one. If you are not keen to maintain a single document, you’ll still want asset lists and level walkthrough documents.

The problem I have is that the design documents that I’ve seen don’t really look like “design” to me. They look like collections of ideas; bullet points, checklists . Actually, with my software development experience, they look more like specifications; or even more like requirement documents. This is fine for level design, but what about systems (e.g. ruleset) design? Long ago, I read Steve Mcconnell’s Code Complete. I’ll never be a great programmer, but he did indoctrinate me on the value of design. In my view, design is complete when a programmer can just sit down and bang out the code without thinking too much. In the case of a game, this would be “programmers bang out code” and “level designers bang out levels”. Design is where you think over the hard “how will I do…” bits. Until then, it is just an idea and after then, the implementation can flow freely. Now perhaps the reason that game design documents tend to include concept art, but not comprehensive “how to” elements is for the same reason that programmers often prefer designer not script on large projects.

Still, a UML for game design would be nice; especially for systems.

As far as I know, not much has been done to define a proper grammar. Raph Koster might have in his book, A Theory of Fun. Unfortunately, I don’t have a copy. It is out of print and virtually impossible to source. Luckily, he says that a new printing will be available this summer. I’ll certainly order it when the time comes. Being unfortunately for the time being ignorant of his theories on game grammar, my idea of “design” would be concide and with a very clear “grammar”. A designer should be able to look at it an instantly know what it means. It also needs to be something that eschews verbosity. Anyone who has ever read through a “what do you think of my game design” forum postings and had their eyes glaze over knows all about the nasty, horrible things verbosity can do to clarity. It might look something like the following:

Action

That little thing that looks like a Feynman diagram is an early prototype (and subject to change) Memotica action graph. It has a very clear grammar. There is a subject and an object. The subject is the do-er and the object is the do-ee. They can be the same thing. The funny callout on the arrow link between the subject and object is a restriction on who may perform the action. The callouts on the object refer to all of the conditions that must be fulfilled for the action to be possible. The dotted line is the stimulus that the world sees when the action is performed. And the dashed lines are whatever state changes in the object.