It’s time for me to think out loud about the game document as an application. All this talk about electronic books and manufacturing buckets and so forth has me thinking that practically every instance of the electronic book is at least as flawed as the paper book in some way or another. See, what the book does right is convey the content via efficient and effective use of the medium. What the electronic book does so far is attempt to mimic the book or extend it incrementally.

Seriously, an electronic device with gigabytes of space a millions of cycles per second and the best we can do is pretend to be a four dollar book? Fuck that.

Exploiting the new medium — a handy computer that does stuff besides display “Hello world” — is going to take some serious innovation. This is not a matter of making new standards or writing books using them or any of that. Real, serious changes to use the machine to do what we really want to do.

See, the game text is a compromise between what the author wants to do for the end user and what the medium is capable of doing. So when we make the machine pretend to be a book, we adopt the same compromise that the author has made for almost 700 years. I think maybe we can do better. Moore’s law, applied since 1450 or so, suggests we can do astronomically better.

What the author wants to do would, in my industry, be encapsulated in a requirements document. We don’t generally do this for books because the compromise we accept cuts so very deep — there’s just not all that much we can do. By contrast, when developing content for a computer, you want to start with the assumption that we can do anything. So now we have to constrain to what we want to do.

So what kinds of requirements would a role-playing-game-delivery-application (usually a book but now released from these bonds) have? Well, a place to start is a little use-case analysis. Here are our users (assuming a traditional RPG structure):

• all players
• non-GM players
• GM players
• readers
• reviewers

Yeah, see, even at this early stage in the analysis we already see that we have vast possibilities open to us just be acknowledging that we can be different things to different people. So let’s look at the most function-rich (I’m guessing!) user — the GM. What does he need this document to do?

• Display rules that are in the context of the current action at the table
• Search for a rule by keyword
• Display action-relevant information for each character
• Display action-relevant information for NPCs and monsters
• Adjust resource elements (fate points, gold pieces) for all players and maybe the environment
• Roll dice
• Display and modify campaign notes relevant to the action at the table and upcoming action
• Record table audio and video
• Convey private information to players (and observers?!)

I could go on. But starting with the assumption that we have a general purpose computer with audio-visual capabilities, a network, and some storage, we find the doors blown open on “what is an RPG if not a book?” As a GM I should be able to award fate points (in secret and in private), get updates based on player activity (“I am tagging ‘Zany funster’ for +2 because I’m just so awesome to be around.” click and fate point tallies on all machines are updated), see what aspects are begging for compels (maybe literally — a player might flag an aspect as a fun thing to tweak and the GM can respond to that red flag). It’s packed with back-channels that are both in and out of story.

So this is what I’m working on right now — what are the use cases for a Next Generation RPG Delivery System? Then after that will come the requirements proper. Then a design. And then I start developing iPad applications? Maybe.

I better go buy some books on that.

–BMurray