[MUD-Dev] Re: WIRED: Kilers have more fun

[Nathan F Yospe]

On Thu, 9 Jul 1998 CJones at aagis.com wrote:

:Now, the players will have some degree of control over an area. There
:aren't any real boundaries unless I enforce "zones" or "realms" which, 
:for me, are convenient mechanisms to make sure that objects stay in 
:the correct scenario. I assume that for the players to take their 
:roles and responsibilities seriously, they'll have to command their 
:"tools for enforcement", the henchmen NPCs and PCs, to police the area,
:collect taxes, etc. The players decide the policies, and with 
:appropriate scripting, the NPCs can carry them out ("Aye, lad. Abide 
:by the laws and us'll be friends.").

:As the stories and rumors get passed from town to town, other players
:will hear about what happened and challenge Bubba and crew in the
:same way Boffo was challenged. The MUD can regenerate Boffo as 
:Boffo, jr., and let him try to recapture the tower with a small 
:army of henchmen (I hope this would be an automatic process).

:Upside: The game starts to develop its own systems of tyrannical player
:rulers, an atmosphere of achivement and competition for less powerful
:players striving to rule, and laws can begin to be enforced.

:Downside: I would have to ensure that I have a small army of programmers
:ready to write the scripts or code to make things happen. Bubba decides
:that he wants to fortify the tower, so he builds a keep around it. He
:then adds traps, etc. This is definitely not something for a compiled
:MUD. :-) Assassins, invisible killers, and others of that ilk will have
:an easier time taking a tower than Bubba the buffed fighter-type.

:Similar idea, different execution:  why not have player or scripted NPC
:barbarian horde leaders, with small armies of henchment? That would
:really shake up small town life. :-)

This doesn't actually have to be online... and the mud *can* be compiled. I
*know* I'm the only person here who doesn't have a programming language, as
opposed to a building framework, for reasons that come down to "programming
languages are too unsophisticated for my needs", but... well, think of this
as a case of definition. A programming language needs to be able to define,
among other things, the state of the world. That's unacceptable. There's no
way a programming language can work around this and still be usable, unless
it is, essentially, an interface definition kit. That's what I have, and as
it ended up being too unweildy to program with... I redesigned it as a tool
that can eventually be set up with a GUI and a set of parameters... and the
effective result of filling out a form, and assembling smaller things. With
this in mind... if I were to say that this is quite the approach I hope for
in time, when I'm running the mud on a public machine? Well... the point is
this: Complex behaviors being evaluated by the mud are a drain, and there's
no need to keep eight *large* neural nets running at the same time just for
a single NPC... when that NPC, and a few hundred more like it, can run from
a remote computer and interface just like a standard client, only without a
text or graphical interface... in other words, STORE THE AIS ELSEWHERE! The
critters from Creatures, which I believe Ling just mentioned, show what the
potential of a neural net based AI can be. (No, I don't do the "chemicals",
at least not in the AI. I do have instincts and such running on *both* NPCs
and PCs, though, which amount to chemicals, in terms of effective weighting
of input data... and the neuron count for a *normal* client is currently at
about 12,000... the NPC would be even worse. I don't want that on the mud's
host machine. Put the clients on remote machines... any remote machine... a
PC here, a university account there... give PCs incentives to install these
NPC executables and run them... and I end up with a lot more capability for
simulated NPC inteligence. Add to that the tokenization of language... with
the fact that the NPC can eventually learn to talk to PCs... and perhaps in
time some of them will pass Turing tests.
--

Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Student, University of Hawaii at Manoa, Physics Dept.
yospe#hawaii.edu nyospe#premier.mhpcc.af.mil http://www2.hawaii.edu/~yospe/