Will's blog

I had a craptastic conversation with one of the admin on Dark Rifts a couple of days ago the end result being that I decided to cut my losses and leave. They're not going in directions I'm interested in and I don't really have time for it anyhow.

Between all the mud projects I've worked on, I've probably written a couple hundred thousand lines of code in Java, Python, C and ending with LPC over the course of the last 7 or 8 years.

I'm still kind of bummed about it and I think that's the end of mud projects for me unless I get involved in Twisted Reality or Phantasmal/DGD. Twisted Reality is really interesting, though it's really different from other mud systems I've worked on.

Every once in a while, someone emails me about Stringbean and wonders why I'm not working on it much. Stringbean is more like an LPMud than a MOO and would allow for in-game coding of objects in Python. I've been giving a few reasons of why I'm not really actively working on it:

• It's not currently possible (without a lot of work) to build a restricted execution environment within the Python interpreter to protect the driver from the mudlib codebase if both are implemented in Python. That's not a wildly large issue except that it forces you to really trust in-game developers. The Zope folks have something like this in place, but I don't know if it would help me solve my problem or not. Mostly this requires a lot of research and work.
• It's difficult to terminate infinite loops and other long-running code which will cause mudlag. It's not uncommon for me to accidentally create an infinite loop. If you can't somehow halt execution, then this forces you to shut down the whole mud and restart it. When working on Varium, we created a reaper thread which would send a signal to the Python process causing the execution thread (which was the main thread of execution) to throw an exception and thus "terminate" execution. Even with this, it's not clear what state the driver would be in. This also requires a lot more research and work.
• I bumped into Twisted Reality (which is what this post is all about).

Twisted Reality is a MOO oriented mud so it's got a different focus than Stringbean does. However, Twisted Reality is also attempting to solve another big problem I have with muds using Aspects.

The problem is this: you build a bunch of objects the player can manipulate (things like torches, swords, hammers, nails, screwdrivers, ...) and in order to add another way for the players to manipulate and modify these objects, you have to code manipulation/modification-handling code for every single object. What if you wanted to allow players to burn an object? Well, for every object, you'd have to implement burn-handling code.

You could implement this using multiple inheritance. Each object inherits from a object-type class (armor, weapon, container, ...) as well as a material class (iron, wood, organic, copper, glass, ...). The material classes could handle effects like burning. But what if you had something like an axe with a wooden handle and an iron blade?

Anyhow, it'd be easier if the burn code could be centralized into one place--an aspect. The stuff in the Reality mailing list is interesting enough that even though I haven't looked into it further, it's caused me to want to wait to research it more before I go work on Stringbean again.

In my copious free time, I do some work on a mud named DarkRifts. The mud itself runs on MudOS on top of a mudlib based on a mudlib based on TMI-2. I've worked on a few other mud projects, but decided I didn't want to run my own mud since I don't have enough time for that and it'd be better to help out with someone else's mud.

The mud is still pretty infantile in terms of maturity of the codebase and player base. We have seven guilds that are in-game (two of which are "starter" guilds) in two realms with twenty-nine different areas and several cities. We've got a few alpha-testers who come irregularly.

There's a lot of polish work to be done--but we're not at that stage yet, though we are progressing. One difficulty is that our alpha-testers are pretty irregular in their testing. So the mud is pretty quiet most of the time (I think we average 2 players online). The other difficulty is that we could use a few more coders to help even out the rough edges on that side of the equation.

Anyhow, if you have any interest in seeing what we've got going on, helping out, or otherwise chiming in, check out the DarkRifts website and/or add a comment below. If you log in, my name is "Flake". I idle there during the day and do some work on nights and weekends (I'm in Boston, MA which is Eastern Standard Time). Please drop in and say hi!

I'm totally fascinated by game economies as they generally approximate real economies but usually have "faked" aspects because game economies usually lack feedback loops that real world economies have. Blah blah blah I am not an economist so I'm kind of fudging my English here blah blah blah. Regardless, I still find it really fascinating. I also find game weather systems really fascinating.

Anyhow, there's an entry on issues in the Star Wars Galaxies economic system that led them to discover cheating. It's detailed here. There's some more information on it here.