[MUD-Dev] Request for ideas

Jon Leonard jleonard at slimy.com
Thu Oct 4 15:15:13 New Zealand Daylight Time 2001


On Mon, Oct 01, 2001 at 11:43:59AM -0500, Eli Stevens wrote:
> From: "Jon Leonard" <jleonard at slimy.com>
>> On Mon, Sep 24, 2001 at 10:44:08AM -0500, Eli Stevens wrote:

[request for Good Ideas, especially of the insufficently explored kind] 

>> JCL and I discussed this a bit on DevMUD on the evening of the
>> 25th.  Since then I've been trying to come up with some more
>> ideas.  Not as many as I'd like, but a few.
 
> Peerage!  Peerage!  ;)
 
> <EdNote:  Phbbbt!>

Well, I don't believe in the Peerage anyway.

And it's not as if my MUD is a secret or requires invitations.

[reuse, in particular socket code]

> I would be very interested in the PD socket code you mention.  I
> assume that you mentioned it because it is _good_ PD socket code,
> yes?  :)

I think it's good code, but as the author I may be biased.

  Simple MUD socket code:
    http://www.slimy.com/~jleonard/src/ipc.html
  DevMUD src (including socket code)
    http://www.slimy.com/devmud/prototypes/runnable/proto_8/

The DevMUD code supports a few more features, like multiple main
sockets.  But there's more that you'd want to strip out, too.

Both of them suffer from the inherent O(n^2)-ness of the posix
interfaces...

If there's something in their which is of insufficient quality,
please let me know.  (And I'll try to improve it.)

[much snippage]

>> This could allow for some sort of game where player status is
>> based on the amount (and rarity) of things they'd collected.
>> This could concievably be extended to some sort of potlatch style
>> PvP.
 
> Advancement as packrat.  Hmmm...  :) Certainly an interesting
> idea, but I am afraid that the year project and limited team would
> mean that significant content generation required for this to work
> might be a problem (although there is always user content...).
> This reminds me of the dragon's hoard idea a while back, where a
> PC dragon's power was directly related to the amount of gold and
> magic in their stash.  That would be more feasible, as not
> everyone would be a collector, and you would have the rest of the
> playerbase working as hard as they could to strip the dragon of
> their power.  :) Interesting idea, that the broken wheelbarrow you
> picked up makes a difference.  Theives and assassins would almost
> be the same thing (moreso than normal for a mud, I mean :).

Having some but not all classes advance this way could be
interesting.  I can imagine a type of caster class that depends
entirely on toys.  There might be a large variety of items that each
allow casting some particular spell once a day or something like
that.

In a different kind of game, a capitalist is just a packrat for
money.  :-)

This also leads to a fairly direct means of play-balancing some of
the classes: Ajust the tax structure, storage costs, etc.

[snippage -- maybe I should reply to submessages to improve latency]

>>   * A game with a contingency-based spell system, where all
>>   magical effects are latent, and only happen in the future when
>>   some other event triggers them.  (JCL compared this to
>>   "UggUgg's mana fight.")  I was thinking more about
>>   trap-setting...
 
> We had been discussing a magic system more complicated than the
> memorize / mana pool commonly seen (I still have a post in reply
> to the "Focus on Hocus Pocus" thread in my Drafts folder), but
> every implementation ended up being a programming language (I will
> polish up that post and send it).  Don't get me wrong, I think
> programming-language-spells are just extra-nifty, but I am a geek,
> and have found that what I like doesn't always map very well to
> other people.  :)

Well, if you have a programming language spell system, there's
nothing keeping you from providing some individually-useful opaque
subroutines.  Whether you allow players to disassemble the spells
they trade each other is an separate design decision.

For that matter, if you have an underlying [meta]physics, there's
nothing to keep you from having different kinds of spell systems on
top of it.  You could have an elementalist who can rather simply
throw lightning and fire until he gets tired/runs out of mana on one
hand, and on the other a ritual caster who need to find the right
spell ingredients, prepare them properly, and then produce a similar
effect with some specially prepared words.

They both wind up pulling elemental energy from somewhere (maybe
even the same place), but the ritual caster is much more useful when
the situation calls for something other than blasting.

I'm also reminded of the spell system from Dungeon Master (a fairly
old computer game).  The characters selected spell symbols (each
costing mana, with the first symbol being a multiplier for
cost/effect), and then cast the spell when ready.  It was pretty
clearly a lookup into a table of valid spells/effects, but it felt
like it had depth.  Getting the effect multiplier directly was a
nice touch, too.

> Which brings up another angle: how does one examine an idea and
> try to figure out if _other_ people will be entertained by it,
> without asking them?

And even asking them isn't all that reliable.  Many players will
insist that they want super-powerful equipment, but that won't make
game more fun, but rather less balanced.

A certain amount of thinking in advance is useful, and some polling
players, too.  But you really need to run a game for a while to
really know how
well it works.

>>   * Economic-based games, where players control businesses, hire
>>   employees, consume resources for sale and profit.  In a MUD
>>   this has the unique potential of having the contracts actually
>>   enforced by the game.  (This has side effects as well...  What
>>   to do about illegal contracts, or players who can't meet
>>   contractual obligations?)
 
> Hmm.  What kind of context would you see the economy taking place
> in?  What would be the shape of the world around the merchants
> that would give value to what they were selling?  It could be as
> simple as NPC purchasing prices fluctuating, but that seems a bit
> flat and uninteresting.  Am I missing something, or would it
> almost require a full world to integrate the economy into?

You probably do need a full world, or at least a convincing
collection of source/sinks.  Maybe something like a bunch of farmers
surrounding the city, and some remote towns that provide resources
not available locally.  (mines, spices, etc.)  You could model each
of these trading partners as having a steadily increasing supply of
their specific resource(s), and a time-decaying amount of any
resources they have on hand.  Setting up some local supply & demand
curves should probably be enough to get a reasonably robust system.
(Local currencies, taxes & trade delays are fun too, of course.)

Hmm.  Maybe I should code that.

> I like allowing person who makes the item to be enchanted and the
> person who does the enchanting can be totally separate.  Allow
> crafters to learn new words to use in their item descriptions, and
> then those new words can be used to make items better suited for
> magical enchantment.  The economy could be driven by racial/guild
> differences...  Dwarves make mithral items (i.e.  any item with
> the word mithral in the desc) faster than anyone else, and gold
> items more cheaply.  Elves can work silver very well, but are
> horrid with iron.  Humans can do everything pretty cheaply, etc.

Why stop there?  A given item could be the result of many different
artisans.  For example, a sword might obtain the blade from a smity,
have runes inscribed in the blade by a mage of some sort, get some
gems put in the hilt from jeweler, and so on.  Or simpler
miner->smelter->smith...

You could also add addition resource->product paths over time,
though that could have unpleasant game balance consequences.

When I asked my anthropologist friend about references for this sort
of thing, he recommended I read Karl Marx.  While Marx's predictions
weren't all that good, his descriptions of economic systems up
though early industrialized capitalism are apparently very good.  (I
have not yet read Marx.)

> Game enforced contracts...  Hmm...
 
> I am drawing something of a blank on what the game could enforce,
> beyond "I will buy X item."  Care to expand?

More or less any financial instrument you can name could translate
in some form or other.  The simplest one that comes to mind would be
an option to buy something: I give a vendor 5 gold now, and in
return I can buy his Sword of Glinting and Gleaming for 95 gold
anytime in the next month.

This lets a player reserve an item for which they don't presently
have the cash, for example.

A more sophisticated example would be assigning shares in the profit
from a trade expidition.  (Historical example: Renaissance Venice).
Money to buy trade goods is obtained from a variety of sources, and
a ship, captain crew are hired.  When (if!) the ship returns, the
profits from the voyage are distributed according to the original
agreement.

There's no particular reason that profits (or risks) need to be
divided evenly, either.  Limited partnerships (again, a
game-enforced contract) isolate some of the people from liability.

Exactly what can be accomplished depends a lot on the details of the
contract language, and also on the underlying game mechanics/laws.
The joint-stock corporation is an example needing legal system
support: In case the corporation can't meet it's oblications, only
the corporation goes bankrupt, not all of the people who own stock
in it.  Whether it is possible to form a corporation in the first
place is a matter of law, and possibly local law.

All sorts of contracts to play with, many of them quite gameable.

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



More information about the MUD-Dev mailing list