Once upon a time I asked myself why there wasn't a Game Designer's Toolkit that actually took this "theory" stuff about role-playing game's and put it to use for practical game design.  Eventually I sat down and kind of wrote something like that when I decided the only "game theory" worth a lick of salt was something that applied to practical game design.

Years past.  The file lay all but forgotten on my HD until, while reading messages, I was reminded of it.  It seemd so incredibly relevent at the time.  After all the only way to get actual play out of a game is to design a game, and before you can design a game you really need to know what a game is and how to construct one.  Right?

Well I just created a new PDF of the article, which you can find a link to in this post or grab it directly from here if the Forum will allow a hotlink.  It may be laughable, after all this was written nigh on 3 years ago, but what it is is free!  You like free stuff don't you?

So D/L it then let me know what you think.

I always thought about writing a Game Designer 101 myself, but I never managed to actually sit down and write such an article.

Nice work, especially as there aren't elementary articles as this. (The RPG design patterns and Costikyans "I have no words" would come closest.)

However, let me point out a few points I feel that should be critizised.

First, you have a lot of emphasis on the fictional level of the game world. It is fine to think about this one, but the meta level shouldn't be underestimated. What do the players do? Where do they get there fun from? What are the nifty mechanics? That's a thing that's often forgotten about and assuming "RPG as a RPG is" without thinking about different approaches to gaming, connection of mechanics and fiction and what not. (Vampire should be the prime example for what happens if this point is forgotten about - you end up with a cool idea, the wrong system chassis and no rules that help you to accomplish what you envision to happen.)

Second, you assume the classical GM/player-diversion. Neither that this diversion is inherently bad, nor that I'm a big fan of forgy GM-less games, but this is a point where unspoken assumptions often spoil a game. Some games would profit from a revision of this division of labour. Doesn't have to be the one extreme or the other - even a minor tweak as the combat scene description rights from 7th Sea can do a lot to further your goals.

Third, get your concept really clear and well-defined before you start any actual work on the design itself. Know exactly what you want to accomplish, and focus strictly on that. Without a clear idea you'll end up going all around the houses, sounding a bit like this:
"Swords do 1d6, axes do 1d6+1 - that's to unbalanced. Better beef up the sword to 1d6+1. Oh no! Now swords chop wood as well as axes! That's need to be reworked! Better add a wood-chop modifier to it... Oh, now are axes to overpowered! That's tactical uninteresting! Now add something to the sword again!" etc.
Knowing whether you want an emphasis on tactics or realism, for instance, would help you to overcome such rules-bloating struggles and keep focussed. (It happened to me more than once with my homebrews, and it can really mess up a game if it creeps into everything.)


There would be more stuff to add that's often made wrong, as the role of reward systems, but if I started to get so molecular you'd end up with a 200-page 101.
However, there are some points that I think that should be added:

Don't write a game system for the sake of writing a game system
Too often I see someone coming up with a cool setting and slapping a half-baked not-even-a-heartbreaker-system onto it. If all you want to do is to write a setting that doesn't really demand a new system, than look for an existing one. There are enough that can be used without problems - d20 if you want something tactical, Forge stuff as The Pool, and billions of standard ones as Risus, Savage Worlds, GURPS, BRP, Wushu, Fudge... Some of them are even to get for free and allow you to incorporate them directly into your game text. No one needs yet another realistic/tactical/storytelling/narrative/who-knows generic system just to play in your setting.

Know what the PCs do
A cool setting isn't enough. There must be a reason to get out of the bed and do something, something that makes the PCs go 'round, team up and experience adventure. This might be as simple as mercenaries for hire who go the dungeon or as blurry and sophisticated as the culture clash in Glorantha - doesn't matter how. What does matter is that there is something to assemble a coherent core story.

Get feedback early and constantly
In 1987, you had no other choice than to sit in your basement and tinker alone around, with the only feedback coming from your fellow gamers.
In 2007 we have the internet, so make use of it. Go to the forums, present your idea, ask for ideas, alternatives and criticisms, and make use of it. Twenty eyes are more likely to point out mistakes, give valuable insights and make you notice existing similar games than your own two eyes alone.

There are definitely more points, but these are three easily avoidable mistakes I see repeatedly done.

Skyrock,

That's some great advice near the end of your post!  And I agree the document does need to be dusted off and expanded.  At one point I started to do just that and ended up writing my AnyBook RPS (you can download it from my Yahoo Group) and since then, well, you know how it goes.  Good intentions and all that twaddle, which leads nowhere.

Of course there's probably a lot that the article, which was never really meant as a step-by-step guide to creating a game, would touch upon if I were to write it today.  Not the least of which is what a designer intends players do and how they should go about making it possible for players to do it.  As for mechanics, now that I think about it, that's really more what the AnyBook RPS document touched on.  It's been a while since I've checked to see which version is up at Fantastic Creations but it should be somewhat complimentary to the GDT.  

I also endorse the notion that a designer needs to "get your concept really clear and well-defined before you start any actual work on the design itself" as that's going to be the blue print for the game you build.  That's why the Fantasy Heartbreakers are so common, they're relatively easy to conceptualize and thus designers can knock them out a lot quicker than, say, a space-opera themed game.

Anothe good point is "Knowing whether you want an emphasis on tactics or realism" but even of greater import, I think, is the problem of "rules-bloating" in some systems.  I say KISS, or at least try to.

But the most important of all the things you've mentioned, and as someone who's tackled the whole "playtest" phase of development and come away totally despondant is. .

Quote from: SkyrockGet feedback early and constantly

Developers thrive on input.  Without input our games tend to stagnate and, worst of all, if we don't have input we start to second guess ourselves and decide that, maybe, this wasn't such a good idea.  Or even worse assume that a lack of feedback means we're doing GREAT and thus we continue plodding along creating a mangled mess of a game without realizing it.