My next MUD client

When I started playing MUDs, zMUD was the client of choice. It had a powerful mapper and a scripting language that was easy to get started in, but which could grow to the level of complexity needed to handle combat in MUDs like Akanbar or even Achaea. But its scripting engine wasn't very well designed. It was built from the bottom up, taking very simple things like aliases and then building them up to be able to do more, thus running into lots of scalability problems. No real subroutines, no scoping rules, no structured programming language benefits, minimal provisions for sharing scripts, and as scripts got bigger, serious problems with stability and performance.

By the time you get to a really rich and complicated combat system like Lusternia has now, you run into serious problems where you're fighting against zMUD all the time. It's possible to make a curing system for zMUD for Lusternia, but it's straining its capabilities. Developing a system smart enough to handle Lusternia combat is a challenge under the best of circumstances, and a huge investment of time. Doing it in a language that lacks things like scoping makes it much harder. Dealing with having to optimize it not just for function, but also for getting around zMUD's performance bottlenecks and instabilities makes a Herculean task nearly impossible.

My zMUD Lusternia curing system has some good things about it, even a few things no one else seems to have done, such as a smarter way of prioritizing potion and deepwound curing based on the class of your current target. However, it lacks other things that really should have been built in from the ground up to be effective, like illusion protection. It also is a bit of a hodge-podge since I have implemented it gradually and things that should have been integrated were not. Most damningly, it's ages behind; there are countless afflictions and situations I never got around to adding to it. Despite this, it's still far past what zMUD can handle; it gets unstable sometimes, despite me pouring way too much time into optimizing. It would get far more unstable very quickly if I tried to add all the missing stuff. If I stripped it down and rebuilt it from the ground up, I could do better, but it would still be limited by zMUD, and that would also be a huge, huge investment of time.

Just about everyone else has moved to another platform by now. MUSHclient is probably the most popular, and has one free system available for it which is just becoming unsupported, allowing me the chance to take over supporting it... and the burden thereof. There's a promising new system for Mudlet that looks quite impressive, but costs, and comes without source code, so you are dependent on the player keeping it up. Both of these have one great benefit: I can skip over the hundreds of hours it would take to fix up my system or build a new one, and use those hours (of which I have only so many to spare) on learning how to fight with the system.

However, these both have two big liabilities that are holding me back. And both of them are things that'll probably seem petty and dumb to most people familiar with these things -- at least until they give them a real try and realize what they've been missing.

The first: because MUDs date to the 1970s, they historically are on a black background, but there's nothing about them that requires it. It's a matter of a couple of minutes to configure any MUD client to use the white background that, for very good reasons, every other computer program you use switched to almost 20 years ago. It would be only a little bit harder to design your system to respect that setting, but no one has bothered, since almost everyone accepts the default black-screen background, and by time they are in a position to think about changing it, they're so used to it, they're unwilling to try out the alternative for long enough to get past that "but I'm used to it" into seeing how much it really helps your eyes follow the text as it goes by (so very fast in Lusternia combat, so it really matters). So no one bothers. If I took up MUSHclient, I would have to spend many hours, on top of the existing time I'd spend on configuring and updating it and learning to use it, recoding a lot of it to support white background. If I took up Mudlet, I might not even have that option.

The second, and much bigger one: the mapper. The mappers in MUSHclient and Mudlet are both very new, and fairly primitive. They have one screamingly big advantage over zMUD's: they can use an XML map downloaded from the MUD instead of making me map everything myself. This also brings a screamingly big disadvantage that could be easily fixed, if the developers prioritize fixing it early into the development (i.e., now): anything not in that downloaded map, even if you have a means to add it, will get lost every time you do a new download. Otherwise, every comparison comes down firmly in zMUD's favor: the map is far more flexible, and has a lot of features the others do not yet have, simply because it's been around for many years, and the others are both brand new.

The key thing about the mapper isn't the amount of work it'd take for me to address the shortcomings; it's the fact that I really can't, or at least shouldn't, be the one to do so, since the issues in question need to be addressed by changes in the underlying database. Even if I hacked the code to make my own version that addressed them, which is a bigger project than I really want to get into right now, I'd be doing so at the cost of making my version separate, so from then on I could no longer benefit from anyone else's work. Future improvements, bug fixes, adaptations to changes in the source data, etc. would all be my problem. If I'm not eager to start over on building my own curing system, even less do I want to build my own mapper, even from a head start.

The things I need from my mapper that aren't in there aren't there in part because the mappers are fairly new, but partly because a lot of people don't expect enough from their mappers. It's a case of "how did I ever live without that?" -- everyone who's used a map that works like mine is set up has concluded "oh my god, this is amazing, how did I ever get by without it," and yet most players live with so much less and have no idea what they're missing. It does tend to make it hard to convince people that the very few things I'm asking for at the heart of the mapper (since they really need to be done there) are worth taking seriously. They don't have it, so they can't try it and see how wonderful it is, so they never believe it'd be worth the time, so they continue to not have it.

This leaves me in a sort of limbo: I'm trying to scope out the makers of the MUSHclient and Mudlet mappers to see who's going to convince me first that the things I depend on my mapper to do might be in a future version (not too far into the future).

The guy who made the MUSHclient mapper pretty much dropped the potato on this: his answer seems to be, "sure, that's great, let me know when you're done," and he doesn't seem inclined to really seriously consider what I'm suggesting enough to see why some of it has to be done in the core product, not as some home-grown slapped-on modification, or why having just a few things added at the core would make all that home-grown addition stuff something I could (and would) do. As far as he can see, I'm just another person who is asking him to do all the work for me; he has no idea that I'm a seasoned programmer, and once I choose which horse to back, I'll probably end up contributing more programming and sharing it than 90% of the people using it, because all he can see is that I'm "quibbling" about getting him to do the few things that, as a matter of design, should be implemented in the core, instead of doing them myself. And that I'm using that as a test to see which horse to back.

The Mudlet mapper people have taken some of my ideas a tiny bit more seriously, but it's too soon to tell whether any of it will actually be done. Even there, I'm running into a little bit of "do it yourself" and the same attitude -- that the only reason for me to be asking them to do some things is laziness, not trying to decide which is the best platform (based, in part, on which one will require me to do more of it myself -- the time I don't have to spend doing basics is time I can spend doing cooler stuff). But even if they do go with my requests, it's likely to be a long time. And I really want to get moving on this project.

So what other options are there? I could stick with zMUD and try building myself a system from scratch. It would be a huge amount of work, but it would probably come out better than anything I could by further evolving what I already have. I've already done parts of such a system, just a few parts, for my second Lusternia character. But it would also run me into the limits of zMUD. And while I'd have its superior mapper, I'd also be committing to it; the MUSHclient and Mudlet mappers could easily become superior, due to that downloaded map factor, with a few improvements, and I would hate to miss out on that.

I could also move to CMUD, which is the successor to zMUD. The maker of zMUD finally realized he couldn't fix what was wrong with zMUD by evolving it, so tried a clean break, but only so clean; CMUD's scripting language is a compromise between backward compatability with zMUD (enough to import simple scripts, and to already know how to code in it from the start) with getting away from its limitations (it has some scoping and subroutine-like functionality). And of course it has basically the same mapper. I could use it to build a whole new system. However, previous versions have been plagued with terrible instability issues, which is why everyone else abandoned it. Seems like it should be better than zMUD on the stability and performance fronts, but it hasn't been. There's a new version now that might be, though. Might be worth checking out.

Of course, the people who make the two systems previously discussed are both eager to see me adopt them -- in one case, because it's worth money, and in the other, I think just because he is taking my assessment of how much work I'd have to do to make it meet my needs as some kind of criticism and/or a dose of that laziness issue (that I have unrealistic expectations of a package that I unzip and it's already perfect -- which is particularly unfair in his case because he knows firsthand that I am an experienced coder who's done plenty of stuff and thus will almost certainly do plenty of stuff in whatever platform I pick).

But no one wants it enough to convince me that they're taking seriously my ideas about what needs to be implemented in the core, and why. So I'm stuck in this limbo and eager to get on with it. I have time right now to spend on this project, now that the game room is on indefinite hiatus, and because my second Lusternia character is at that point in her career where she should be focusing on this stuff; and I can't proceed. It's very frustrating. All this over what probably amounts to one solid day of coding for whoever has the source code for the mapper, and a few hours more coding for the white-background issue. I need to find some way to proceed!