Most of the problems in Infamousare
result of its sandbox, but there are a couple of key problems with the
main storyline as well, so let's talk about those.
First, by its very nature, Infamous wants to
give you meaningful choice: Do you want to be a supervillain or a
superhero? But it runs into a problem because it also has a story to
The difficulty here is pretty easy to sum
up: Content is expensive. If the game actually diverged every time it
gave you a choice, the amount of content required would increase
exponentially (and so would the production budget). So, instead, the
game gives you the illusion of choice: No matter what you do, the
ultimate result on a macro-level is the same and the next stop on the
plot's railroad remains unaltered.
Which is fine.
What you can do, though, is specifically
color the events of the plot to suit the type of character the player
is choosing to play. This is tricky, but it can be done. Infamous even
takes a stab at it: Every so often the gameplay is shunted into a short
semi-animated sequence that moves the plot forward. Some of these
semi-animated sequences are swapped out depending on whether you're a
superhero or a supervillain.
The problem with Infamous is that
the writers just don't seem to have had their hearts behind the
supervillain plot: No matter how villainous the character becomes, the
game just can't seem to shake the underlying themes of savior and
Fix #1: Develop a meaningful theme and arc
for the supervillain side of the story. Most of the necessary pieces
are tantalizingly within reach: They just need to be realized.
For example, here's the end of the game:
Notice the complete disconnect between the
sequence and the "evil epilogue"? How can you go from "when the time
comes, I'll be ready" to saying "only an idiot thinks I'm going to
bother doing that"?
The fix here is simple: The narrative needs
to explicitly embrace at every level the irony that Kessler's efforts
to indoctrinate Cole have had exactly the opposite result; that the
unspeakable and almost incomprehensible sacrifices he made were all for
More radically, it would be nice if not all
choices were completely meaningless. (It would certainly improve the
replay value of the game: After discovering how completely illusionary
the choices in the game were, I didn't bother going back to finish a
For example, you can watch the death of
both the good
version and the evil
The different outcomes in this case depend on your morality rating
within the game and suffers from the same incoherence as the end of the
game: The fact that Trish, in her dying moments, chose to scorn you or
to love you should have some sort of lasting impact on how Cole thinks
of her. But it doesn't.
In addition, the death of Trish is
couched in a false decision: You can try to save her (evil choice) or
you can try to save several innocent hostages (good choice). But,
ultimately, the decision is meaningless: Trish is killed either way and
the "decision", like so many others in the game, is ultimately trivial
Supporting these variations in the death of
Trish would be significant because this is a key moment in the game and
its impact would be felt in many other places. But precisely because
it's a key moment in the game, a little extra depth here would go a
long way towards enriching the entire experience. (And the differences,
although pervasive, are cheap: A little extra time recording dialogue
and a couple extra yes-no switches in the code.)
Similar changes at other moments in the game
be more isolated than the Trish divergence, and thus easier to
If you ever have the opportunity to write a video game, please avoid
the temptation to include "you have succeeded at goal X in the
gameplay, but now we'll go to a cut-scene and reveal it was all a
failure after all". The discordant gut-punch is not effective. It is
merely annoying. Particularly if you follow the example of Infamous and do it
over and over and over again.)
Last year my one-page dungeon The Halls of the Mad Mage,
inspired by the twisted landscapes of M.C. Escher, won Best Geometry in
the One Page Dungeon Contest. The deluxe version of the One Page Dungeon Codex 2009,
which collects all of the winners, has now been released as a FREE
e-book from Tabletop Adventures.
I believe the 2010
contest has also concluded (I didn't enter this year).
THE HALLS OF THE MAD MAGE
If you like The
Halls of the Mad Mage, while you're at RPGNow for the Codex, you might
also want to check out some of my other adventure supplements:
couple months ago I mentioned
that I had created counter-intelligence guidelines for the Gather
Information skill. Confanity
had mentioned that he was intrigued by them, and I promised to get them
posted sooner rather than later. For certain definitions of "sooner"
and "later", I suppose that this has now been accomplished.
A character can attempt to detect other characters gathering
information about a particular subject in the area by making a Gather
Information check. The DC of the counter-intelligence check is opposed
by the original Gather Information check made in the attempt to gather
Suspicion: If a character is attempting to avoid
suspicion, it becomes more difficult to detect them. Although the
character suffers a -10 penalty on their Gather Information check for
the purposes of collecting the information they seek, they gain a +10
bonus to their Gather Information check for the purposes of opposing
the counter-intelligence check.
In addition, cautious characters can
increase the penalty on their original Gather Information check,
granting an equal bonus for the purposes of opposing the
counter-intelligence check. (For example a character could decide to be
extra cautious and apply a -15 penalty to their Gather Information
check. Their unmodified check result is 30, which is modified to 15 (30
- 15) for the purposes of determining what information they actually
glean. But if another character attempts to detect their presence, they
would have to make a DC 45 (30 + 15) counter-intelligence check to do
Apply a -2 penalty to counter-intelligence checks for every week that
has passed since the original Gather Information check.
PCs, these guidelines aren't only useful to find out if someone is
asking questions about them. In fact, they're generally more useful for
identifying competing interests. Who else in town is trying to find out
information about the Vault of the Dwarven Kings? Or investigating the
Baker's Street Gang?
Resolving these types of checks requires the
know two things:
(1) Who else is
looking for that information?
(2) What should the DC of the check be?
The answer to the former question, of
situational. For the latter you could either set simple, static DCs as
you would for any other Gather Information check, or you could actually
resolve the opposed check.
generally find it useful to know what kind of information-gathering
capacity factions have in my campaigns. For smaller factions (like an
opposing group of adventurers or a small gang of bad guys), this is as
simple as looking at the highest (or most appropriate) Gather
Information skill modifier in the group.
For larger factions, I simply assign a
Information modifier to the group. (This number is essentially
arbitrary, although I base it on the size, nature, and resources of the
group in question.)
When trying to figure out how suspicious a
particular group is (i.e., whether they're performing
counter-intelligence to make sure anyone is asking questions about
them) or how pervasive their surveillance is (i.e., how often they're
making counter-intelligence checks), I've generally just relied on
common sense to make a ruling whenever the question needs to be
answered. But if you're running a campaign where intelligence and
counter-intelligence is likely to be fairly common (for example, a
modern espionage campaign), then codifying those factors might be
(For example, a
Paranoid group might check 1/day; a Suspicious group every 1d6 days; a
Cautious group once every 3d10 days; a Naive group might never check.
In other words, if the PCs investigate a Suspicious group then there
would be a counter-intelligence check made 1d6 days later.)
Dwarves: Oh no! All
the gold in our mountain has been
Dwarven God: That
sounds sucky. Hereís a magical artifact to
remove the curse.
Dwarf 1: Think we
should use it?
Dwarf 2: Nope.
Letís lock all the dwarves afflicted by the
curse into the lower vaults.
Dwarf 1: And then
Dwarf 2: Nope.
Letís evacuate the mountain.
Dwarf 1: And then
weíll use it?
Dwarf 2: Nope.
Weíll hide the magical artifact in the depths
of the mountain.
Dwarf 1: AndÖ then
Dwarf 2: Nope.
Weíll create clockwork bodies for ourselves
and inscribe the secret of how to find the artifact on the gears and
Dwarf 1: AndÖ wait,
Dwarf 2: Then weíll
go senile. And centuries from now the
grandchildren of our disciples will ďconĒ a small group of adventurers
retrieving and using the magical artifact.
Dwarf 1: What the
hell are you talking about?
I guess this is what
happens when you write adventure
modules by committee. (I really wish I was exaggerating this, but Iím
Although they technically didnít plan
to go senile, this is, in fact, the background used in the module.)
artifact wasnít ready-to-use out of the box.
The Secret Masters of the dwarves collected the tears of the Hundred
had lost their husbands to the corruption of the curse. The fist-sized
teardrop of gold they forged from the cursed gold needed to bathe for a
years in the widows' tears before it could cleanse the mountain
before the teardrop was ready, the
dwarves had been forced to abandon the fortress. Or perhaps the Secret
arranged for the evacuation, planning to return a century later.
case may be, things didnít go according to plan: A hundred years passed
deep in the bowels of the mountain, the Golden Teardrop was completed.
dwarves were never able to return to the Golden Citadel, and so the
Tonight only the American
Shakespeare Repertory will be presenting a staged reading of The Second Maiden's Tragedy
as part of the Complete
Readings of William Shakespeare. This is the second
apocryphal entry in the series, presenting a play that has been
hypothesized as being by Shakespeare without being widely recognized as
such. (You can see that the controvery started early in the play's
history: Early owners of the original manuscript, pictured above,
crossed out a succession of would-be authors for the anonymous
manuscript before someone finally supplied the name "Will Shakspear".)
Some of you may have also read the recent
news articles about the Arden Shakespeare deciding to include an
edition of Double Falsehood
as being at least representative of the lost play of Cardenio allegedly
written by Shakespeare and Fletcher. The Second Maiden's Tragedy
is the other
"lost play of Cardenio"
-- a completely different manuscript, but a second contender for the
This is a rarely performed play, so if
you're local this may be your only chance to see it in performance. It
will also give you a chance to see me. (No assassins please.)
Twin Cities Theater Connection recently put a
panel together of local
artists working on summer productions of Shakespeare. You can hear the
discussion on their "Summer of Shakespeare" podcast.
So if you've always wanted to know what I sound like (and can't afford
to spring for the Call of Cthulhu
audio book I did), this is your chance.
of Life" at the Society of Torch, Pole, and Rope)
The reason we look for verisimilitude in the rules of a roleplaying
game and not in the rules of Monopoly
is because we don't play roleplaying games as if they were a round of Monopoly.
Personally, I look at the rules of a roleplaying
game as the interface
between me and the game world. I want those rules to be fun and
interesting, but I also want them to be transparent: My primary
interest is interacting with the game world. If I wanted to interact
with the rules of a game, I'd play a boardgame like Monopoly or Arkham Horror.
So if the rules in a roleplaying game get in the way -- either due to a
lack of verisimilitude; or because they're boring; or dissociated; or too complicated --
then I'm going to be unhappy with those rules.
of the major problems I had at the time was the sheer sloppiness of the
module: There were continuity errors in the adventure scenario and
numerous self-contradictions in the rules. Ignoring some of the larger
creative and structural issues with the adventure, on a very basic
level the product was a mess.
In April 2009, Wizards of the Coast released
a revised version of the module as a free
PDF on their website.
I didn't pay much attention to it because I had already sampled 4th
Edition, found it lacking in everything I value in an RPG, and moved
on. But I did think it was a rather nice gesture on WotC's part to make
a corrected version of the product available.
I decided to re-visit this material with an eye towards using my
remixed version of the module as the basis for an OD&D
Remembering that the module had been revised, I tracked down the PDF.
My plan was to re-read the revised version of the module, see what had
been improved, and then adapt my remix notes as necessary if I thought
incorporating the changes would be worthwhile.
couldn't even get past the first paragraph of the first encounter
before discovering that WotC's revision was just as sloppy as the
The original module describes the encounter
like this (pg. 16): "The player characters are on the King's Road
traveling toward Winterhaven east to west (or right to left on the
map)." They are then ambushed by kobolds, as shown on this map:
The obvious problem, as I detailed in my original
remix essay, is that the indicated kobolds are all standing
in plain sight
for characters traveling east to west along the road.
keen-eyed revisers noticed the same thing, but they didn't want to redo
the cartography. So they opted to simply change the direction that the
PCs are traveling (pg. 6): "The player characters are on the King's
Road traveling toward Winterhaven, west to east (or left to right on
... except that's completely impossible.
Because two pages earlier in the module we
can see this map of the local area:
And, as you
can clearly see, Winterhaven is at the western end of the King's
Road. You cannot travel west-to-east anywhere on the King's Road and
end up at Winterhaven.
of course, get made. (For example, both the original and revised
versions of the module refer multiple times to the Burial Site being
southwest of town. You'll note that it isn't.) But what you have here
is an acknowledgment that there is a problem that needs to be fixed; a
decision being made (either deliberately or ignorantly) to not fix the
root of the problem; and ending up with a half-assed effort that just
creates an entirely different problem.
And it doesn't even fix the original
problem, because there are still
kobolds standing in plain sight.
like pretty much everythingGoogledoes,
is really cool. But either I'm
becoming an old fogey, or the fact that Google continues to make us
more and more reliant on content that exists only on their servers
makes me nervous.
In pondering the implications of the AIs in
Greg Egan's Diasporaimmersing
themselves so completely in virtual realities that they forgot about
the real world, I found a simple saying: "You should never forget where
your plug is."
The virtual reality may be indistinguishable from the real world in
every way while being filled with endless possibilities far beyond the
scope of anything the real world may be able to offer: But if the sun
goes supernova in the real world, you're
still going to die, no matter how deeply nestled you've become in your
In reflecting on cloud computing I think
it's equally important to say: "You
should never forget where your data is."
the "cloud" is increasingly becoming a buzz word that means, "If Google
ever goes away or chooses to shut down a server or decides to start
charging for a service, then you're all screwed."
Don't get me wrong: I use GMail, Google
Calendar, and Google
I watch videos on Youtube. I search prices on Froogle. Google Books
(along with the Internet Archive) is literally revolutionary in making
information widely and rapidly accessible. I'm even convinced that
Google Wave has the opportunity to replace e-mail. (Although, notably,
one of the reasons I believe that is because Wave is an open protocol
and not dependent on Google's servers.)
But whenever I hear about
somebody who has lost their entire blog because their hosting company
has gone out of business or failed to back up their servers properly,
I'm reminded of the importance of knowing
where your data is. The
Alexandrian, for example, is actually designed so that the
copy of every document is kept on my local computer. The website itself
is the first of several back-ups. And even though that isn't an option
for many blogs, you should still make a point of making a local back-up
on a regular basis.
The same applies to anyone who's keeping
their data exclusively on Google Docs, Flickr, Facebook, or anywhere
else on the web. The utility of being able to access and manipulate
your data from anywhere is great, but the importance of both knowing
the physical location of your data just cannot be stressed enough.
Which is why, for example, I can't get
excited for Google
Chrome OS. In fact, it's why I can't figure out why anybody
is excited about it. This is an operating system which fails to offer
even a single unique feature: Everything it can do, other operating
systems already do. In fact, the only thing it can uniquely claim to do
is to make your computer completely reliant on the "cloud" -- in other
words, to force you to give up your control over your own data. For
some reason this is supposed to be a "feature", but I can't fathom what
advantage anyone thinks they're going to get out of it.
Most published adventures are designed around a structure that looks
Your start at the beginning (Blue), proceed through a series of linear
scenes (Yellow), and eventually reach the end (Red).
Occasionally you may see someone get fancy and throw a pseudo-option
But youíre still looking at an essentially linear path. Although the
exact form of this linear path may vary depending on the adventure in
question, ultimately this form of design is the plotted approach: A
happens, then B happens, and then C happens.
The primary advantage of the plotted approach is its simplicity. Itís
both easy to understand and easy to control. On the one hand, when
youíre preparing the adventure itís like putting together a scheduled
to-do list or laying out the plot for a short story. While you're
running the adventure, on the other hand, you always know exactly where
you are and exactly where youíre supposed to be going.
But the plotted approach has two major flaws:
First, it lacks flexibility. Every arrow on the plotted flow-chart is a
chokepoint: If the players donít follow that arrow (because they donít
want to or because they donít realize theyíre supposed to), then the
adventure is going to grind to a painful halt.
The risk of this painful train wreck (or the necessity of railroading
your players) can be mitigated by means of the Three Clue Rule.
But when the Three Clue Rule is applied in a plotted structure, you run
the risk of over-kill: Every yellow dot will contain three clues all
pointing towards the next dot. If the players miss or misinterpret a
couple of the clues, thatís fine. But if they find all of the clues in
a smaller scene, they may feel as if youíre trying to
spoon-feed them. (Which, ironically, may cause them to rebel against
your best laid plans.)
Second, because it lacks flexibility, the plotted approach is inimical
to meaningful player choice. In order for the plotted adventure to
work, the PCs must
follow the arrows. Choices which donít follow the arrows will break the
Of course, itís all well and good to say, ďPrep Situations.Ē
But one of the reasons people prefer the plotted approach
is that it provides a meaningful structure:
It tells you where youíre going and it gives you a way to get there.
Without that kind of structure, itís really easy for a gaming session
to derail. Itís certainly not impossible to simply turn the PCs loose,
roll with the punches, and end up somewhere interesting. Similarly,
itís quite possible to jump in a car, drive aimlessly for a few hours,
and have a really exciting time of it.
But itís often useful to have a map of the territory.
This line of thought, however, often leads to a false dilemma. The
logic goes something like this:
(1) I want my players to have meaningful choice.
(2) I need to have a structure for my adventure.
(3) Therefore, I need to prepare for each choice the players might make.
And the result is an exponentially expanding adventure path:
The problem with this design should be
self-evident: Youíre preparing 5 times as much material to supply the
same amount of playing time. And most of the material youíre preparing
will never be seen by the players.
In some ways, of course, this is an extreme example. You could simplify
your task by collapsing some of these forks into each other:
But even here youíre designing eight steps
worth of material in order to provide three steps of actual play.
Youíre still specifically designing material that you know will never be
And in other ways itís actually not that extreme at all: The original
example assumes that there are only two potential choices at any given
point on the path. In reality, itís quite possible for there to be
three or four or even more Ė and each additional choice adds a whole
new series of contingencies that you need to account for.
Ultimately, this sort of ďChoose Your Own AdventureĒ prep is a dead
end: No matter how much you try to predict ahead of time, your players
will still find options you never considered -- forcing you back into
the position of artificially constraining their choices to keep your
prep intact and leaving you with the exact same problem you were trying
to solve in the first place. And even if that wasnít true, youíre still
burdening yourself with an overwrought preparation process filled with
The solution to this problem is node-based scenario design. And the
root of that solution lies in the inversion of the Three Clue Rule.
For any conclusion you want the
PCs to make, include at least three clues.
The underlying theory behind the rule is that having three distinct
options provides sufficient redundancy to create a robust scenario:
Even if the PCs miss the first clue and misinterpret the second, the
third clue provides a final safety net to keep the scenario on track.
This logic, however, also leads us to the inversion of the Three Clue
If the PCs have access to ANY
three clues, they will reach at least ONE conclusion.
In other words, if you need the PCs to reach three conclusions (A, B,
and C) and the PCs have access to three clues (each of which would
theoretically allow them to reach one of those conclusions) then it is
very likely that they will, in fact, reach at least one of those
And understanding this inversion of the Three Clue Rule allows us to
embrace the full flexibility of node-based design. Hereís a simple
The scenario starts in the blue node, which contains three clues Ė one
pointing to node A, one to node B, and one to node C. Following the
inverse of the Three Clue Rule, we therefore know that the PCs will be
able to conclude that they need to go to at least one of these nodes.
Letís assume they go to node A. Node A contains two additional clues Ė
one pointing to node B and the other pointing to node C.
At this point the PCs have had access to 5 different clues. One of
these has successfully led them to node A and can now be discarded. But
this leaves them with four clues (two pointing to node B and two
pointing to node C), and the inverse of the Three Clue Rule once again
shows us that they have more
than enough information to proceed on.
Letís assume they now go to node C. Here they find clues to nodes A and
B. They now have access to a total of seven clues. Four of these clues
now point to nodes they have already visited, but that still leaves
them with three clues pointing to node B. The Three Clue Rule itself
shows that they now have access to enough information to finish the
(Note that weíre only talking about clue access here. That doesnít mean
that theyíre guaranteed to find or correctly interpret every single
clue. In fact, weíre assuming that they donít.)
Now, compare this node-based design to a comparable plotted approach:
Note that the plotted approach can also be broken down into distinct
nodes. And in terms of preparation, the plotted approach requires the
exact same resources: Four nodes and nine clues. But the non-plotted
design is richer, more flexible, and leaves the PCs in the driverís
seat. In other words, even in the simplest examples, node-based design
allows you to get more mileage out of the same amount of work.
Of course, this entire discussion has been rather dry and technical. So
letís put some flesh on these bones.