December 1999
- Neural Networks as the AI system for a MUD? PartyG2816@aol.com
- Neural Networks as the AI system for a MUD? claw@kanga.nu
- Neural Networks as the AI system for a MUD? Marc Bowden
- Neural Networks as the AI system for a MUD? Lo, Kam
- Neural Networks as the AI system for a MUD? Marc Hernandez
- Neural Networks as the AI system for a MUD? Kræn Munck
- Neural Networks as the AI system for a MUD? Hans-Henrik Staerfeldt
- Neural Networks as the AI system for a MUD? PartyG2816@aol.com
- Neural Networks as the AI system for a MUD? Hans-Henrik Staerfeldt
- Neural Networks as the AI system for a MUD? Andrew Norman
- Neural Networks as the AI system for a MUD? Mik Clarke
- New member IronWolf
- Scenarios Chris Lloyd
- ColdStore J C Lawrence
- New AI Engine released Fabian
- New AI Engine released Steve Houchard
- New AI Engine released Bruce Mitchener, Jr.
- New AI Engine released Elysium
- AI's in MUDS and Online Gaming IronWolf
- AI's in MUDS and Online Gaming Matthew Mihaly
- AI's in MUDS and Online Gaming IronWolf
- AI's in MUDS and Online Gaming Ryan P.
- Garbage Collection Miroslav Silovic
- Capture of players. (was: Fair/Unfair? Scenarios) Kræn Munck
- Capture of players. (was: Fair/Unfair? Scenarios) J C Lawrence
- Capture of players. (was: Fair/Unfair? Scenarios) Chris Lloyd
- Biosystems (was Fair/Unfair? Scenarios) Richard Ross
- Biosystems (was Fair/Unfair? Scenarios) Philip Loguinov -- Draymoor
- Biosystems (was Fair/Unfair? Scenarios) Mik Clarke
- Biosystems (was Fair/Unfair? Scenarios) J C Lawrence
- Biosystems (was Fair/Unfair? Scenarios) Greg Miller
- Biosystems (was Fair/Unfair? Scenarios) Dundee
- Biosystems (was Fair/Unfair? Scenarios) Travis S. Casey
- Biosystems (was Fair/Unfair? Scenarios) Douglas Couch
- Biosystems (was Fair/Unfair? Scenarios) Marc Hernandez
- Biosystems (was Fair/Unfair? Scenarios) J C Lawrence
- Biosystems (was Fair/Unfair? Scenarios) Mik Clarke
- Ideas for dynamic worlds Nolan Darilek
- Ideas for dynamic worlds Chimera
- Ideas for dynamic worlds Ilya, Game Commandos
- Ideas for dynamic worlds J C Lawrence
- Ideas for dynamic worlds Nolan Darilek
- Ideas for dynamic worlds Joe Kingry
- Ideas for dynamic worlds David Morgan
- The GTS Library J C Lawrence
- Combat systems Neil Edwards
- Combat systems Kylotan
- Combat systems Kylotan
- Combat systems Chris Lloyd
- Combat systems J C Lawrence
- Combat systems Marc Spoorendonk
- Combat Systems Ben
- Combat Systems Raph Koster
- Metakit J C Lawrence
- Commercial Online Roleplaying Games (fwd) J C Lawrence
- Mud-Dev FAQ Marian Griffith
- Mass bannings (was The grass is always greener in the other field) AR Schleicher
- Game Balance: Statistical Analysis in MPORPGs Lovecraft
- Game Balance: Statistical Analysis in MPORPGs Koster, Raph
- Biosystems & simulation [RAMBLE] Ben Greear
- Souveniers Douglas Couch
- Souveniers Lovecraft
- Souveniers J C Lawrence
- Souveniers Raph & Kristen Koster
- Souveniers J C Lawrence
- Souveniers Raph & Kristen Koster
- Ideas for dynamically generated worlds Cynbe ru Taren
- Ideas for dynamically generated worlds J C Lawrence
- Balancing between anxiety and boredom (was Fair/Unf air? Scenarios (fwd) ) Sellers, Michael
- Online Migration and population mobility in a virtual gaming setting - Ultima Online J C Lawrence
- lockpicking Matthew Mihaly
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Sellers, Michael
- Optimized Object Storage Matthew Mihaly
- Optimized Object Storage J C Lawrence
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Sellers, Michael
- Optimized Object Storage Ian Macintosh
- The Habitat Papers are missing J C Lawrence
- Waving Hands -- Debian's Spellcast for Linux J C Lawrence
- Waving Hands -- Debian's Spellcast for Linux Dan Shiovitz
- Waving Hands -- Debian's Spellcast for Linux Travis Casey
- Waving Hands -- Debian's Spellcast for Linux J C Lawrence
- Upload to ftp.kanga.nu J C Lawrence
- Farewell again Ilya, GC
- Telnet Protocol and Winsocks method
- Telnet Protocol and Winsocks J C Lawrence
- Telnet Protocol and Winsocks cg@ami-cg.GraySage.Edmonton.AB.CA
- Telnet Protocol and Winsocks Ilya, GC
- Telnet Protocol and Winsocks J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Ben Greear
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Christopher Allen
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Christopher Allen
- MUD source licensing: beyond GPL? (fwd) J C Lawrence
- MUD source licensing: beyond GPL? (fwd) Matthew Mihaly
- Classes and Races and more (a BIG list) (fwd) J C Lawrence
- Originality/Points of Reference (was Classes and Races and more (a BIG list) (fwd)) Richard Ross
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Justin Rogers
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Justin Rogers
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Christopher Kohnert
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Matthew Mihaly
- Collecting ideas for a MUD server... (fwd) Jon A. Lambert
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Wesley W. Terpstra
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Wesley W. Terpstra
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Originality/Points of Reference Ian Klimon, Esq.
- Job Openings - Mud Engineering Christopher Allen
- PGP player certificates (was: collecting ideas...) Wesley W. Terpstra
- PGP player certificates (was: collecting ideas...) David Bennett
- Re[4]: The grass is always greener in the other field Travis Casey
- Re[4]: The grass is always greener in the other field J C Lawrence
- Re[4]: The grass is always greener in the other field Adam Wiggins
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Wesley W. Terpstra
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) J C Lawrence
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Marc Bowden
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Greg Miller
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) cg@ami-cg.GraySage.Edmonton.AB.CA
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Hans-Henrik Staerfeldt
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) cg@ami-cg.GraySage.Edmonton.AB.CA
- PGP confusions hopefully resolved (was: collecting ideas ...) Wesley W. Terpstra
- MUD-Dev digest, Vol 1 #237 - 9 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #237 - 9 msgs J C Lawrence
- MUD relevant references (was: The grass is always greener...) Ola Fosheim Grøstad
"Bruce Mitchener, Jr." wrote:
> Ola Fosheim Grøstad wrote:
> >If there are other list
> >members who feel like getting up to date on database/relation/OO research,
> >then maybe we could spawn off a little short term project, ending up with a
> >survey-paper beneficial to the mudding community?
>
> I seem to recall suggesting this type of thing back in the DevMUD days. :)
> That suggestion went exactly nowhere.
Well, I am not going to repeat what I suggested back in the DevMUD days! >;)
> That said, on some of these types of
> topics, I'm learning about them for my current project to try and make some
> decent decisions on things. I'm just not into writing papers on that
> research due to lack of time and no real demand.
Well, I didn't mean a peer-reviewed paper published in some fancy journal.
Anyway, a list of references and maybe a short evaluation of their relevance
could be helpful.
> The people doing this type
> of server often are already willing to do the research. Those unwilling to
> do the research tend to not be doing the type of server that might require
> that research. I've probably insulted any number of people now.
I am of the type that is willing to do the research, but unwilling to
implement it until I really know what I want. Which I still don't. :) I
think I know which direction I am ready to move though.
> I'm open to collaborating with people who are skilled in these areas though.
What kind of collaboration? I am not skilled. That's why I am currently
reading journal papers!
Some context: I basically want a flexible MUD. I don't want a design to be
made in concrete, so I want softer building materials. I think what I might
want to do in the long run is to move towards some kind of flexible E-R
(entity-relationship) model, with some kind of inference engine on top. The
current plan is to look at the possibilities and then get down to earth for
a while...
One issue, if you want flexibility, is to not be too dependent on the
representation of state (that is variables, objects etc). This may be
achieved with heavy functional encapsulation and reuse of prior calculated
expressions for performace reasons (one possiblity is to use hashed
lookups). Although I've always been facinated by the esthetical aspects of
functional programming, I have little actual experience as imperative
programming and OO feels more natural for most problems. Nevertheless, I
decided to browse the Haskell documents, in which I found a paper on
programmer efficiency. Haskell did reasonably well, but something called
Relational LISP did better. The Haskell-loving authors attributed this to
prior training. I got curious about this, but was unable to find much on
Relational LISP on the net. I found something called AP5:
AP5 is an extension to commonlisp which allows users to
"program" at a more "specificational" level. By this we mean that
it allows you to focus more on what you want the machine to do
and less on the details of how. AP5 is a compromise between
lisp and the gist specification language.
Which, after browsing the docs, might not be exactly what I want, but then
again, I am not quite sure exactly what I want. Or rather, I may know
exactly what I want, but I don't know if it is feasible or how to implement
it with reasonable performance. So for the past couple of weeks I have spent
some of my spare time with the last few years of issues from journals
published by Springer Verlag, and I have also peeked at some of the ACM
journals. Most of them are too narrow or too far from having practical value
of course. A few have peeked some interest in me though:
--------
"Deductive Database Languages: Problems and Solutions", MENGCHI LIU,
University of Regina, ACM Computing Surveys, Vol. 31, No. 1, March 1999
Abstract: Deductive databases result from the integration of relational
database and logic programming techniques. However, significant problems
remain inherent in this simple synthesis from the language point of view. In
this paper, we discuss these problems from four different aspects: complex
values, object orientation, higher-orderness, and updates. In each case, we
examine four typical languages that
address the corresponding issues.
My comment:
As this is a recent survey it may be an invaluable timesaver. A language
called ROL (Rule-based Object Language) peeked my intersts, but I haven't
had time to look up the reference and look more closely at it yet. None of
the languages were exactly what you would want to build a MUD with of
course.
--------
"The State of Change: A Survey"
Anthony J. Bonner 1 and Michael Kifer 2
in B. Freitag et al. (Eds.): Transactions and Change in Logic DBs, LNCS
1472, pp. 1{36, 1998. (Springer-Verlag)
Abstract: Updates are a crucial component of any database program-
ming language. Even the simplest database transactions, such as with-
drawal from a bank account, require updates. Unfortunately, updates are
not accounted for by the classical Horn semantics of logic programs and
deductive databases, which limits their usefulness in real-world applica-
tions. As a short-term practical solution, logic programming languages
have resorted to handling updates using ad hoc operators without a log-
ical semantics. A great many works have been dedicated to developing
logical theories in which the state of the underlying database can evolve
with time. Many of these theories were developed with speci c applica-
tions in mind, such as reasoning about actions, database transactions,
program veri cation, etc. As a result, the di erent approaches have dif-
ferent strengths and weaknesses. In this survey, we review a number of
these works, discuss their application domains, and highlight their strong
and weak points.
My comment:
I am going to force myself to read this. Promise! =8-X
--------
"Randomized Binary Search Trees"
CONRADO MART ´ INEZ AND SALVADOR ROURA
Universitat Polite `cnica de Catalunya, Barcelona, Catalonia, Spain
Journal of the ACM, Vol. 45, No. 2, March 1998, pp. 288 323.
Abstract: In this paper, we present randomized algorithms over binary search
trees such that: (a) the insertion of a set of keys, in any fixed order,
into an initially empty tree always produces a random binary search tree;
(b) the deletion of any key from a random binary search tree results in a
random binary search tree; (c) the random choices made by the algorithms are
based upon the sizes of the subtrees of the tree; this implies that we can
support accesses by rank without additional storage requirements or
modification of the data structures; and (d) the cost of any elementary
operation, measured as the number of visited nodes, is the same as the
expected cost of its standard deterministic counterpart; hence, all search
and update operations have guaranteed expected cost 2(log n), but now
irrespective of any assumption on the input distribution.
My comment:
I guess this needs no comment. Except it is amazing that they have
improvemed something as basic as this as late as 1998. I might actually want
to use it.
--------
"An Optimal Algorithm for Approximate Nearest Neighbor Searching in Fixed
Dimensions"
SUNIL ARYA & al.
Journal of the ACM, Vol. 45, No. 6, November 1998, pp. 891923.
"Undirected Single-Source Shortest Paths with Positive
Integer Weights in Linear Time"
MIKKEL THORUP
Journal of the ACM, vol. 46, No. 3, May 1999, pp. 362394.
My comment:
I doubt that I will ever need their approaches, but they may be worth a
peek. Even linear time may be expensive for a mud.
--------
Active Database Systems
NORMAN W. PATON AND OSCAR DI ´ AZ
ACM Computing Surveys, Vol. 31, No. 1, March 1999
Active database systems support mechanisms that enable them to respond
automatically to events that are taking place either inside or outside the
database
system itself. Considerable effort has been directed towards improving
understanding of such systems in recent years, and many different proposals
have
been made and applications suggested. This high level of activity has not
yielded a
single agreed-upon standard approach to the integration of active
functionality
with conventional database systems, but has led to improved understanding of
active behavior description languages, execution models, and architectures.
This
survey presents the fundamental characteristics of active database systems,
describes a collection of representative systems within a common framework,
considers the consequences for implementations of certain design decisions,
and
discusses tools for developing active applications.
My comment:
If I was writing a generic database then this would have been more useful
than it apparently is to me right now. As far as I can tell seems to be very
much influenced by prior practice. It may be a resource for ideas though.
--------
"Index nesting an efficient approach to indexing in object-oriented
databases"
Beng Chin Ooi 1 , Jiawei Han 2 , Hongjun Lu 1 , Kian Lee Tan 1
The VLDB Journal (1996) 5: 215228
My comment:
Sounded more interesting than it was, but I am not very disk centric. If you
intend to use B+-trees and such, yes maybe you should look at it. This is
basically about "H-trees" (Hierarchical trees) which affords indexing of
subclasses and such.
--------
"Conceptual classes and system classes in object databases"
Elvira Locuratolo, Fausto Rabitti
Acta Informatica 35, 181210 (1998)
My comment:
If your design involves multiple inheritance, but you need single
inheritance in the implementation for performance issues. Then this might be
worth peeking at.
--------
"Garbage collection in object-oriented databases using transactional cyclic
reference counting"
P. Roy 1 , S. Seshadri 1 , A. Silberschatz 2 , S. Sudarshan 1 , S. Ashwin
1;?
The VLDB Journal (1998) 7: 179193
My comment:
Interesting reading for me as my knowledge about garbagecollection is
marginal. As often is the case with academic papers: if you don't want the
paper, then maybe you want their references.
--------
"Byzantine quorum systems"
Dahlia Malkhi, Michael Reiter
AT&T Labs Research
Distrib. Comput. (1998) 11: 203213
My comment:
Fault tolerant distribution is really not my top priority, but somebody on
the list may have use for it...
--
Ola Fosheim Groestad,Norway http://www.notam.uio.no/~olagr/ - Re[6]: The grass is always greener in the other field Travis Casey
- Embedded languages, object persistance... ack. Joe Kingry
- Embedded languages, object persistance... ack. cg@ami-cg.GraySage.Edmonton.AB.CA
- Embedded languages, object persistance... ack. Laurent Bossavit
- Embedded languages, object persistance... ack. Kevin Littlejohn
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. Jay Carlson
- Embedded languages, object persistance... ack. Jay Carlson
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. icecube@ihug.co.nz
- Embedded languages, object persistance... ack. Kevin Littlejohn
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Rahul Sinha
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Ola Fosheim Grøstad
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Kevin Littlejohn
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Phillip Lenhardt
- Storing tokens with flex & bison Dominic J. Eidson
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Chris Jones
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Ola Fosheim Grøstad
- Storing tokens with flex & bison Per Vognsen
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Chris Turner
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison Greg Miller
- Storing tokens with flex & bison J C Lawrence