Now what I know about computers can be summed up as: "What you guys and Wikipedia tell me." but this (probably authentically accidentally publicly posted but no less germane to this here post if it isn't) Google employee rant struck a chord with me, once I sifted through the technical jargon.
The gist of the thing--which I do dearly hope I'm getting right--is that each little part of Googlecorp has been focusing on building ace products that work, rather than on building "platforms"--that is: architectures that anyone inside or outside of Google can use to make their own products that are Google-compatible.
His example is (don't groan yet) Facebook and Farmville. Basically: Facebook did not anticipate Farmville (the current most popular computer game on Earth, literally, I have heard), but they made their code architecture available so that a thing like Farmville was possible.
i.e. Rather than anticipating all possible products and trying to outcompete everyone to find the next product, they built their product (Facebook the website) on a platform (Facebook the platform) which products like Farmville or Mafia Wars could be designed to fit on top of and shared that underlying architecture. And they did this by assuming from the beginning that the architecture they were going to build Facebook on would be transparent.
Probably by now you're already anticipating the first point I'm going to make: D&D is a platform. Third parties have been able to design their own products and "products" (noncommercial things like custom encounter tables for strictly local use) for RPGs since day one.
What I'm thinking about here are some ideas brought more closely into focus if you look at D&D, and RPGs in general, as platforms:
-Every time you hack D&D instead of writing your own game from scratch, you are essentially acknowledging the usefulness of D&D as a platform. Either because it works or because it's so popular that it's easy to get a group together or because you're too lazy to shop around or whatever. Point is: this is one of the keys to it being around.
-WOTC: What makes 3.5/Pathfinder not just a philosophical stepping stone between TSR D&D and Type IV is that 3.5 seems to represent the last time the people at WOTC thought of D&D as a platform. D&D Type IV, is, as I have said, fun. However, its hackability and extendability are compromised by:
*The third-party license problem (which, actually, is the least of it, and largely none of my business)
*The complexity involved in building monsters. This was already kinda nuts in 3.5 for DMs who (unlike me) were not willing to just throw feats, skills, and "yes-that-+5-attack-bonus-is-teleologically-justified" out the window. It's not that it is impossible to build the monsters with simple math--it's that it takes a long fucking time. Here's Jeff talking about how "building opposition was a chore" in an abandoned 3.5 campaign (and if Jeff Gameblog can't on-the-fly something you know it's a mess). In TSR D&D you can just go HD 6 AC 7 Atk 2d6/2d6 and you got yourself a foe.
*(Insidious and maybe beside-the-point corollary of point above:) It takes so long to build an according-to-Hoyle 3.5 or Type IV stat-block that it seems to trick many product designers into thinking they've provided a lot more content than they really have when they give you a monster.
*Though skill challenges can be cleverly designed and thought-out--they have to be in order to work. Although Type IV is designed to be "easy to DM" and it probably is in many ways, it isn't easy to make a skill challenge fun. Once a situation is re-designed as a skill challenge it takes effort to back-engineer it into a situation again and figure out what other ways could provide tension and meaningful challenge. This problem doesn't occur in a situation where a situation is just a situation.
-Platformyness isn't just about making a game hackable (all games are hackable) or about Open Game Licenses (even without them, nothing's stopping you from sharing tools with your friends or with GMs online. Unless you're playing Palladium games.)--it's about making that hacking so easy and fast that the usefulness of the game as a platform is as meaningful as the usefulness of the game as IP.
Savage Worlds seems to have gotten this idea, D20 has this idea, GURPS and Rolemaster were built on this idea--but Warhammer and WOTC seem to want to go a whole other way.
-Vornheim is a platform product--it's a thing, but it is also a set of (hopefully) transparent tools for making things--and when I keep saying I hope I don't have to write another RPG book because I hope other people look at it and make things like it, that's what I mean. Things plus platforms that can be used to make more things. Thought about in that way from the beginning.
"Half and half" books. How many times have you read on some blog about a nifty subsystem buried in an ancient module for a game you never saw? Why not explicitly design the thing that way: here is the thing I thought up, and here are the tools I used to think it up or extend it.
Since we know that hardly anyone uses these things right out of the box anyway, why not start out assuming a toolkit of extensions is step one in helping GMs use your module?
-Modularity is not exactly the same thing as platformyness but it also seems to be an idea implicit in the way we handle game stuff that seems like it could be more explicit in the way adventures are actually put together--by companies and individuals. "I took the pygmy trap from Mountain of The Devil Peach and I took the three-headed ghost from Wheel of Unexploded Fungi and..." well if we all know this is going to happen, why not put together dungeons and adventures as if we knew that to begin with?
Write a little something about why tab A goes into slot B and what you'd lose if you moved them around. Sometimes nothing, sometimes something--if you know your dungeon's going to be hacked, talk about the hacking opportunities. Make the design process transparent.
You don't lose anything by explaining that the pool is in front of the door so the rust monster has a natural barrier between it and the needle-mice. If a distinct area can be completely lifted without interfering with interactions in a module, point it out and graphic design the thing overall so it can be easily chopped into parts.
-Half the time you see a new table or chart on this blog it's because I went "Ok, for my next session I'll need a fortress--hey why don't I spend the amount of time I'd spend designing that fortress adventure making a little subsystem to generate fortresses." This isn't always the best approach but when I do it that way it generally works out--the brainstorming I do to get the entire table might give me ideas I wouldn't have thought of if I'd just been focused on building one location. And, naturally, it saves a lot of time down the road.