[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

53: Re: Threads, IO handling, and Event Queues

[Full Header] [Plain Text]
From: claw@null.net
Newsgroups: nu.kanga.list.mud-dev
Date: Fri, 14 Mar 97 15:08:53 -0800
References: [1]
Organization: Kanga.Nu
On 10/03/97 at 08:53 AM, "Carter T Shock" <ctso@umiacs.umd.edu> said:

>I agree that multi-threading is not an issue to be taken lightly. I'd
>suggest that it only applies to the mud if you want to run different
>hunks of your world asynchronously. You could run different regions as
>seperate threads, unloading the threads when the region is devoid of
>players to reduce load. You could also run with each user as a seperate
>thread, but I wouldn't recommend it.

Or, you could take my approach: an event driven server where events are
transactions and compete simultaneously for compleation.

>One of the things I like about SillyMUD is the catastrophe code. The
>goblin raid on a town, the dwarf miner's revolt, etc. No reason you can't
>code up these "events" as a seperate process that runs, attaches to the
>mud, loads and tracks the appropriate critters, plays out its scenario
>and then cleans up after itself. 

Which is based on the premise that having an unused area defined or
otherwise "in the system" is wastefully resource consumptive, and doesn't
make a lot of sense to me.   Start with an event driven server and 90% of
this logic disappears.  Move from an in-memory image to on disk with
decent cacheing and the rest goes too.  Instead we are saddled with
iterative, polling, looping servers that spend most of their time either
doing things that aren't needed, or hoping to hell that the system loop
time is not so long that user performance goes thru the floor (cf
LambdaMOO).

>In essence, if you design well, you
>should be able to dynamically modify what's going on in your world
>without having to reboot.

Err, you write the above as if it were a "new thing".  The Tiny-* world
has been doing exactly this for years -- massively runtime modified and
defined worlds.

--
J C Lawrence                              Internet: coder@null.net
----------(*)                              Internet: coder@ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...


ing operation code for their object. If they choose to, great. If they don't, leave it up to the administration to detect/repair/handle. The second is a Good Thing, but I'm not sure if its enforcable/codable without either binding it into the server, or precluding users from creating alternate grammars (eg an area which requires all commands in Klingon with a reversed (subject/object)/(verb/noun) grammar). While the alternate grammar bit may be of dubious value, for the me the requirement of not binding ANYTHING game specific, such as a grammar, into the server is absolute. The tack I've taken is stolen from ColdX, which in turn is lifted fairly directly from Cold, COOL, and before that MOO (tho its a long way from Tiny*): Everything is an object. Objects are defined in a database. Objects have Unique IDs. Objects may contain methods, attributes and verb templates. Objects may inherit from other objects (multiple inheritance). Inheritance applies to methods, AND verb templates. Inherited methods, and verb templates can be locally over-ridden. Objects may define methods and verb templates as unable to be over-ridden. Objects may declare (virtual) methods and verb templates without defining them. Objects inheriting virtual methods and verb templates must define them. A verb template is a string which defines a spcific command grammar which is used to match against commands. eg A template of "l?ook [at] <this>" defined on a dog object (note that the template is defined on the target object, not on the issuer) with defined names "dog", "rusty", and "fido" would match any of the following: l dog l at dog look at dog l rusty l fido l at fido etc. And would result in the method attached to that template being called on the dog object. As such a user programming an object with a button would inherit from a button object to get the requisite verbs and supporting code. There are problems with this general approach however: You quickly end up with a very large array of base objects intended as components. (eg button object). This can present namespace and complexity/learning curve problems (I'm coding a widget, would any of the 800+ component objects already defined really help me here?), as well as the obvious documentation problems >Lessee... in most mud worlds, the "nouns" are dynamic, but the verbs are >not. Not true for MUDs which support (free) user programming. >I put nouns in quotes because often a noun/adjective pairing is >required to uniquely identify an object (the long sword, the black sword, >etc.). I believe "noun phrase" is the accepted term. >The verbs in the system are your commands. cast, throw, hit, etc. >If we want to allow dynamic or generic verbs, now you're getting into >natural language processing and I definitely don't want to go there. So >there are some distinct sentence structures that emerge: ><verb> <object> "hit foo" ><verb> <object> <object> "give gold foo" "cast fireball foo" I don't have any docs or notes here at work, but you should be able to find some good references on the basic english-style declaritive grammars on the Web. Where <noun> is a noun phrase, which may consist of a series of noun phrases joined by (implied) conjunctions, and where a noun phrase may consist of (several) adjective(s) and a noun: <verb> <verb> <noun> <verb> <noun> <adverb> <verb> <noun> [<preposition>] <noun> <verb> <noun> [<preposition>] <noun> <adverb> etc. >So the first trick is to define your grammar... establish a mapping of >verbs to appropriate objects. We'll start with "hit". In most codes if >you "hit foo" the code first sees what the allowable targets are for foo, >then tries to locate a foo somewhere in the world that satisfies the >target rules (get_person_room_vis(), get_obj_room_vis() whatever). Not for me. I do a cyclic proximity scan from the issuer, looking for an object with a template which matches "hit foo". The basic scanning order is: issuer, inventory, removed inventory, items close, items nearby, items far, and then out thru any levels of containment (room, area, etc). >An example of where this works very nicely is with magic. Identify the >verb "cast" as special in your lexical analyzer. Rather than ><verb> <object> <object> >it becomes ><verb> <spell> <object> For me: Bubba learns a new spell "wugga". Bubba's object now inherits from the "wugga" object, adding the requisite templates and methods. Bubba enters, "cast wugga on boffo", or "wugga boffo", and gets the expected result. >Now the question, why bother? >Well, first off, it can make the mud more user-friendly. Rather than >simply reporting "huh?" on bad commands, a true parser should be able to: > > 1) report the exact location of the error in the command > 2) offer up suggestions (tab completion of commands) Hurm Not arguing, but not clear on what I can't do here. My system violently discourages name compleation if only due to its transactional nature (everything is a transaction which can be rolled back). Hurm. I guess this could fit in by putting a light weight client interface between the connection object and the socket to allow very light-weight accessor-only private transactions to get possible target lists. Hurm. Could get *really* ugly fast, but it would work. The thing I have right now (and am fairly happy with), is the old target query: > get bag Do you want the: 1) Red bag 2) Tattered paper bag 3) Mouldy sack 0) Cancel command >> 2 You take the tattered paper bag. >Now, we could do all of this without learning lex/yacc, but doing it in >lex/yacc gives you a standard interface.. not to mention someone else has >written most of the ugly code for you already. Btw, the newer flavors of >the GNU lexer/parser software (glex and bison I think) offer up a C++ >version that encapsulates the parser as an object. Nifty side effect is >that you can have more than one. So, if you really want to screw with the >user's minds you could conceivably have different command sets in >different parts of your world. (something along Zelazny's Amber... the >physics are different in the place you've warped to so the commands, >spells, etc are different). Wait, it gets better... if we want to link up >muds, there are ways that one mud could export its parser object to >another so, if you wanted, you could process commands for a user in the >remote mud locally (not sure why you'd want to, but hey.... explore the >possibiliteis :) cf COOL and its YO protocol. -- J C Lawrence Internet: coder@null.net ----------(*) Internet: coder@ibm.net ...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...