Backstory (was RE: [MUD-Dev] New poll)
Lee Sheldon
linearno at gte.net
Tue Jun 20 11:28:24 CEST 2000
> -----Original Message-----
> From: mud-dev-admin at kanga.nu
> [mailto:mud-dev-admin at kanga.nu]On Behalf Of
> Angela Ferraiolo
> Sent: Tuesday, June 13, 2000 5:30 PM
> To: mud-dev at kanga.nu
> Subject: Re: Backstory (was RE: [MUD-Dev] New poll)
>
> Losing linearity is no big deal.
Heh, maybe not to you, but I drives a lot of my friends from other media
crazy. :)
>But rules that apply to rising tension? I threw some of
> those out. For instance, the rule that says here's where
> the reversal goes...
<snip>
> ...But a player may not make a bad decision. A player wants to
> win the game. To
> satisfy
> that rule, I had to think of it differently.
I think it's also important to divide the game (world) experience up, and
not try to apply (or avoid) the same rules in all situations. I often use
reversals in modular stories, or any kind of surprise I can work in.
Similar to what you sketch below: If the PC is sent by NPC A on a quest to
get item A from NPC B, and return it to him, you have a basic, dull UPS
quest. If the PC arrives to discover NPC B lying in a pool of blood, and
the militia arrives seconds later to arrest the PC for the crime, you have a
classic 3rd act reversal (on a much smaller scale of course), and it seems
to work fine. The PC is never really in danger of losing the game, or even
being set back too long.
I think reversals work in larger, arcing stories as well, but they become
reversals to an entire collection of PCs aware of (and maybe participating
in) the story, not just one PC, and are more difficult perhaps, but are
structurally similar to the "events" discussed in threads elsewhere.
> More like, well, do we really need a reversal?
> Or do we just need to raise the stakes in an interesting way
> so that the player remains engaged? Let's send the player an obstacle.
> We can send another monster, but the player might be expecting that. To
raise > the stakes, I need something surprising.
> If Indiana Jones is making all the right moves, if he's
> really closing in on the ark, if
> he's not going to make a bad decision? Let's have the bad guys kidnap
> Marion. Just as Chief Brody is about to call for help? Let's have Quint
walk
> across the deck and smash the radio to bits. We've all seen how well this
kind > of thing was handled in HalfLife. The trick is knowing that here
> or close to here we have to increase the tension,
> that doesn't change. So you're right, I didn't really throw
> the rule out, I just had to rethink it.
Yup. I think I missed the middle step, probably out of ignorance, and just
began sticking in reversals as usual exactly the way you've described. I
don't see these requiring as much of a re-think as you do. Feels pretty
much like business as usual.
> What changes in games is not what needs to be done, but how
> we go about doing what needs to be done. Don't you think?
Yes, if we don't find new ways of applying the old rules, we end up with
stories (?) on the level of those we currently have. :)
> Do you have a new use of an old rule you feel like sharing?
Hehe, sure, and this one is a major pet peeve of mine: consistency of style,
theme, period, whatever... just BE CONSISTENT! The designer of the set for
a regency drama doesn't throw in a rear-projection TV because she thinks it
might look cool. Everything in a game or a persistent world should relate
to everything else, occupying the same universe as it were. (And no, for
any lurkers, I don't want to get into surrealism, or Monty Python or XEna or
anything else that breaks the rules. You have to KNOW the rules first, and
have a damn good REASON for breaking them, before you CAN break them).
Consistency is one of the most powerful tools we as storytellers have to
draw people into the living, breathing reality of the experience, and it is
simply ignored by many writers in our industry.
Lee
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list