[MUD-Dev] Request for ideas

[Eli Stevens]

----- Original Message -----
From: "Jon Leonard" <jleonard at slimy.com>
> On Mon, Sep 24, 2001 at 10:44:08AM -0500, Eli Stevens wrote:

>> Specifically, I would like pointers to past Good Ideas that
>> haven't been explored enough, or are implemented poorly, or are
>> just under-represented in general.  We are not looking to just
>> make a Diku clone, although combat will be a feature.  We want to
>> push the edge a bit.

> 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!>

> My first recommendation is to concentrate only on one or two novel
> features, as an academic year doesn't provide as much coding time
> as you'd think.  (This would be an argument for a text only game.)

> If you wind up ahead of schedule, you can always add something,
> polish the code, or even just test it.  :-)

God forbid...  ;) The limited time is an excelent point, however.  I
will have to bring this up at our meeting today.

> Depending on what the assignment permits, you might want to reuse
> code from existing projects for the boring parts, or at least use
> it as example code.  (I know where public domain socket code can
> be found, for example.)  This could give you more time to work on
> the novel portion of your design.

My understanding is that as long as we don't take credit for code we
did not write and a significant portion of the project is unique
(actually, from some of the descriptions of the other projects, I am
not even sure if that is true ;), then it should be fine.

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?  :)

> [specific list of ideas trimmed]

> You have an opportunity to explore the negation of many of the
> usual assumptions for successful games.  (I think this is the
> thread aspect JCL found most interesting.)

> For example, in a commercial game, you can't afford to let players
> collect and store everything they feel like, because that costs
> too much hard disk space (which is money).

> 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 :).

  <URL: http://www.kanga.nu/archives/MUD-Dev-L/2001Q3/msg00162.php >

> That may not appeal to all sorts of players, but appealing to
> everyone isn't even necessary in the commercial space (Achaea,
> etc.).

Very true.  We had been picturing something of a more traditional
mud (more of a "cool ideas bolted on" system), with the possibility
of taking it commercial if we wished.  The traditionality was more
uncreativity than dogma, however.  :)

> Negating the rule about never trusting the client, there are some
> intereseting distributed-MUD designs.  Some would be novel from a
> computer science perspective in addition to a MUD perspective.

> Some other random ideas:

>   * A game where not all players play at the same level (Some
>   players are generals, and get a broad view, while most are just
>   soldiers).

This could also link back into the dragon idea.  Not quite sure how,
tho.  :)

>   * 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.  :)

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?

>   * 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?

  <URL: http://www.kanga.nu/archives/MUD-Dev-L/2001Q2/msg00661.php >
  <URL: http://www.kanga.nu/archives/MUD-Dev-L/2000Q3/msg00659.php >

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.

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?

Thanks for all your thoughts, comments, etc.  This is exactly the
kind of discussion we were looking for.  =)

Good stuff,
Eli

--
Never use brute force in fighting an exponential.
      -- Andrei Alexandrescu, "Modern C++ Design"

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