For those who haven't seen it, John Kirk's free book Design Patterns of Successful Roleplaying Games is definitely worth a look for anyone interested in the structure of RPGs.

Quote from: Neel KrishnaswamiDesign patterns are a communication tool from software development -- the idea is that successful projects will tend to have recurring patterns, and that by naming and describing them and the situations that call for their use, we can make it easier to turn tacit, experiential knowledge into a teachable skill.

http://legendaryquest.netfirms.com/books/Patterns.zip

Oh dear Lord, and thus it begins. Presuming the book is a good read, we'll soon be flooded with RPGs that think Design Patterns are necessary. They're a useful tool, but can easily get blown all out of proportion.

Actually, it's been out for a while, yet it hasn't generated very much discussion. I keep meaning to read it myself.

It's a chunky motherfucker.

James M, are you coming from a position of knowing something about how this stuff went down in the software industry? I'd be interested to hear about it.

I read it yesterday before I saw this thread, actually, purely through chance.
Now, I'm no programmer so I can't say I knew much of anything about the history of the idea before I tripped over the thing, but after having cruised through it...  it struck me as an overly complicated, pedantic list of various concepts that ranged from common-as-dirt to derived-from-common-as-dirt that were broken into the smallest pieces possible, and then (mostly) complained about after having gotten the most dry and dissasociated 'definition' available.

Granted, I didn't give it a "Must absorb this fully and fully grok it as a whole" read, so I may have missed something, or focused too strongly on the listed drawbacks of everything.

I R a software engineer.

There's been a lot of smack-talk about the scourge of design patterns, brought on by obsessive "what design pattern fits this" mentality and a host of immitators creating their (sometimes valid, often not) own design patterns.

And yet, GoF remains one of the most influential books in the field; in introducing younger engineers to basic design techniques, I find it and Larman to be "go to" books. Though some of the backlash is justified, I think it's the "silver bullet" mentality that deserves scorn, not the concept of design patterns itself.

Whether or not this particular document deserves the position GoF has in software engineering, I can't say. Yeah, it's mostly a simmering down of basic techniques... but so was GoF. But the gaming field is a bit more artistic than the software engineering field, and I think some concepts may be more elusive to such a treatment.

Basically what Caesar said. I'm currently working o  ajoint project between three entities, my section, a "seperate but equal" section of the same company, and our customer. The "seperate but equal" group started the design on the project and apparently someone in their management gets a boner thinking about using every conceivable design pattern, even when not necessary.

For example, there is a pattern called the Singleton which ensures that one and only one instance of an object can be created. It has some overhead attached, but does what it's supposed to. For some reason though, some people think that if you can't foresee a reason to have multiple instances, you should create a singleton. This adds on the overhead without giving any benefit. Singletons should only be used where necessary.

Another example is a Facade, where you add in a layer of code used only for interfacing some other code. this is a great idea when you're accessing multiple similar modules as it makes the code easier to follow and use. But if you've got one object talking to another you're wasting your time sticking a layer between them.

Basically the premise of patterns is that they give a way to design known problems with reliable and repeatable methods. When a pattern is applied incorrectly though you end up with code that's harder to read, runs less efficiently, and will be a pain in the ass to change when it becomes apparent that the pattern was a bad choice.

My work is in embedded programming on government systems (aircraft displays and missile interfaces). Unlike a PC, where bloatware is becoming the norm, an embedded application means that processor and memory usage is always at a premium. Tossing in inefficiency without reward is a surefire way to force rework later on.

Quote from: James McMurrayMy work is in embedded programming on government systems

Small world.

It's really small if you say you work for Lockheed Martin or (even smaller) EFW Inc. I'm currently working for Lockheed Martin MFC, and spent 4 1/2 years at EFW.

I'm only a little way in, though I'm already detecting a degree of sampling error -- define "successful game" for the purposes of his study.  One of his criteria is whether or not it is being discussed on The Forge, leading to a seemingly unusual preponderance of Forge-born/promoted games.  Since the author is an admitted fan of The Forge philosophy, I find that an unfortunate bias, whether he intended it or not.

More thoughts as I proceed through the individual chapters.

!i!

(P.S. Another problem.  The notion that a "pattern" emerges with as few as two occurrances in separate systems seems flawed.  To quote the infamous Bond villain Auric Goldfinger, "Once is happenstance.  Twice is coincidence.  The third time it's enemy action.")

Quote from: Ian Absentia(P.S. Another problem.  The notion that a "pattern" emerges with as few as two occurrances in separate systems seems flawed.  To quote the infamous Bond villain Auric Goldfinger, "Once is happenstance.  Twice is coincidence.  The third time it's enemy action.")

I have not read the document, but I wonder if two examples are given in the text but many more samples were used when actually compiling the data. It may be a case of being brief. That is, it sounds like the document is fairly long, but would be longer if he'd mention ever single sample he'd used in defining the patterns. It is possible he was just being brief.

Quote from: Jack Spencer JrI have not read the document, but I wonder if two examples are given in the text but many more samples were used when actually compiling the data. It may be a case of being brief. That is, it sounds like the document is fairly long, but would be longer if he'd mention ever single sample he'd used in defining the patterns. It is possible he was just being brief.

No, the author comes right out and says in the beginning of the document that he's required a pattern to have appeared in two unrelated sources to qualify as a pattern.

Well, here's the list of games. Perhaps we could discuss it?

Ars Magica (Fourth Edition)
Call of Cthulhu (Sixth Edition)
Code of Unaris
Dogs in the Vineyard
Donjon
Dungeons and Dragons v.3.5
Elfs
Fudge
Great Ork Gods
GURPS
HARP (High Adventure Role  Playing)
HeroQuest
Hero System 5 th Edition
InSpectres
My Life with Master
Nicotine Girls
Nobilis
Paranoia xp
The Pool
Puppetland
The Riddle of Steel
RIFTS
Rolemaster Fantasy Role Playing
Shadowrun
Sorcerer
TORG
Universalis
Warhammer Fantasy Roleplay
The World of Darkness (including  Vampire: The Requiem)

I dunno, looks like a pretty good spread of games, though weighted a bit on the new/Forge end. From reading some of the book and seeing some of the comments here, though, I think people are getting the wrong idea. That is, it's not like the purpose is to canonize certain games or even to identify which game did X first. Instead the purpose is to categorize types of mechanics to provide a toolkit, reducing the need to reinvent the wheel or at least providing a resource for research (so if you want to accomplish X, you can locate a game that does X already).

I don't know if the author is still planning on expanding the book but the general concept is worthy of extension as people identify other worthwhile patterns.