<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: Ho hum --> <!--X-From-R13: @nguna Kbfcr <lbfcrNunjnvv.rqh> --> <!--X-Date: from tacitus.globecomm.net [207.51.48.7] by mx01.ny.us.ibm.net id 860975581.89343-1 Sun Apr 13 23:53:01 1997 --> <!--X-Message-Id: Pine.GSO.3.95q.970413130753.10523A-100000@uhunix2 --> <!--X-Content-Type: text/plain --> <!--X-Reference: 199704132248.WAA403102#out1,ibm.net --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, Re: Ho hum</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:yospe#hawaii,edu"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00124.html">Previous</a> | <a href="msg00126.html">Next</a> ] Thread: [ <a href="msg00124.html">Previous</a> | <a href="msg00133.html">Next</a> ] Index: [ <A HREF="author.html#00125">Author</A> | <A HREF="#00125">Date</A> | <A HREF="thread.html#00125">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>Re: Ho hum</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: Mud Dev Mailing List <<A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A>></LI> <LI><em>Subject</em>: Re: Ho hum</LI> <LI><em>From</em>: Nathan Yospe <<A HREF="mailto:yospe#hawaii,edu">yospe#hawaii,edu</A>></LI> <LI><em>Date</em>: Sun, 13 Apr 1997 13:51:51 -1000</LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> On Sun, 13 Apr 1997, Ling wrote: :On Sat, 12 Apr 1997, Nathan Yospe wrote: : :> You mean, how does it decide to ask "you sure"? That's pretty simple. :> There is a probability weight on prefered interpretation of a command, :> with comparative risk being a crude product of action effectiveness and :> consequences. This is part of the command interpreter, and is tied : :I would have thought that'll be fairly tough to calculate. Does it every :ask 'You sure?' when it's obviously a low risk action? I've had those show up, early in the modeling process, and undoubtably there will be cases later, but the models cleared out on those with a little tweaking. Since each potential action processor weights itself, the confirmation request is simply a byproduct of the natural language parsing process. Its not so much a risk assesment as a likelihood assesment. The models (I have yet to port these skill objects into the code, but the design allows easy porting of objects...) have used a large number of factors, but they all boil down to the following: - utility match (do I have all the proper tools for the job, and if not, how close do my substitutes come... IE. "You lift the shoe to hammer the nail, then pause, noticing that its not exactly a proper hammer." >Hammer nail anyway.) - clarity (An ambiguous command will return a query as well... >ha m. usually gets you a question, unless there is only one available command 'ha*' and one potential target 'M*'.) - unambiguity (This is a sort of an imformation availabilty tracker. It is complex, but its what keeps you from attacking a pair of glowing eyes in pitch blackness without knowing what they belong to... IE. "Its rarely a good idea to start a fight with something you cannot even see." >shoot eyes anyway.) - success probability (This is based on the contemplation routines, which are a bit complex, but essentially return a probability, based on _available_ information. This does not take into account the unambiguity factor, which has already been resolved) - desirability/consequences (This is what kicks in when you, say, type "eat grenade"... The verb "eat" is going to kick back at you the desirability of eating anything inedible, dangerous, or thoroughly repulsive. The grenade hits the inedible first, then the dangerous. It would actually tell you that you broke your teeth if you tried to chew the grenade after ignoring the report that the grenade didn't look safe to chew, but eat would try swallow too, and there is a species that could manage to swallow a grenade... I don't have multiple warning support, though it could be coded specific to some new verb... the inedibility warning would not catch the unsafe warning, which means the fellow would get no warning about the fact taht the grenade was primed to explode... looking at my code, there would be no such warning, aside from the one that flashed up the moment the grenade was primed or enttered the effective space of the character. As I said before, though, with the NLP in place, the warnings followed with minimal effort. :> :in reading through some of the old stuff. Just thought I'd bring the :> :topic of game design back into the mailing list and pollute the optic :> :fibres with my presence whilst I'm at it. :> :> Ah, now this is a fun debate. Personally, I like a system with feedback :> between a list of attributes and a list of skills, all of which are : :Hmm.. I'll wait patiently for some development (like that Champion thing). :Gonna be busy for the immediate future... Hmm. I've always hated the numbered skill systems. Thus my verb/attribute system.... the skill system I use, such as it is, is totally tied into the NLP. :Earlier, someone mentioned the possibility of the processor spending most :of it's time time-slicing between multiple threads if there was a lot of :connections. This number of threads business seems a lot like voodoo to :me and being the unsure vulnerable type (while I'm in this mailing list :watching all you masters chat), I won't mind some help. This is my model :and it'll be great if someone commented (it's for a uniprocessor): : :Initial thread: Sets everything up, opens a socket, and waits to : terminate. :Signal thread: Sits in a sigwait() loop, handles signal for the entire : process. :Server thread: Waits for the next connection. :Input Socket thread: Snoozes on select(), gets input from socket and : plonks it in the input buffer, serves multiple sockets. :Output Socket thread: Waken up whenever there's something in the output : buffer. :Input processing threads: Multiple threads which interpret the actual : input, multiple meaning something like 1:10 ratio of : threads to clients. :Event processing threads: 3 threads sat in a pool (nicked from Lambert's : I think). :Area threads: The usual, I've not thought about this yet, it's gonna pose : a problem. :Compiler threads: Compiles I suppose... : : :The main focus is on the socket threads. I can either use the above or I :can: Combine the socket input and output threads by getting the signal :handler to wait for SIGIO, use select() to figure out which client(s) have :input pending and use semaphores to tell the appropriate threads, the :socket threads would sit in a semaphore wait position (the semaphore can :be released by the signal handler or be an event which has just popped :something in the output buffer). : :The dilemma is: If I used select(), the socket threads will either have :to use a loop to check input and output buffers or I can have input and :output threads (the server thread can have SIGIO all to herself). If I :depend on SIGIO, I will have to end up using select() anyway to figure out :which socket it was and I may as well have one thread sleeping on :select(), waking up the other threads when needed. What gets me is that :if I used the later, won't there be an awfully high number of SIGIOs being :sent out? I'm as much of an infant here, in many ways... I think I might have a problem if I don't start shuffling and pooling my threads. Not that that's a problem, really... The OO structure that I wrapped my threads in is nicely adaptable to the point that I could, quite easilly, assign a single manager thread to move the sleeping threads into and out of a pool, rather than letting them sleep.... I've got five sets of threads, but only three types. The types are: socket IO (these could be split into I and O and pooled, I think... or put into a polling loop, even...) management (pretty much handles creation and destruction of all thread types, and a number of similar things. Also adds and removes objects from the world.) and Event manager (In three batches: global, area, and room... the latter two could be pooled quite easilly, and should never exceed the number of players...) that still leaves me with up to 2.2 times the number of players present... which, with 200 players, hits a number closing on the 500 thread panic mentioned earlier... I have at times slipped a nice little loop in in place of the threads, tricking the process to switch to every wakeful "thread"... the object model allows this without changing any code outside of the SysThread.h and SysThread.cpp files. I suppose I could have a pool of threads do a similar slight of hand act, but wouldn't that defeat the whole point of the threads? I could easilly make the area threads take over all of the room threads, and save on those... would require the area to process all current events, then all room events (area already has precidence) but I could use the trick of having an empty room event dropped on the area queue when the room has an event to process in order to make sure the area thread wakes up... Or tie the same thread directly to all of the queues, so that any of them can schedule a wake for it... The problem is, everything depends on these threads going to sleep and waking on an externally scheduled wake signal... this is how I manage to avoid concurency problems, as well. __ _ __ _ _ , , , , /_ / / ) /_ /_) / ) /| /| / /\ First Light of a Nova Dawn / / / \ /_ /_) / \ /-|/ |/ /_/ Final Night of a World Gone Nathan F. Yospe - University of Hawaii Dept of Physics - yospe#hawaii,edu </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00124.html">Re: Ho hum</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00126.html">Risk Assessment -- was (Re: Ho hum)</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00124.html">Re: Ho hum</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00133.html">Re: Ho hum</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00125"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00125"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>Re: Ho hum</STRONG>, <EM>(continued)</EM> <ul compact> <LI><strong><A NAME="00113" HREF="msg00113.html">Re: Ho hum</A></strong>, Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Sun 13 Apr 1997, 09:25 GMT </LI> <LI><strong><A NAME="00115" HREF="msg00115.html">Re: Ho hum</A></strong>, Jeff Kesselman <a href="mailto:jeffk#tenetwork,com">jeffk#tenetwork,com</a>, Sun 13 Apr 1997, 11:45 GMT </LI> <LI><strong><A NAME="00118" HREF="msg00118.html">Re: Ho hum</A></strong>, coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Sun 13 Apr 1997, 23:57 GMT </LI> <LI><strong><A NAME="00124" HREF="msg00124.html">Re: Ho hum</A></strong>, Ling <a href="mailto:K.L.Lo-94#student,lut.ac.uk">K.L.Lo-94#student,lut.ac.uk</a>, Mon 14 Apr 1997, 05:38 GMT </LI> <LI><strong><A NAME="00125" HREF="msg00125.html">Re: Ho hum</A></strong>, Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Mon 14 Apr 1997, 06:53 GMT </LI> <LI><strong><A NAME="00133" HREF="msg00133.html">Re: Ho hum</A></strong>, clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Tue 15 Apr 1997, 00:03 GMT </LI> </ul> </LI> <LI><strong><A NAME="00099" HREF="msg00099.html">Re: Just a bit of musing</A></strong>, clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Sat 12 Apr 1997, 08:49 GMT <UL> <li><Possible follow-up(s)><br> <LI><strong><A NAME="00098" HREF="msg00098.html">Re: Just a bit of musing</A></strong>, clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Sat 12 Apr 1997, 08:51 GMT </LI> <LI><strong><A NAME="00111" HREF="msg00111.html">Re: Just a bit of musing</A></strong>, Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Sun 13 Apr 1997, 07:55 GMT </LI> </UL> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>