[MUD-Dev] Reusable plots for quests
coder at ibm.net
coder at ibm.net
Sun Nov 2 11:16:17 CET 1997
On 30/10/97 at 10:07 AM, "Travis S. Casey" <efindel at io.com> said: >On Sat,
25 Oct 1997 coder at ibm.net wrote:
>> On 24/10/97 at 08:44 PM, "Travis S. Casey" <efindel at io.com> said: >On Thu,
>> Agreed, the examples I gave were overly extreme. However, going back to
>> the Rebel Alliance, the problem remains of what happens to the game when
>> the Empire or Rebels are utterly defeated? The game must change, and that
>> requires redefining the problem which the game players are attempting to
>> solve (ie the goal in in the mesh of goals, barriers and freedoms that
>> define any game). One approach is to make a cyclic goal series:
>>
>> Rebel vs Empire -> One wins -> Fight for control of winner -> One wins ->
>> Rebels vs Winnder -> Repeat.
>That's possible. Another possibility is for someone/something to choose
>a new "goal" for the game -- preferably something that will seem to
>naturally arise from the changed circumstances that result from the
>achievement of the old goal.
True. I natively tend to steer for game designs and solutions which are
in some form cyclic, or at least don't have end points. To the largest
extent possible I'd prefer to have a game which can run and administrate
itself outside of any social engineering or other touchie-feelie
activities. As such, my goal is to derive a set of game mechanics and
game state changes which won't end even if I utterly ignore them.
>A third, but IMHO less satisfying, possibility is to "fast forward" the
>game universe. By this, I mean moving the game universe forward to a
>time when there is another interesting goal to be achieved. Naturally,
>this will mean that player's characters will have to be changed --
>they'll either be older or be dead.
Yeah, I've seen this done several tinmes in MUSHes, They somehow
determine that the current period is now "boring", and leap forward in
time to a point that "things are more interesting". Much as you, I'm not
fond of this approach as I often find the "boring" segments actually much
more interesting as they offer incredible resources to create an
"interesting" time from.
>This third way is basically the same as the second, but it has the
>advantage of allowing the mud's admins to choose their new story with
>more freedom. The disadvantage is in the required changes to the
>characters. While many paper gamers will happily go along with this sort
>of thing, I have a feeling that far fewer mudders would.
Which raises I think a more interesting point:
The MUD community is currently very simply fragmented. The base sections
can problably be considered the classical RP/story telling/social on one
hand, and Combat/PK/monty haul/puzzles/powergame on the other. Has the
MUD field matured enough to fragment more? Does the increased population
of the net allow a finer granularity of player-types and game-types to be
supported?
Most of this would of course reall be just sub-dividing of the current
groupings. But the key I think is that the new finer granules would now
be self-supporting, and would exist on their own, with their own player
bases, with minimal intersection with other granules. (The real
definition of a community?)
>> I've been throwing massive change tokens in here deliberately as they are
>> much easier to manipulate in a discussion than more minor stuff with its
>> more measily and indeterminate side effects.
>To use an overused phrase, it's all in how you look at things. To me,
>coming from a paper RPG background, a role-playing game is something that
>requires constant involvement from the game master.
FWIW I have no background at all in paper RPG's, D&D, etc. My first
introduction to MUDs was Shades, and I moved on from there. Equally, this
colours my viewpoint strongly. One result of which is my prefered
hands-off approach to automation of game systems and game development.
>Thus, I don't have a
>problem with having to change things to take into account unexpected side
>effects of player actions. I'm not saying that you do have a problem
>with it, but I think there's some difference in perspective -- to me the
>effects you're talking about seem more like features than problems. :-)
I'm ambivalent on this sort of area. As a player I very definitely see
them as features and opportunities (a Good Thing), but as a game designer
I see them as problems as they create a greater administrative load (a Bad
Thing).
There's a tight line to follow there, balanced between the two.
>> Yup, but this is an entirely different game really. It also requires the
>> game and the plaeyrs to constantly re-invent the game as it progresses, as
>> the base fundaments of the game will be changing over time. This is not a
>> Bad Thing, its just very expensivce in time and Admins. The really really
>> nice aspects of this, are that game history suddenly starts having real
>> import. Who what where and when within the game world is now of actual and
>> real importance as these are player made and driven changes, with lessons
>> to be learned and used again in the curent state.
>Yep. That's what I'd really like -- the same sort of effect that you get
>in a long running paper RPG campaign, but able to do it in less time
>because of having more people involved.
Umm,. It certainly does have its own level of attraction. Possibly this
could be considered the real definition of "immersive" in regards to a
game.
>Of course, this kind of thing isn't for everyone -- the level of
>involvement required is huge. For me, it's more of a dream than anything
>else now -- during the time that I had enough free time to really be able
>to run something like this, I didn't have the expertise to do it. If I
>ever win the lottery, though, expect to see a kick-ass mud come up a year
>or so after that. :-)
Aye, I think we've all seen that side of the problem.
--
J C Lawrence Internet: claw at null.net
----------(*) Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
More information about the mud-dev-archive
mailing list