[MUD-Dev] Star Wars Galaxies: 1 character per server

Acius helpsfamily at attbi.com
Mon Dec 16 20:19:31 CET 2002


Wes Connell wrote:
> Valerio Santinelli wrote:
 
>> Think about maps, quests completed, NPCs you've talked to and all
>> the info tied to their conversations. A system like the on
>> eyou're proposing would probably be a hell to manage. You would
>> need to be sure to send to the player ALL the data that could
>> ever be needed if you want to cut off the problem of storing all
>> this on your server. On the other hand, if you're only going to
>> send him the basic datas and an ID that points to all the other
>> structures tied to the character, you're loosing the point in
>> sending datas to the player.

If you're trying to impose a system like this on an existing game,
it's trickier. If this is a known constraint from day one, then
grouping all player-relevant data into the same place is not
particularly difficult.

>> I don't know if my mumbling makes sense.. it's getting late
>> there, too :)

> To continue the argument...

> Version control would be (IMO) the toughest part of this. How
> would you handle somebody that has a player file from three months
> ago when you have changed the player file data three times (only
> slightly) in the past three months? Surely the player file layout
> won't remain the same throughout the lifetime of the game.

LPC handles this reasonably cleanly by saving data files in a format
akin to this:

  hp 10
  name "Robert"
  password "x9J1P.mn4"
  varSettings (["ansi":1, "deepThoughts":0,])

Essentially each line is just a variable followed by a value. When
you load in an object, variables in the object not mentioned in the
data file are set to their default value. If you change the datatype
of any of the variables (but retain the name), then you perform a
validity check on these variables and provide a conversion routine
(we've got a few of these lying around).

It's a nuisance, but we've yet to do a player wipe in several years
of coding, and the earliest data files still log into the current
version of the MUD. So I guess it's doing something right. This is a
difficult problem, but not an insoluble one.

> What if he logs back in two years later? Will you retain all the
> patch information for that long?

You would need to, wouldn't you? Of course, that's not exactly
impossible, as long as your conversion routines are consistent and
bug-free. The overhead of keeping conversion routines around doesn't
seem all that terrible (a few extra kilobytes of code a
year?). Then, when they log in, simply apply all the conversions
serially, much as one would apply patches to a very old game.

> What if the encryption on the player file has been compromised
> since Bubba last logged in? Will you still let him upload his
> player file?

Wait, this is strong encryption, right? So that means they broke the
encryption, and modified the character. Well, in that unlikely case,
there's close to nothing you can do (because properly breaking
encryption, modifying stats, and re-encrypting is something you
can't really detect). They've done far better than winning the
lottery, so simply having the GM's detect this case by keeping a
sharp eye out is probably solution enough.

Anyway, it's soluble, but it really does help if you design this
capability in from the ground up. Attempting to apply this to an
existing game would be quite the headache.

-- Adam Helps


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list