Releasing Stackless Python 2.6.1

I've spent the last seven and a half hours building and releasing Stackless Python 2.6.1. For the last release or two I have been able to get CCP to let me allocate working time to do this, since their framework embeds Stackless, but I haven't been paying attention to the python-dev mailing list and I've been ignoring the other mailing list where the release discussion takes place so I wasn't able to schedule the working time ahead of the fact. Here's a summary of the effort which is involved in this process.

The first step is to merge in all the changes up to the point where Python 2.6.1 was released, into the corresponding Stackless branch:

• Worked out that revision 67220 was the last one integrated from the Python release26-maint branch.
• Integrated up to revision 67220.
• Had to edit conflicts in two files. 'configure' which is a generated file, reverted the changes to that and will generate it on a non-Windows machine after I check in the changes. 'typeobject.c' where a new function is being used called 'call_attribute' which is replacing the use of a generic call API function, this touches the Stackless "soft switching" changes.
• Compiled the source code in Visual Studio 2008 Professional. CCP have allowed me to install it at home in order to build Stackless there. There was an error in 'typeobject.c' where TortoiseSVN shat on the file and left merge information in place.
• Ran the standard unit tests. There were three failures and some stacktraces which looked dodgy after tests which didn't fail. I rebuild the source code with Stackless disabled and saw most of these again when I ran the unit tests again. The only remaining problem is a stacktrace which happens between 'test_cpickle' and 'test_cprofile' complaining about a recursion depth runtime error. Crossing my fingers that the problem is not in the pickling support, as that pickling isn't the most fun part of the Python code to debug.
• Ran 'test_cpickle' directly and it definitely prints out the stacktrace. Ran the unit test again with the verbose flag and saw that it was happening in 'test_issue2702' test within the 'cPickleDeepRecursive' test case. Hoping that that it's some verification of proper behaviour which doesn't make sense in Stackless. Well, the test says "This should raise a RecursionLimit", given that, this is just Stackless specific noise.
• I'm happy with the Python unit tests, now I need to run the Stackless unit tests. They all pass fine.
• The merge looks like a success. If I really wanted to be pedantic, I'd look into that Pickling noise. But given I am hoping to release Stackless Python 3000 or whatever the newfangled Python that was released is called, it isn't worth doing.
• Time to check it in, so I can check it out remotely on a Linux box to fix the 'configure' problem.
• The changes to 'configure' were negligible. Checked it in and made a tag for the 2.6.1 state.

In order to build the Windows installer, I need to build all the dependencies like bzip2, OpenSSL and so forth:

• Exported the Stackless 'release26-maint' within a sub-directory of an arbitrarily named 'export-release26-maint' directory, so I can isolate the external dependency builds there. The build in the 'release26-maint' directory looks in its parent directory for those dependencies.
  
• Did a debug build within 'export-release26-maint/release26-maint' as I expected the buildbot external dependency building process to use Python.
• Entered the 'export-release26-maint/release26-maint' directory and executed 'Tools\buildbot\external.bat' file which takes care of the tedium of obtaining and building these dependencies. Python scripts weren't actually involved. Thanks to whomever came up with this timesaver.
• Rebuilt the debug build, with the dependencies theoretically in place, it should now do a full compilation.
• The '_ssl' and '_hashlib' projects failed due to their not being able to find some 'nasmw' command. This is addressed in the _ssl section of 'PCbuild/readme.txt'. It mentions the need to install nasm and points to the relevant web site. I've been here before and the 'nasmw.exe' executable is a myth, I've never been able to find it. I just download the binaries with the 'nasm.exe' executable and rename that one, placing it in my 'system32' directory. It seems to allow the compilation to proceed, so fingers crossed. Watching some Countryfile and drinking a delicious diet Pepsi Max while I am waiting. I've would never accuse the Python developers of writing 100% reliable or accurate build instructions, sometimes a lot of faffing around is involved wondering how they ever managed to make a release in the first place. I'd moan on about it a bit more, but let's be honest, I'm not going to bother submitting patches.
  
• '_ssl' compiled, but there's still one failure. Rebuilt the solution and the now compiled '_ssl' allowed '_hashlib' to now compile.
• This means I have successfully built a debug Stackless Python 2.6 and all its dependencies. I'm now going to build the release version and then run the unit tests for each. Maybe there will be some problems with the unit tests which involve the dependencies, or in the release build in ways which were not present in the debug build.
• The buildbot script for some reason does not do release builds of tcl and tk. I need to do both manually. In the case of tk, it wasn't enough to use the same command lines from the 'readme.txt'. I also needed to give a command line argument of 'TCLDIR=..\..\tcl-8.5.2.1'.
• Running the Python unit tests with the release build. I needed to take the tk and tcl dlls from my existing Python 2.6.1 install and put them in the 'PCbuild' directory to run the 'test_tcl' test suite. The test runs were consistent with previous results.
• Running the Stackless unit tests with the release build. The tests all passed successfully.
• Running the Python unit tests with the debug build. Acceptable.
• Running the Stackless unit tests with the debug build. The tests all passed successfully.

Now to actually build the installer:

• The first step is to run 'Tools\msi\msi.py'. This, as usual chokes, as it depends on the pywin32 extensions. The only way I know to get these in place are to install them into my existing Python 2.6.1 installation, and then to copy the 'site-packages' directories into the corresponding sub-directory in my build directory.
• 'msi.py' expects to find a directory matching 'tcl8*' above the 'release26-maint' directory. However, the directory is actually named 'tcl-8*', so.. I need to fix this inconsistency in 'msi.py'. I made the same fix for tk while I was there. Tix is also specified there, but I don't know where that comes from, so I've commented it out.
• 'msilib.py' errors in 'make_short' with an assertion. This always happens, and is meaningless, although I forget the reasons why. I comment this out. Why things like this aren't hit by the Python releasers, I do not know.
  
• 'msi.py' errors unable to find 'python26.chm'. I'm not even going down this rabbit hole again. Even when I can get the separate documentation build process to generate the chm prerequisites, the tool to generate the chm file chokes on the input. I just grab it from the Python 2.6.1 installation. There's no Stackless customisation to the documentation anyway. This file in the installation is coincidentally called 'python261.chm' in any case.
  
• This reminds me I need to customise 'msi.py' and have it do an 'official' build. This should get it looking for the '261' chm file I epxect. Now 'msi.py' is choking on there not being a suitable uuid entry for '2.6.1150'. This uuid was added days later to the 'uuid.py' module, so I hacked it in. I can understand why this happened, there was probably a code freeze at the time.
  
• Now it is asking me for 'python26.chm'. But the one which came with the install was 'python261.chm'. I want to conform to the existing install, but.. I'm getting weary so I will just rename the file to give it what it asks and move on.
• 'cabarc.exe' not found in registry (it never is). And it fails to find 'cabarc.exe' in the PATH environment variable. I executed the platform SDK 'SetEnv.cmd' script and it added the entries I needed.

Now I have a 'python-2.6.1.msi' installer, which is actually for Stackless. I'll rename it and put it up on the Stackless downloads web page.

Notes on MMORPG Tycoon

I stumbled across MMORPG Tycoon while checking out the recent TIGsource competitions. It was one of the entries in the now finished procedural generation competition.


What made the game stand out from the rest was the use of vector graphics. It was made using a framework called VectorStorm, which was also created by its author. It turns out VectorStorm was written for this purpose, to allow programmers to prototype games without having to source graphics to make them meet a minimum standard of presentability.

The screenshot above is the view of the game world. The various elements featured are:

• Subdivided areas are the different zones in the game world.
• Numbers labelling a zone are the level ranges which it is suitable for.
  
• Houses are the towns.
  
• Squares are starting areas.
• Circles are respawn points.
• Dots are the individual players within the game. In order to see these, you need to zoom right in using your mouse wheel.
  

The management of the abstract simulated world doesn't do much for me in and of itself. I find it hard to reconcile what is going on in the world within the visible level of abstraction. What interests me about this game is that the abstract view it provides resembles something I have wanted for my MUD.

Hand coding rooms and the linkages between them is an approach I consider unnecessary. As is building a representation of the same with data. I want a procedurally generated landscape, where the generated world is built upon. Rooms are just a view of a position you might be located at, constructed on the fly. We did an implementation of this on our MUD "Nameless Sorrows" back in the late nineties.

In order to build such a game world, you would be better off with an interface which better visualises it. Not text. Perhaps a 2D view in the spirit of what MMORPG Tycoon provides. And being able to take that view and extend it to view the live state of the simulation running within the game world is a natural next step. And, again, this would be in the spirit of what MMORPG Tycoon provides.

I don't have much interest in MMORPG Tycoon as a game. But as a prototype which inspires me to work on similar ideas for my own project, it interests me a lot.

PyCon 2009: CCP related talk proposed

I submitted a talk proposal for PyCon 2009. It's title is "Making games in Python - Tools and techniques at CCP". It's intended to cover all the ways we have customised our framework in order to make working with it more productive, and easier. From the unique ways in which we do our unit testing, to how we use code reloading and more.

Here's hoping it gets accepted! :)

mudstats.com

Link: Barriers to commercial MUDs

Mike Rozak: [Link]

Looking at MUDStats.Com shows a "peak concurrent users" of 9000-ish for known muds (as known by mudstats). I assume they missed some; maybe the peak concurrent users is 14,000. For a popular pay-for-play MMORPG, you'd multiply this by around 5 to determine the number of paying players. For MMORPGs (and MUDs), multiply about 10x.

Nice. I wonder what other interesting MUD related sites are out there..

Something resembling an Octree: 2

My expanding octree implementation is now cleaned up and checked into a random SVN repository.

I thought I might as well flesh it out and get it to a polished state, as there are a few of my projects for which that hasn't been done. My Gmail backup script is one that badly needs a GUI added to it, for instance.

It has always been a mystery to me that people actually used the Gmail backup script, as it just dumps backed-up emails as pickles. As such, anyone who uses it either doesn't care that they don't know how the emails are stored, or they are willing to do the extra work required to work with the dumped files.

Something resembling an Octree

There is an interesting thread on LPMuds.net about working around the limitations of the MudOS dictionary type (in LPC a dictionary is called a mapping). The problem is that a mapping can only have 64000 entries. The proposed solution is to make an MD5 hash of the string representation of a 3D position, break it up into substrings and index each substring as a mapping entry under the preceding one.

Unfortunately, this lead to me implementing something resembling an Octree in Python, aimed at limiting the number of entries it puts in any given dictionary to 64000 at most.

All of the octree implementations I have seen in the past have to have a predetermined maximum size, within which objects are placed, subdividing the current quadrant into child quadrants as needed.

My implementation takes a different approach and starts with a predetermined minimum size, expanding as the need to place objects outside of the current quadrant arises. It is not fully complete, and needs a little extra work to get it into a usable state. But the guts of it are there.

I'm not really sure what to think of this code. Then again, it's past my bed time.

Link: http://pastebin.com/f19686a59

Blog syntax highlighting: SyntaxHighlighter

I've been wanting a Javascript based purely client-side syntax highlighting solution for a while. In the past, I've used Python to HTML scripts and other similar things.

SyntaxHighlighter looks pretty good.

import stackless
import traceback

def f():
    while 1:
        pass

stackless.tasklet(f)()

while stackless.runcount > 1:
    # If any tasklet runs for too long, kill it.
    t = stackless.run(100000)
    if t is not None:
        traceback.print_stack(t.frame)
        t.kill()

PyPy: Using the Visual C++ Toolkit Compiler 2003

I've been meaning to experiment with PyPy for a while. There are a couple of projects I have in mind which might find some of the functionality it provides useful:

• A text-based MUD programming environment using the sandboxing to allow programming and invocation of Python.
• A reimplementation of the MudOS driver using translation to interpret LPC.
  

Before I start playing with it, I want to build the C translation of the PyPy Python interpreter with Stackless functionality. I'm going to note the steps I had to take, in order to get this to work in this post, for the purpose of reference.

The compilation PyPy does through its distutils module needs to be done with the same version of Visual Studio that the Python installation it is using was compiled with. Visual Studio .NET 2003 (7.1) is the proper Windows compilation environment for Python 2.5. I don't have VS .NET 2003 but I do have the free MS Toolkit Compiler set up for Python development. In order to get distutils to recognise it, I followed the instructions which Mike Fletcher provides.

I've already installed the pre-compiled Boehm garbage collection files, which the PyPy web site provides.

The command I need to execute in order to translate PyPy the way I want is: "c:\python25\python.exe --stackless translate.py --opt=3 targetpypystandalone.py".

It errors to a debugging prompt claiming it can't find 'windows.h'. This is my fault due to the way I have the MS Toolkit set up. In order to compile things with it I need to open the Microsoft Platform SDK for Windows Server 2003 R2 / Windows XP 32 bit / Retail build environment DOS window, then execute the BAT file which adds the environment variables for the Toolkit over and above that. I had just opened a normal DOS window and executed the BAT file before trying to compile.

It errors to a debugging prompt claiming it can't find 'zlib.h'. Apparently some option is set to enable zlib support in the process. I can't immediately see how to turn it off and I am not sure that I don't want zlib support. So I download zlib 1.2.3 and compile the source code, adding its path to the 'Include' environment variable and restart the compilation process

It errors to a debugging prompt claiming it can't find 'bzlib.h'. Same deal as with zlib. I already have the bz2 downloaded and compiled, as it is a dependency need for compilation of Python, which I need to do for Stackless. So I just add its path to the 'Include' environment variable and restart the compilation process.

It errors to a debugging prompt claimign it can't find 'bz2.lib'. This makes sense. However, one problem is that this is not what the lib is called in the output of the build process in my environment, it gets compiled as 'libbz2.lib'. I copy and rename it to 'bz2.lib' and add the path to the 'Lib' environment variable and then restart the compilation process.

Success. The compilation proceeds and during the process, a mandelbrot is drawn with characters in the DOS window as the PyPy web site describes. It is still compiling at this point and lots of generic looking cack is being printed to the window.


Updated 17th September 2008:

The compilation process errored. I am compiling against a Stackless Python installation. This includes Stackless include files which are in a subdirectory, and I didn't add that subdirectory to my 'Include' environment variable. So the compilation failed after all that time, because of this.

There were two warnings in the compilation at the point of failure, where unknown command line options were found: '-fprofile-generate' and '-frandom-seed=testing_1.c'. This seems to be harmless, so ignoring them.

Updated 18th September 2008:

Another error, where 'zlib.lib' could not be found. There's a pattern emerging here. Added the zlib directory to the 'Lib' environment variable.

Next 'python25.lib' could not be found. Added the Python installation libs directory to the 'Lib' environment variable.

End result is a compiled 'pypy-c.exe'. Ignoring my laziness in populating the 'Lib' and 'Include' environment variables with entries which I should have known were needed, the process was as painless as a MS Toolkit compilation can be expected to be.

The next step should be creating a very simple frontend and getting that to compile.

rec.games.mud.lp: reading list 2

Having trawled through thousands of threads, the transition from USENET newsgroups to a range of disparate forums as a location for MUD discussion, doesn't seem like much of a loss. The newsgroups were filled with a range of off-topic posts, spam and most of the threads which are on-topic are rife with misunderstandings and flaming. Forums however, have moderation and sub-forums for posts on various topics to go. The only downside to forums is that there are many of them, and similar topics of conversation can be located in different forums. It isn't as easy to remember to visit all the distinct locations as it was to just go to the relevant newsgroup.

In the first LP newsgroup thread listing I did, there was a thread about griefing and griefers. One of the posts noted that all you need is one griefer to run the MUD for a lot of people. In a way, it reminds me of one particular poster the LP newsgroups. In pretty much every thread you'll find him posting numerous overly aggressive responses, getting in the way of the discussion. This is a pity as it seems like this set back the discussion consistently. In my books, its a vote in favour of moderation.

1997-04-22: Ressurect: Future of Mudding - User Interfaces and Distrbuted MudServers

Following an earlier trainwreck of a thread titled "Future of Mudding", this is an attempt to resurrect it more productively.

Distributed MUD drivers as a solution for lag. The need for graphical clients, due to the "dauntingness" of the command-line interface. Difficulty factor in writing code for a distributed MUD. Use of a DB backend as a basis for a distributed MUD.

1997-07-11: LP: How does it work?

Implementing a pseudo-language to dynamically transform MUD behaviour (wtf?). LP driver VM implementation/optimisation notes. Runtime morphism, for instance the ability to dynamically change running code to affect game behaviour. The need for downtimes/reboots for game maintenance.

1997-07-25: DLPC: A proposal for distributed LPC

Suggests that distributed LPC is important for the future. That distributed LPC is more appropriate than distributed support in MudOS specifically, because then different drivers can implement it, not just MudOS. Handing off players from MUD to MUD.

Bickering about the practicalities of using CORBA and whether people know what they are talking about. Intermud presence as a measure of mudlib popularity.

1998-01-23: Bandwidth Usage of MUDS

The regularly featured "How much bandwidth do MUDs use?" thread.

Cross-post: rec.games.mud.admin

1998-02-02: What do you think of Introductions?

Otherwise known as recognition systems. Appeal of it, or lack thereof to players. Degrees to which it can be implemented. Interesting gameplay which it facilitates, like amnesia and forgetting people's names. Breaks down into implementation specific discussion related to the resource usage of noting who knows who.

1998-01-29: Mudlib security issues

Common ways mudlib security is compromised. Weaknesses of stack-based security. Discussion about stack-based implementation details.

Bickering over the implementation of better security systems. That to write your own stack-based system rather than using the Lima Bean one, is to needlessly rewrite the wheel. That Shattered Worlds invented and posted a security system like this over five years ago. That because no-one knew about it or saw it, it didn't count.

1998-04-08: Diku vs. LP from the player's POV

Eventually moves to discussing exits and directions. Having the server doing the movements as part of an action to go to a landmark, rather than the player entering the movement commands needed to get there themselves. Drifts to classless systems. Skill systems.

Cross-post: rec.games.mud.admin

1998-07-06: MudOS bug? all_previous_objects()

A discussion about implementation details related to writing a stack-based security system.

1998-07-08: Player base thinning

More navel-gazing about the decrease in popularity of text-based MUDs.

1998-08-24: Coder shortage

There are a lot of MUDs asking for coders, and yet few seem to offer to teach people to code. Quality MUDs don't need to ask for coders as people actually want to code there. The same situation exists for builders. That builders on LP MUDs need to be coders anyway. How hard it is to actually train a coder.

Cross-post: rec.games.mud.admin

1998-09-28: Are LPMuds Dead? Or Where to Next?

That Java is a better bet in the long-term. Discussion about other languages which allow code reloading.

1999-03-24: Future of MUDs

Declining player numbers yet again. Uninteresting stock MUDs being responsible for this.

1999-05-04: Threshold RPG = Copyright Infringment?

The LPmud license prohibits the driver from being used for commercial purposes. Threshold has been a long-term LP MUD. Diverges into other related topics, like DGD licensing terms, and Skoto's licensing terms.

Well, this is now done.

Current position: 10th September, 2008.

rec.games.mud.lp: reading list 1

Now that I have gathered together all the threads posted to rec.games.mud.admin which were interesting enough to take note of, the next forum on the cards is rec.games.mud.lp.

On a preliminary note, I get the feeling that a lot of the threads in this newsgroup are too implementation related. I find little value in these sort of posts, and a lot of it is quite dated given the aging of LPmud/MudOS over the years.

1991-11-20: Graphical Mud - How are they going?

A short thread where an early 3D MUD is mentioned. A 3D world, with a custom client, based on an LP driver.

1992-01-30: Building tools and doc files

The downsides of generated rooms. Pros and cons of different methods of training creators.

1993-02-21: What would you like to see?

.. as in, in the ultimate MUD driver. Multiprocessing. Blocking functions in place of the asynchronous offerings MudOS has ("call_out", "input_to", ...). The suitability for cooperative threading for games like MUDs. Pre-emptive versus cooperative threading. Distributed MUDs.

1993-03-12: Magic

A magic system as a procedural effect, where components have characteristics and their combination determines the result. The unpredictability of such a system. The ability to effect the game world. That the more dynamic a game system allows the creation of things to be, the more difficult is to create them.

Pinkfish was doing it back before we knew we wanted to..

1993-08-24: Permanency in LPs.. does it work?

A persistent world, where nothing respawns and player changes remain. Hard enough to get an area coded, let alone when with one play through it becomes obsolete. Player created content. Comparison of player created room quality to that of creator created rooms.

1993-11-06: Multi-threaded MUD driver

More discussion on the repercussions of adding some form of multi-threading to an LP driver. An interesting point this thread brings up relates to usage of an euid based security system.

1993-11-06: MUD Economies

Description of a "proper economy" in a MUD by the name of Shattered Worlds.

1994-11-24: Mudlib security

The transition from uid-based security to stack-based security, as a more secure approach, after changes in MudOS. Rather than checking the player who did the action, or the previous object in the call stack, instead checking all the objects in the stack.

1994-06-14: Connecting MUDs

Having interconnected MUDs. Being able to walk between MUDs. Imbalance between the participating MUDs. Duplicated player names.

1995-08-19: Some Economical Thoughts

Proposal for an economy based MUD with a wide range of player professions, harvesting of raw resources and so forth. Making armour from processed corpses.. wtf?

1996-06-18: Realism in MUDs

A pretty good thread, with very little flaming. Confusing realism with tediousness. Assertions that realism is at the expense of playability. The assumption that a realistic implementation has to be done in an unplayable way. Juggling of inventory, in terms of what is being held, carried and so forth. Reference to Gemstone III in the case of specific implemented examples of realism.

1996-08-19: Realistic MUDs: Mob behavior

Starts with giving NPCs a life, engaging in activities for a reason. Then devolves from this into discussion of existing limited approximations which aren't anywhere near as hard to implement. Wanders into introduction systems. Rumour systems. Adding continuity by doing away with resets.

Cross-post: rec.games.mud.admin

1996-12-08: Developing a graphical MUD in Java / java and dynamic reloading

Some back and forwards about the practicalities of code reloading in Java at the time. Comparisons with LPC, within which this is easy. Class reloading is the main thing that my code reloading module allows for in Python.

Cross-post: rec.games.mud.admin

1997-01-03: Player Killing / Intelligent monsters / Ranged attacks

How to ensure that player killing is balanced. Realism without impacting playability. Town/city guard behaviours. Bounties (and how they turned out on Discworld). Griefing and site-banning griefers. Justice systems.

Appeal of killing players over killing NPCs. Ways to make NPCs more intelligent.

Different types of ranged weapons. Feeling of helplessness/unfairness felt by players when attacked remotely. Taking cover.

1997-01-25: End of Nightmare Mudlib Development

Entitlement causes George Reese to withdraw his Nightmare mudlib from circulation.

Current position: July 30th, 1997.

rec.games.mud.admin: reading list 5

Looking back at the last summary post I made, it feels a little like I was "phoning it in" to a degree. I'll try and give a little more detail in this section. I am also wondering if I should be adding a little more detail, for instance the number of posts in each thread.

1999-12-23: Promoting mudding in general

A proposal for a community effort to promote mudding. Discussion about the perceived value of a free-to-play MUD. The appeal of graphics again. Comparison to Ultima Online. Suggestion of some approaches after which the thread peters into waffling about the support different MUDs have for colour.

2000-02-20: Dungeon runners is getting even easier

No content of note. Just thought it was interesting to see that there was once a MUD with the Dungeon Runners years before the MMO came about.

2000-02-29: After how much coding can you release your own dist

Addresses taking an existing code-base and changing it a subjective amount, then deciding it has been changed so much it no longer resembles the work it was derived from.

Unfortunately, where the poster says "have altered it so that pretty much all that remains original is the area format", in my experience people who ask this question tend to have a detached view from reality of the scope the changes they made. If it were up to me, I would say never.

2000-03-05: I am a builder

The thread starts off with someone asking for a building position on a MUD. The peanut gallery chimes in with pithy commentary. Then the thread gets into a discussion about the proper way to write room descriptions. Should "you" feature in a room description? Some consensus that it is bad in a static room description.

This gels with what I remember from reading something on Discworld MUD long ago, what if someone is being scryed and a third party sees a description of the room they are in. Then it is going to be confusing, with any use of "you" referring to the target (first party with regard to the description) being scryed.

2000-03-01: Gay Programmers Wanted

This thread isn't worth reading in and of itself, but there are some interesting posts made within it. The best quote I include below. Only the first dozen or so posts stay on topic, after which the thread drifts.

George Reese [post]: "Although, one wonders about the need for a mud targetted at gays since, face it, aren't all muds these days just a bunch of teenage guys pretending to be women and having mud sex with each other?"

Right on George, right on.

At around this point, the "Shade" problem became evident in this newsgroup. I will avoid covering with this and note that this was a pedophile who ruined a lot of good threads both by his presence, mention of his predilections and reflection on both of these things by others. It was hard to find a thread which wasn't tainted. Or at least, that was how it seemed to me at the time.

2000-07-04: Need interesting threads (shade-free)

A thread I started after a long shade-free drought in the newsgroup. Exhibits the Google Groups problem, where a response appears before my post in the archive.

Initial post suggests a range of topics of interest to me. The superiority of layered 2D to actual 3D implementation of a game world. Whether the compass directions were a design flaw or a band-aid for problems with the text-based media itself.

2000-08-29: Declaring the Rights of Players

A topic brought to the newsgroup from the MUD-Dev mailing list by Raph Koster. This is not a topic whose discussion I found interesting, so is not summarised, but is included for the sake of completeness.

2000-10-03: Realistic travel times in muds (shade-free thread)

Covers methods of creating the feel of realistic travel taking time, including varying definitions of what realistic means in this context. Dynamic room descriptions. The scale of movement time to in-game world time. Justification for different travel time in different locales (crowds in the city = slower, uncrowded countryside = faster). What players would do during the long travel times (be logged off?). Scripting of character behaviour while its player is logged off. What would players do if magic were arcane and rare? Action and fun while online, your character does the grind while you are offline. Definitions of playability and the repercussions.

2000-11-26: A Discussion of what makes a good RP MUD

Starts with a subjective list posted by the thread starter. Whether RP has to involve good versus evil. Roleplaying professions. The potential of soap operas as inspiration.

2001-12-18: What is a good Description?

Use of 'you'. Forcing emotion on the player. Assuming things about the player.

2002-03-07: Advances to MUD's

A blind query about what should be done differently. Make as much as possible configurable online. Use of database backends. Mapping of an object model into SQL. Use of web UI to make character creation or building easier/better.

2002-05-02: Original MUD Association?

A suggestion that people creating original MUDs band together to share resources, promote their games and more. Subjectiveness of originality. Measuring achievement as a membership qualification. Diverges into value of writing a codebase from "scratch".

2002-09-09: Text vs Visual - Are UO, EQ, and DAoC killing text-based muds?

A short thread about the possible death of MUDs. Allusions to other subjects which are supposedly strangling their competition. References to MUD listing numbers over time at relevant websites.

2002-10-23: Goodbye RGMA

Mock announcement of the official death of this newsgroup given the lack of traffic. Discussion about where the discussion went. Surprisingly, there are no mentionable posts made after this point.

Current position: September 3rd, 2008 / done.

LPMuds.net: VM to Demo LPC Muds

Link: VM to Demo LPC Muds

I don't know about you, but compiling MudOS has never been a pleasurable activity for me. There was a time when I considered the *nix compilation process a character building measure, e.g. compile, encounter error or missing package, recompile, repeat until an insurmountable problem is encounted or successful. But these days, I just don't have the patience for it. And the building of MudOS is complicated by the ability to configure features out of/into driver at compilation time, you need to have the right set for the mudlib you plan to use. Add to that my use of Windows, and the need to use something like MinGW and the pain adds up.

So the idea of having a VM, where someone else has taken the time to build the driver for each mudlib supported within it, is a very appealing one.

saquivor: [link]

As part of getting ready to actually getting restarted on my GUI tool, I decided to build a VM to run DS2 so that I can easily manage a DS2 setup via my Windows machine.

Anyway it got me thinking that it might be a good idea to create a VM image for all public lp mudlibs. I use VM images a lot at work and they can be very handy from everything to developing, testing, playing and even live usage.

saquivor: [link]

Ok first release is available for testing. VM will run Puppy Linux 4.0, and currently has ds2 and tmi2 installed.

saquivor: [link]

I have upload another version of lpmud VM. See links above for downloads.

Added discworld and also changed how the muds are started. In that I have written an ncurses menu front end to control starting the muds and connecting. (It will pkill any running copies of driver and then start your selected mud.) ...

A failed attempt at an evaluation of UltiMUD

I was reading one of the MUD forums, where a poster inquired about being able to build one without coding. Someone responded pointing out UltiMUD.

UltiMUD is a telnetable MUD server, with visual and graphical world building tools built into it. At a distance, looking at the screenshots and web pages, it looks quite nice. A tool which allows you to graphically edit your game world and also to visually add things like commands. Properties look to be editable in a "Visual Basic" style. The built game can be started and stopped via the "play" and "stop" buttons. Logged on players update in the GUI and can be snooped on. Etc.

In order to gain some inspiration for my own hobby projects along the same lines, I decided to bite the bullet, install it and have a play with it. I had a lot of trouble figuring out how to do any world building with it. The help option unfortunately brought up a web page on the UltiMUD web site, sadly not one which addressed anything I needed help with in a useful way.

Attempting to build a world

How do I create an area? No idea. Okay, there's a obtuse page on this on the UltiMUD web site. I try and follow the directions, and manage to create something which looks like a forest with a starting location in the middle. Most of the properties for the selected object have strange names whose purpose I can't begin to guess at.

How do I allow a player to look around? Well, having tried to start a game with no world and nothing else edited, I was informed that without commands, a player won't be able to do anything. So having created an area this time, I tried to create a look command. Adding a command is one thing, but what do the properties for the command mean? Script? Apparently UtiMUD uses Lua. I found a look command written by the author via Google, having been unable to find it on the UltiMUD site myself. I _guess_ I am supposed to add the command to the "script" property of the command I have added. But where does the additional supporting script go? I can't add scripts to the game - the "scripts" folder has no context menu. And however I add a command, script or no, I get the shown error. At this point, UltiMUD is now in a broken state and stopping a running MUD locks it up otherwise that error just keeps coming back.

Final thoughts

To me, UltiMUD is unusable. It looks like a well made tool, which a lot of work has gone into. But I feel like anyone who wishes to use it needs to have some "idiot savant" ability to divine required information which hasn't been provided.

It is not a code-less world building tool. Case in point is the commands. UltiMUD does not come with built-in commands - it is up to the user to author them, and the only way the commands can do anything beyond trivial effects is via attached Lua code. This is just an observation, code-less developing is clearly not a feature of UltiMUD.

Apparently version 2 is coming out sometime after mid last year (July 2007). But this won't address the reasons why I wouldn't use UltiMUD. Even if it were usable, it implements a fixed model for any game world built on top of it. And being implemented based on the authors own ideas, this unavoidably forces what seem like arbitrary constraints on anyone who uses it. To someone who doesn't have world building experience, this might be fine. But having my own idea of how a game world should be able to be built, this is not suitable for me.

Webinar: Sirtuins, Aging and Disease

A recent post to the CR Society mailing list pointed out a video recording of a seminar which aimed to "introduce people to sirtuin biochemistry," and was freely available (not counting the tedium of having to register with their website) to watch.

A lot of the posts to the mailing list are summaries of recent research and mention things which seem beyond my understanding like sirtuin. Normally, I stare at them until I realise I don't really know enough to understand them and delete them, feeling a little guilty about missing out on useful information. Because of this, I couldn't justify deleting the email and left it sitting in my inbox. As I've been having a clean out today, I found myself watching the seminar so I could get rid of the email.

I found it quite an educational hour. It covered a range of topics of interest to me, in relation to sirtuins; particularly calorie restriction and resveratrol supplementation. I've let my calorie restriction slip since I left Iceland. I am however, supplementing with resveratrol which I bought on a whim.

After watching the seminar, I feel like recommitting to calorie restriction again. And given that the seminar mentioned that resveratrol needs to be taken in large doses, I suspect that I am undersupplementing and should look into that.

Anyway, the company which provides the seminar will apparently be shutting down at the end of the year. So if anyone would watch it, they need to do so before then.

python-dev: unittest changes and language changes

When new releases of Python are being developed, I start browsing the python-dev mailing list in order to keep up to date on when the alpha versions, beta versions, release candidates and final versions will be released. I do this in order to try and synchronise releases of Stackless Python, as it helps me (and hopefully others) feel like it is a relevant and current project. Maintaining its currentness has been my primary driving force in spending the time I have maintaining the project itself.

However, in browsing python-dev I find myself actually reading all the posts, and I find this rather disappointing. Features are proposed and seem to get accepted and integrated arbitrarily - at least in my opinion. I don't want that statement to get conflated with a dissatisfaction with the Stackless Python features never having gotten into the Python language, that is not an interest of mine. In any case, I feel that the Python language is drifting away from what I originally liked about it, especially in terms of approachability and readability.

One particular aspect which is being discussed at the moment is revising the unittest module for a later release of Python 3000. Modifying all the assertion method names away from camel case to suit the style guideline PEP. Going with the assert* naming and dropping the fail* naming. And more.

Personally find the fail* naming easiest to interpret and tend to just use the failUnless method for most of my unit tests. The feeling I get from the mailing list is that there is a desire to make everyone use the assert* methods, so that those who prefer them can have any test they encounter fit their preference given that the other approach is redundant.

I hope that the fail* aliases make it in - but I don't expect them to.

rec.games.mud.admin: reading list 4

These threads seemed a bit better to summarise, in the sense that they felt like they had more concrete experience to them, rather than wishful thinking and speculation.

1997-12-15: Better mud

What makes a better MUD? The original post lists a range of rather superficial aspects which deal mostly with good taste and quality control. Eventually touches on magic systems. Then going level-less in terms of skill systems.

1998-01-23: Bandwidth Usage of MUDS

A good overview of the bandwidth usage of MUDs (at least in 1998, but hey, it's not like MUDs have gone anywhere) with a consensus on what to expect.

1998-02-02: What do you think of Introductions?

An excellent thread on recognition systems. Concentrates on observations of actual implementations and possible ways to vary them. Polluted with a few boring implementation related posts.

1998-04-14: Grids and curvature of a sphere

Grid-based game worlds with wrapping of the world.

1998-04-08: Diku vs. LP from the player's POV

Eventually moves to discussing exits and directions. Having the server doing the movements as part of an action to go to a landmark, rather than the player entering the movement commands needed to get there themselves. Drifts to classless systems. Skill systems.

1998-03-21: Roleplaying

Just skimmed this thread. Seemed to stay on track.

1998-05-06: Political Systems

Land ownership, taxes. Player councils. Law and order. Guard behaviour.

1998-05-07: Dealing with Mages

As the title says. Alternative magic approaches (mage2mage, waving hands).

1998-05-28: Level Restrict Rooms and Obj's

Not a particularly interesting topic. Branches off to item usage restrictions, like the D&D mage armour restriction.

1998-07-21: Immortal Attitudes to Players

Player rights. Not a topic I find particularly interesting. The situation which triggered the thread was where an admin closed down a MUD leaving the players in the lurch with their ensuing feeling of entitlement.. to something.

1998-07-29: new project + roleplaying in muds

Starts with permadeath and nethack style interface. Generated descriptions for people and rooms, up to and including recognition systems. Droning on about the best data structure to use. Discussion about a Simultronics MUD called Dragon Realms. Simulationists vs anti-simulationists. People who go off on a rant when they read the word realism.

1998-08-24: Coder shortage

Complaint about how MUDs aren't willing to train coders. Creativity being more important than the ability to code. Good coders being better than good builders. Code reviews, including descriptions of workplaces MUD programmers have experienced it at.

1998-11-02: missile combat

Bows, arrows, armour and so forth. Peasants as slaves.

1999-03-04: MUD Economies

Noise-free thread about more realistic economies in MUDs.

1999-03-24: Area Copyright and Usage

Builders' rights. What right does a builder have to the work they create for a MUD run by someone else. Subjective interpretations of law. Overuse of swearwords (on my part).

1999-05-05: [The Future of Our Hobby] What's in store for us?

Yet another pointless discussion about what the future of MUDs is. Graphical, text.. etc.

2000-05-30: Sublocation

Location of objects within rooms.

1999-06-30: Combat with fireweapons

Range attacks, radius effects, guns and grid usage.

1999-06-02: Classes vs Classless

The advantages and disadvantages of class and classless MUDs. Skills. Combat technique. Weapons.

1999-07-08: ENOUGH STALE MUDS!

Starts with a diatribe about unoriginality in MUDs. Importance of room descriptions. Mapping and disparate room sizing. Races.

1999-08-17: Turn-based combat

Turn-based combat in MUDs. Combat speed. Devolves into boring implementation discussion for a while.

1999-11-21: Commercial-use Restrictions on Code Bases

Starts off with someone wanting other people to have written a graphical code-base for them then moves into the secondary topic shown above. GPL. BSD.

Current position: December 13th, 1999

Stackless notes #1

Creating a tasklet

When you create a tasklet, it is automatically scheduled. This places it at the end of the list of scheduled tasklets, and out of all the tasklets currently waiting to run, it will get its turn last.

Scheduling a new tasklet:

>>> def f():
...     pass
...
>>> stackless.tasklet(f)()

There is no need to hold a reference to the tasklet to keep it alive. The scheduler holds a reference to all scheduled tasklets.

Binding a callable to a tasklet:

>>> def f(arg, kwarg=None):
...     pass
...
>>> t = stackless.tasklet(f)
>>> t.scheduled
False
>>> t.alive
False

Supplying the parameters for the callable:

>>> t = stackless.tasklet(f)
>>> t(1, kwarg=2)
<stackless.tasklet object="" at="" 0x01b031b0="">
>>> t.alive
True
>>> t.scheduled
True

Running the scheduler

Once started, it will continue to run until it has no scheduled tasklets remaining.

>>> def f():
...     print "scheduled once"
...     stackless.schedule()
...     print "scheduled twice"
...
>>> stackless.tasklet(f)()
<stackless.tasklet object at 0x01B03170>
>>> stackless.run()
scheduled once
scheduled twice
>>>

If a tasklet never exits, the scheduler will continue to run forever. This would happen with the following function:

>>> def f():
...     while True:
...             stackless.schedule()
...
>>>

Running the scheduler normally

As already shown, the normal way to use Stackless Python, is to create your tasklets and then to run the scheduler until they have all either blocked out of it, or run to completion.

An example function to schedule as a tasklet:

def SomeFunction():
    while not shouldExit:
        # Do whatever it is this tasklet is supposed to do.
        pass
        # We need to yield to allow the other scheduled tasklets to run.
        stackless.schedule()

Create and schedule the tasklet:

stackless.tasklet(SomeFunction)()

Run the scheduler until there are no remaining scheduled tasklets:

stackless.run()

Using this approach, Stackless is a framework and it drives the running of your application. If your application needs to do something, then it needs to create a tasklet to run alongside the others in the scheduler.

Running the scheduler in a more flexible way

It is often less constraining not to have to shape your program to fit inside a framework. This is not how Stackless was used above, in the normal manner. But it can be done by approaching things a little bit differently.

This is what we do in EVE Online, as Kristján Valur Jónsson described in his presentation at PyCon 2006. The approach is described in the Stackless Python idioms wiki page, as the 'Being Nice' idiom.

In a nutshell, rather than yielding your tasklets to the end of the scheduled tasklet list, you yield them onto a channel and out of the scheduler. This is the 'BeNice' function:

def LoopingFunction():
    BeNice()

The scheduler will then exit after each tasklet has been run once. Then when you next get to the point when you can run the scheduler again, you first wake up each tasklet on your yield channel, then run the scheduler.

def MainLoop():
    while not exit:
        RunNiceTasklets()
        stackless.run()

The Stackless 'schedule' method should not be used to yield any more, otherwise you will block on the scheduler running until the tasklets which use it are blocked off the scheduler in some other way, or have exited.

An example implementation of this is provided in the uthread module.

import uthread

def LoopingFunction():
    uthread.BeNice()

if __name__ == "__main__":
    uthread.Run()

Of course, as is, it is not much use. You need to integrate your logic into the loop within your own version of the 'Run' function. Otherwise, you are not much better off than just using Stackless normally.

PyCon 2006 / Stackless Python presentation video

Back in 2006, CCP attended its first PyCon. Kristján Valur Jónsson and I were sent to attend, with Kristján Valur doing a presentation and both of us sprinting to bring Stackless Python up to date. Christian Tismer had been preoccupied with PyPy. But he kindly made himself available to hold our hands through the sprint.

On a whim I acquired CCP's video camera and recorded Kristján Valur's presentation. However, the tape was never processed and sat in and on various desks for over a year. Since I am leaving CCP, I decided to make sure this video was processed.


However this wasn't an easy matter. The video was extracted from the tape into an avi file encoded with a Sony DV codec. Nothing except for Microsoft tools seemed to want to recognise the audio. Which meant that if I wanted to encode an XviD version, I needed to reencode an existing WMV reencoding of the Sony DV avi. Unfortunately this was a dead end, no matter what I tried I was unable to get the XviD to have audio which was in sync with the video. The WMV played perfectly of course. Windows Media Encoder was a pleasure to use - it just worked. I tried using AutoGK and StaxRip for the XviD encoding and they were also a pleasure to use, but just weren't able to do the job.

If anyone can convince me that they have experience working around audio sync problems and converting Sony DV codecs, I can provide the 8 GB Sony DV avi or the 1 GB WMV for reencoding to XviD.

Anyway, here is the video on Google Video:



Originally posted 2007/30/05; Updated 2008/06/05: Reuploaded the video, which was not working. Previously, it would upload and sit in the Processing state. I gave up and left it that way for a year. Reuploading it now, Google seem to have updated their quality to blurry converter to be able to handle the WMV format better.

mudconnect.com: Python MUD codebases

Link: Calling all Python muds

Idealiad:

Inspired lately by Python I wrote up a short list of all the Python muds I could find. Note that I couldn't get working links for some sources so I left those out. If your Python mud isn't included here would you add it?

Here's what I have so far:
...

The thread gathers together links to 17 different Python MUD codebases.

rec.games.mud.admin: reading list 3

On one hand browsing through these threads reminds me of when I first read them as they were posted in university on monochrome terminals in a neglected computer room in the corner of the engineering buildings. Doing so is inspirational, reminding me of many things my fellow programmers and I wished to implement in the MUD we worked on at the time.

However, on the other hand most of the topics are kind of depressing. Not because they remind me of the things I want to program for my current pet project, but haven't. Rather because pretty much every thread seems like a futile reiteration of other threads, most likely by the same posters. An exercise in repeated procrastination. I can feel myself finding it hard to make notes on each thread as I do more and more.

A common factor of these threads, is that more often than not, Physmud pops up within them. The way it is described by its author, paints it as one of the deepest most complex codebases ever written. Unfortunately, while it sounds interesting and is painted as an implementation of some of the more advanced concepts (non-room-based, dynamically generated descriptions, ...), word is that it is vapourware.

1997-01-10: Specifications for Wear Location System

Mainly of interest for the initial post which is a detailed description of a ... wear location system.

1997-02-24: Stock muds considered harmful

A long thread, but a classic. Starts with the suggestion that all the stock MUDs are bringing the rest down.

1997-02-26: Design of a good MUD (was Stock MUDs, etc)

Touches on experience, levels and skills. How to handle character health. Downtime, what your character does when you quit. Then some more on classes.

1997-01-09: Telnet NOW! Campaign / Interaction in combat / Quests

Starts off with something boring to do with telnet, then veers into where MUDs are going.

Eventually it comes on track and starts covering combat. Effect of the rate at which text is displayed to the player. Proximity and room sizes. Manual action versus automatic reactions. Limb-based systems. Realistic fighting topics, from Japanese fighting techniques to practicality of armour. Magic in combat. Damage types. Size of combatants. Relative descriptions based on the viewer. The practicalities of combat in Braveheart. Armour class and damage.

Next it veers to quests. Static, dynamic or templated. Replayability. Players sharing solutions. While this is an interesting topic, my personal preference is that solutions don't end up making the same mistake Oblivion did with its dynamic content being at the expense of believability.

1997-04-20: The State of Muds

Starts with some subjective thoughts on the future of MUDs.

Next a proposal is made to band together and create and uber-codebase. I don't know about you, but I work on my personal project because it interests me - I get to choose the language it is written in and where it is heading theme and featurewise. Working on other people's ideas in my spare time doesn't sound like much fun, and the chance of the commonly agreeable concepts being appealing I would expect to be low.

Mike Sellers chimes in with a point which matches my interests, that "the biggest overarching weakness is that the simulations and world-mechanics remain shallow". The thread continues to debate realism and game simulation/world-mechanics.

1997-04-06: Ideas for the betterment of muds...

Starts off with the subjective opinion that sound was what was missing from MUDs. A protocol to add it. Then a general MUD protocol.

1997-03-31: Stock muds: the my-way highway

Yet another thread to do with stock and scratch MUDs. Hard to pin down what it covers as I got bored and lost focus while reading it. Gets to a point where it starts going into programming related details, near the end. Maybe something to do with concurrency.

1997-05-14: Threats in a MUD

Relates to adding excitement to the game, through posing threats of various kinds to the player and their activities. Threats from interaction with the environment. More detailed gameplay, in the direction of simulation/realism.

1997-05-24: Experience based on reality...

Suggests rethinking at what experience is used for. Moves onto skill system discussion. The effect of botting.

1997-05-02: Combat system Design

Avoiding round-based combat. "To hit" factors. A good discussion of room-based and other alternative spatial approaches. Skill systems and experience. Death. Player rights.

1997-08-10: DESIGN: Coordinate systems, etc

Body types; swarm, gas, blob, etc. Coordinate system area creation.

1997-08-12: RP mud naming restrictions going a bit too far

Should characters be forced to name their characters with real names? Should nickname-like names be allowed as character names? Introduction systems in passing.

1997-08-24: DESIGN: Original themes, running muds

Original themes. Implications of the room-based spatial model on play experience.

1997-09-08: Room based VS ???

Short thread on the alternatives to the room-based spatial model.

1997-06-30: The Failure of Mud Evolution

Starts off as someone requesting help compiling the Circle codebase, then branches into discussion about the failure of MUDs to evolve. Touches on licensing disputes (Medthievia), advanced MUD codebases, stock MUD suckage, inclination of given MUD types (diku, LP, ..) to quality levels. Advantages of build able to directly build things like HTTP and FTP servers into your MUD.

EVE Online has had a built in web server from day one and it has been extremely useful as an interface for game masters, game designers, programmers and more. It was simple and fast to write a web page which worked with your feature you implemented in some way.

The pluses and minuses of using LP as a MUD programming environment.

1997-08-12: ADMIN: Update of stock/scratch analysis

Another attempt at breaking down the advantages and disadvantages of stock and scratch MUDs respectively. I didn't bother to note the original thread because.. I don't remember, but it probably devolved into bickering and flaming. This also devolves into more of the same. Although, at the end, there's some discussion of advanced codebases.

1997-09-18: Redefining the room

More discussion of variation from the room-based spatial model. Dynamic generation of descriptions.

1997-10-20: Player Rights

This isn't the first thread on this topic I encountered. There were several others, several years back, but I skipped them. This is one of those worthless topics which are subjective and more often than not are unproductive (like stock vs. scratch).

1997-12-02: Is it mine yet?

Whether a MUD codebase is yours if you make enough changes. Meanders a bit into bickering. Then to the theft of codebases outright, then people deriving from them (Godwars).

A topic I identify with, but from the opposite perspective. I worked on an LP based codebase with some friends and we released it as the Sorrows mudlib. More than once, we got people who took our hard work, made some nominal changes to some of the higher level systems and claimed that they had changed so much that it was completely their own work.

As someone who had done the bulk of the work rebuilding an existing codebase (the Discworld LP mudlib) from the ground up, the difference in the work we did that, to the superficial work the adopters had made to our resulting work, was an order of magnitude.

I would say it is never yours, but always a derivative work of what you based your work upon. As we considered our mudlib to be a derivative of Discworld mudlib, their work was a derivative of our mudlib and always would be.

1997-12-17: DISCUSSION REQUEST: Combat System

Discussion of combat systems. Armour, damage, participant size, limb-based.

Current position: December 24th, 1997.

rec.games.mud.admin: reading list 2

A few more..

It occurs to me that the links are not as neatly sorted by timestamp as I wished. Google groups seems to sort the posts by date of last post, at best. And then there's the odd thread where some of the later posts are before the original post which started a thread. Better than nothing, but unfortunate.

1995-04-05: Commercialization of MUD - part 2

This is continued discussion from an initial post about the future of online games. Unfortunately, the initial post seems to be missing from the Google groups archive. RMT is suggested and dismissed, although mention is made of it already happening in some game called Kingdom of Drakkar.

1995-04-06: Commercial MUD Feedback

More discussion of RMT in commercial MUDs. Also a reference to the monthly revenue of a MUD called Jurassic Park in Korea, which supposedly earned $60K USD per month.

1995-07-30: Paradigms for Modeling Physical Space

Relating to a 3D world as a basis for MUD development. Other possibilities come up along the way.

1995-07-19: What is the Mud State of the Art?

Something I have always wondered myself. Starts off promising with an array of interesting features listed, but gets derailed into covering various details which aren't really that hard.

1995-08-04: Do you use auth/identd?

The idea of being able to get the username of a player, on the machine they logged in from, was quite nice. We logged it on my MUD and found it very useful in dealing with problematic players. However, it was only as useful as long as people logged in from sites they didn't own or have administrative access to.

1995-11-27: VRML mudding

Some discussion of the practicality and utility of using VRML to make a graphical MUD. We exposed a VRML representation of our MUD, via our embedded web server, back in the day. Given an agreement on the benefits of text as a game representation, based on the idea that it allowed more free use of the imagination, we dismissed using VRML for play. The consensus in this thread is that it was impractical anyway (required functionality was lacking and bandwidth needs). When we experimented with VRML, it was on the wane. It was a few years after this.

1995-06-27: What would *you* pay for an excellent mud?

An attempt at polling the interest in what people would be willing to pay to play a graphical MUD. Goes on to cover what people think of advertising.

1996-05-17: Do you think Quake/Doom/etc will end mudding as we know it?

Starts off as one of the atypical valueless topics, that graphical games (i.e. Doom/Quake) will cause the death of their text counterparts. Doesn't ever veer from it. Included just for the sake of completeness.

1996-08-08: shifting economies

Addressing shifting from a npc based economy to a player-driven one. Polls those who have made the shift, with one poster of relevance piping up mentioning Dartmud.

1996-08-11: Rethinking Rooms

More discussion of alternatives to the room-based spatial model. Mentions the problem of viewing one room from another..

1996-08-29: The Future of Muds?

A short but positive thread covering text versus graphical MUDs. Mentions the integration of graphical aids into text MUDs.

1996-09-01: Letting Coders have Players

Should coders be allowed to play the game? The possibility of cheating, the effect of that on the player base. The advantage of being able to see what the players are really doing and hear what they talk about.

1996-07-15: Skill based systems / Rethinking Rooms

This thread veers from skill-based systems to rethinking rooms and back again.

Ways to stop players gaming 'learn through use' skill systems. Lore/in-game knowledge of a character.

Limitations of the room-based model. Grid-based approaches. Technical details of grid-based implementations. Generated room descriptions. Ways to handle exits.

1996-08-19: Realistic MUDs: Mob behavior

Starts with giving NPCs a life, engaging in activities for a reason. Then devolves from this into discussion of existing limited approximations which aren't anywhere near as hard to implement. Wanders into introduction systems. Rumour systems. Adding continuity by doing away with resets.

1996-12-08: Developing a graphical MUD in Java / java and dynamic reloading

Some back and forwards about the practicalities of code reloading in Java at the time. Comparisons with LPC, within which this is easy. Class reloading is the main thing that my code reloading module allows for in Python.

Current position: 8th August, 1996.

rec.games.mud.admin: reading list

Reading forums like The MUD Connector, MUD Lab, Top MUD Sites and so forth, there are not a lot of posts covering original subjects.

... Are MUDs getting less popular? Allusion to a feature which needs implementing, implicit request for people to design it (or something). Description about yet another MUD programming language which someone is creating, appeal for ideas or comments. ...

I've always wanted to make a set of notes where I can just post summaries of and links to existing discussions on these topics. There's a range of resources, whether the MUD-Dev mail archive or newsgroup posts.

Given a little spare time, this is my initial effort. I am going through the Google groups archive of the rec.games.mud.admin newsgroup from the beginning onwards. Not reading the posts at this stage, but making a list of interesting looking threads. It is surprising how few threads of note (excluding crap like bickering over licensing) there are over the early years, 1992-1995 at least.

1992-07-04: Discworld MUDS

Terry Pratchett encouraging MUDs based on Discworld to step forward and be legitimised.

1992-07-31: Admin Burnout and the TMI Dilemma

Several posts which relate to my own MUD development experiences where it is all very well for people to have ideas, but when it comes down to it, you need programmers who are willing to code it.

1992-09-10: Australian MU* ban. Still in effect?

Apparently MUDs were taking a significant proportion of the Australian national link. Interesting note on the overhead of a telnet packet when the protocol is operating in character mode rather than line mode.

1992-10-09: Graphical MUDS?

A poll of what graphical MUDs were available for play, with some allusions to others that were in development (for what that's ever worth).

1992-11-10: ATTN: skill based muds

Interesting discussion about skill training through use. Discworld MUD has a system called Taskmaster which was implemented four or five years later than this. Pinkfish from Discworld (David Bennett) can be seen participating in this thread.

EVE Online used to have skill training in this manner, but eventually it was discarded due to the implementational problems it involved in the one-world multi-node environment.

Eggert, who wrote EVE's "taskmaster" system was directly inspired by Discworld's implementation which he experienced as a player in university.

1992-12-03: Skills based systems abuse

Followup discussion on skill advancement through use.

1993-03-12: Magic

Discussion about magic systems.

1993-03-19: A new type of player?

Allowing players to login and control NPCs.

1993-04-19: Rooms? Who needs them?

Replacing the room-based model with a grid-based model.

1993-04-15: Nightmare mudlib 2.4 for MudOS 0.9.16

George Reese makes a post announcing his new mudlib version, listing a range of features it provides. This is analysed by other posters and results in some interesting discussion about schools, guilds and more.

1993-06-17: How to permanent character death

Discussion about permadeath. Leads to Alan Cox pointing out that this was the way it originally worked (in MUD1) and it was expensive.

Current position: April 23rd, 1995.