[MUD-Dev] Instancing, or Franchising?

Dr. Cat cat at realtime.net
Wed Dec 11 11:50:26 CET 2002


I agree that instancing of areas in MMORPGs has a lot of potential
downsides.  Though I'm not totally convinced it has no useful place
there.  Castle Infinity had a very nice implementation of it, but
they never really got big enough to test how it would play and
"feel" with a hugely crowded server.  Which is a shame, it was one
of the finest online games ever crafted, and deserved the success
which sadly always eluded it.

My instincts do tell me that for some types of games, an initial
tutorial area that generates one private instance per player (or
just runs offline totally on the client) is something that's better
to have than a crowded tutorial area with the confusion of lots of
other people running around and talking.  Castle Infinity had that
too, though it wasn't something you were forced through at the
start, but rather could go through any time you chose.

Anyway my theoretical intended solution to developer-made areas
getting overcrowded has been, for many years now, "franchising".
Early on in our world, one of the most popular hangouts was
Mycroft's Tavern.  If we got so big that we ran into Yogi Berra's
famous quote "Nobody goes there any more - it's too crowded", the
idea is we would change the concept from it being "a place" to "a
type of place" or "a chain of taverns".  Not all of them would need
to be 100% identical, but people wanting to hang out in "a place
like that" could pick one or another of them to be their regular
hangout, with the displeasure of being overcrowded producing some
natural tendency for people to spread out between them somewhat.

This is all theoretical in our world, because our other method for
keeping there from being too many players per area, the user created
content paradigm, is predominant and is keeping the issue under
control.  It's also nicely scalable - if 1 out of 50 players makes
places to hang out when you have a thousand people, and 1 out of 50
players does so at a million, you still have about the same ratio of
players to places.  If you try to do the same thing with developer
created content, if you keep your team size the same, they'll get
swamped.  If you try to grow the team in proportion to the growth of
the playerbase, you may get swamped (though this is the type of
problem every commercial project hopes for, and few fet!)

I will note that the "shards" mechanism most of the big online games
have is somewhat analogous to franchising, in a sense.  But even
within one shard, they have a clustering problem - the places where
you get things that advance you in the game are so important to most
players that most people want to swarm around those.  The Star Wars
Galaxies approach of allowing that kind of stuff to algorithmically
show up anywhere, at any time, is the type of solution I would have
advocated for that.

I'd also note that in our game, we have something of a player-driven
analog to franchising, which is people copying "good" ideas, or more
accurately popular ones.  We saw that in our first month open, when
one player used red and black pillows and different patterned floor
tiles to make a place where you could play checkers.  Within days,
probably a dozen people had checkerboards in their dream.  That was
an example of a quickly passing fad, but other things like bots that
run sparring systems, nightclubs, RP settings, etc. become enduring
trends.  It's sort of nicely organic, like real world franchised
businesses, in that how many of them open is driven partially by the
amount of player demand, and how many of them stay open is driven
almost entirely by that.  So it's partially self-balancing without
developer input, which is great!

*-------------------------------------------**-----------------------------* 
   Dr. Cat / Dragon's Eye Productions       ||       Free download!
*-------------------------------------------**   http://www.furcadia.com
  Supporting user-created graphical worlds. ||  Let your imagination soar!
*-------------------------------------------**-----------------------------*

_______________________________________________
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