[MUD-Dev] Leaving characters in play
s001gmu at nova.wright.edu
s001gmu at nova.wright.edu
Tue May 12 23:42:18 CEST 1998
I cleaned this up for 80 cols.
On Wed, 13 May 1998, Joel Kelso wrote:
> I read Ben Greear's post about a space trading MUD and problems with
> keeping characters around whilst not logged on. It reminded me of an
> idea I was thinking about a couple of months back.
>
> I was thinking about the problems of having a space
> trading/warfare/colonization MUD that gives a sense of size and distance
> in space, while still allowing player interaction. One of the problems
> is (and I notice that some recent posts refer too the same problem in
> the context of UO) that you need a world that is large enough for
> players to travel in and colonise with a real feeling of exploration;
> but which is small enough to allow frequent player interaction.
The main problem is that you need to clearly define the scale of your
game. Is it a micro-management game, where the player controls one
character in the scope of a room by room adventure, or is it a game about
interstellar commerce, and the fate of whole empires? Trying to combine
the two is, I would posit, smashing two games under one title.
There is aboslutely nothing wrong with that... most games DO do that, and
just have a smooth progression from one point to the next (this ties into
the posting(s?) about how single player games grow from one kind of game
to another as they progress).
> The idea I came up with (or re-invented: there might really be new
> ideas, but _I've_ never had one :-) was to use "hyperspace jumps"
> between star systems as a way allowing controlled interaction. The idea
> is that when players leave the game, they are either docked safely at
> some station, or they launch themselves into a hyperspace jump. While in
> hyperspace, they are completely removed from the physical game world
> (although still in communication so players can chat and wander around
> their starships if they log on during this period). The interesting bit
> is that (a) once the jump has started its irrevocable: the ship _will_
> emerge at the intended location at the intended time and (b) the ship
> and its destination and emergence time is visible to everyone else in
> the game. Think of it as throwing a ball into the air: everyone can see
> it up there and where and when its coming down, but no-one can touch it.
Interesting... We are aiming for a fantasy setting, but a similar
approach might work... though we wanted to have cross country travel be a
lot more dangerous. And teleport is istantaneous. Still, it gives one
something to ponder... :)
> What this means is that ships can meet up during journeys, for trading,
> piracy or whatever at a time when the players are guarenteed to be
> logged on. Players are vunerable to attack, but have a chance to
> arrange a (real and game time) window in which it occurs: pirates with
> fast ships can lauch on interception jumps.
>
> There's lots of other details to flesh out, like typical distances and
> times of trips. Players with different scheduals can opt for different
> careers and types of starship. A player who can log on for a short
> amount of time every 3-4 days could run a slow (but fuel efficient)
> long-jumping trader ship or a patrol ship, while a dedicated student
> player might be part of a millitary fleet and be expected to log in at
> all sorts of strange hours to interecept an enemy fleet or take part in
> a fleet battle.
>
> Anyway thats the gist of it.
Interesting idea. :)
This whole thread, of dealing with leaving characters in the game when the
player has logged out, has forced me to think about what it adds to the
game, and why one would want to do it (aside from the usual, "it's more
realistic" argument, which I think we all agree is insufficeint). It
seems to me that keeping characters in game when the player is away, with
no defense (s/he's essentially a moron when yer gone) is counter to the
point of any game (unless the point is just to drive potential players
away). Offering up safe rooms (presumably at a cost), makes the game into
at least a little bit of a resource management game. You have to manage
your location and the resources necessary to keep you there, at the very
least. Since we are aiming at a resource management game, it works great
for us. We plan on using safe rooms (haven't decided if they will cost $
yet), and probably not a lot more than what is already built into the
game. One key part of the design is that players will be able to purchase
rooms, etc, as they progress through the game and they acquire $. There's
no reason they can't purchase a safe room either... In fact, we were
thinking it'd be a nice way to encourage player-run inns. Something along
the lines of, PC adventures for years, then settles down and buys an Inn,
with a few safe rooms. S/he charges slightly under the game's prices, or
offers some other perk (be it location, whatever), and starts piling up
money, etc.
I've had a few other thoughts on general mud design (I've been reading and
digesting _The Art of Computer Game Design_... heh), but they aren't
really part of this thread, and it's late, so I can't really organize my
thoughts well enough. mayhaps tomorrow... :)
-Greg
--
MUD-Dev: Advancing an unrealised future.
More information about the mud-dev-archive
mailing list