A few more hours have passed, and I've already been outvoted. We're going with Option One, and I'm going to have two games open simultaneously so I can grind in another MUD while I play. *grin*


I'm contemplating starting up a MU* for a roleplaying community, and would really like to make it a MUD rather than a MUSH-genre server so the OCD gamers can have things to go grind at when we get bored but don't want to log off. The difficulty with this is that many of the group would rather focus on actually interacting with human beings, so I've got to find a way to make sure we ADD grinders don't outstrip the community-building roleplayers.

I'm wondering if any of the SMAUG forks would be a good tool to build a solution to that, and if so, which approaches may work. I have to admit my MUD experience was as a builder on various projects off and on between 1993 and 1998, and after that it was a few years here and there working with professional proprietary scripting languages, so I have ZERO actual admin experience, let alone C++. So while I learn new systems quickly, my current experience is limiting me in knowing exactly what is possible, and in knowing what/how to ask those who DO know what's possible. I apologize in advance for those gaps and any bad assumptions I might make.

Option One: Screw combat, make a MUSH
I haven't given up on this option. My co-designer husband would really like to have a combat system in place for even just the RP side of it, though, so even the pure RP fans would like a combat setting to work out. I know people have made some scripts to handle limited combat options in MUSHes, but it's sounded like they're underdeveloped and clunky. I'd like something that can be set up, tweaked, and then sustain itself quite nicely to be used by players without my intervention.

Option Two: Managed Opportunities for Advancement
Create completely customized races and classes to fit a modern gothic horror setting. Create all new areas for this setting, with minimal opportunities for combat and/or experience gain to even happen. Experience is granted on a schedule or manually by the staff, so nobody can grind to outpower the others. The downside is that I might get bored if I can't go out and fight.

Option Three: Managed "RW" Advancement, but with in-game "VR Gaming"
Take Option Two and implement more standard adventuring areas as an in-game Virtual Reality. My husband says that would create a geek implosion of all the known universe, but my last MUD project was with one of the creators of Starbase III (complete with holodeck adventuring), so I think it could actually work. To do this, I'd have to find some way to separate the rewards gained in the VR areas from the "real world" (RW) advancement. Such as...

A) Remove experience gain from the VR. Maybe allow lesser amounts of cash from MOBs, maybe charge cash to go into the VRs -- like a kind of game where you can use RW money and convert it back out. The difficulty here is what to do with equipment, unless I want to make it the kind of game where you can use what you bring (like a holodeck), and you can "buy" or "win" stuff inside the environment that will persist outside the game (like an on-deck replicator).

B) Implement a "Two-Tiered Reality" system, where every room/area is restricted as to what types of abilities may be learned and used. The VR area would ONLY use Class skills and experience could be gained to enhance ONLY the class, whereas Racial abilities would ONLY be usable in the RW areas, and improved using ONLY training credits granted on a schedule or by the staff. The same inventory issues would apply.

So... do any of those thoughts sound feasible to anybody using one of the AFKMud or SmaugMud forks? I'm leaning toward this code family because it seems the most currently stable, flexible and actively supported. I'm sure there's even better options for solving my MU* idea, but I'm kinda liking Option Three-A. Am I utterly insane?

Thanks a billion for taking a look at my post, and for any insights you may be able to give. I used to be known for my love of taking code and making it do things the designers never intended, but I realize I may be taking that a little too far this time...

After all that, the "wouldn't it be cool if" factor has kicked in. If anyone has ideas on options Two and Three, please send 'em my way! In the meantime, I'm sitting everyone down for the Ideal Feature List and make us make some decisions.

A world-within-worlds approach certainly sounds interesting. If it's just to kill time and doesn't have enough rewards, it might not quite work. Also, it can be dangerous to have lessened rewards: assuming a good enough virtual reality, there's not necessarily a reason why the things you learn would be less valuable than the "real thing". Even disregarding that, by having a "cheapened" experience, people might feel ripped off and therefore not enjoy it as much.

An assumption in your post seems to be that you cannot balance experience gain from combat and non-combat activities. If your non-combat activities are rewarded based on a schedule of some sort, why not just use the exact same schedule for the combat activities? You could cap the amount of XP gained to match the schedule, which IMHO is a reasonable thing to do anyhow because there's only so much you can learn in a given amount of time.

I think that in this kind of system, the excitement from the fight has to come from experience itself, not the reward. People enjoy RTS or FPS games because of the tactics/strategy. If the only enjoyable thing about combat in the MUD is getting XP or items, something is probably broken. To be honest, this is true whether or not you're worried about balancing XP with non-combat activities.

Well, just some random thoughts; hope this was at least a little useful.

Very good thoughts, and similar to ones that have started to percolate up in the back of my head today. I could put in a cap on XP gainable within a given day on a given character, especially if I go with non-combat xp granted on a schedule. Since I have no plans of trying to cap the number of characters available to a given person, the most OCD among us could then switch to another character to keep grinding if we hit the cap. (This, at times, includes me.)

I do agree that there being little to do OTHER than grind for xp/items is a very bad sign, but I'm also really thinking of people who'll gravitate to that over other options simply out of habit, or to grind up to cause problems for others. May be solvable by allowing only consensual PK, but it's still something I actively keep in mind. I'm against "behavior enforcement via computerized cattle prod", but I would love to create a design that promotes and rewards a more "balanced" playstyle, and encourages "potential problems" to play on a MUD that better suits their wants.


You make a very excellent point. Now that I think of it, I'd feel like I was doing something cheap, trying to pitch a VR as "realistic", but not "realistic enough to actually learn from"... which doesn't make sense to me. If what I build/write can't even make internal sense, I feel like I'm not even trying.

One thing I may try to do is have the VR xp be lower than non-combat xp gain on the basis that it really is just virtual experiences, but I'm not positive exactly how to balance the xp to begin with. I was always a builder rather than an admin even when I did pro work, so my approach is to figure out WHAT I'm going for, and then learning HOW to do it. I figure, once you got the "what" in mind, the "how" usually finds a way of working itself out... eventually. *chuckle*

I think this is an excellent idea in general, however perhaps some players don't want what you or I think is balanced play. Perhaps some people only enjoy one kind of play: there are those who only want to partake in social activities, and others who only want the combat aspect of things. While I think that having many options available is a very good thing, perhaps it would be good to pick a theme for the game and focus on that. Instead of doing several things well, it might be better to do one thing very well. I'm not completely sure about this, but I often wonder how feasible it is to accurately balance very different styles of play. Perhaps the solution is to offer several games, not several facets to a single game, although of course that has issues of its own...


It's an interesting question. I've never learned things in a VR before so I don't know exactly how it works. That said, I think there's something to be said about learning when something really valuable (as opposed to simply real) is at stake: you have a much higher incentive to try hard, to reflect, etc. I've seen people play games they don't care about and make stupid mistakes over and over again because they're not trying, but then the same person, when put in a situation that matters to them, will start learning much more quickly.

Either way though, by establishing this bias you establish the bias of the entire game, which might be exactly what you want to do in the first place. Since you seem to want social activities to be the main focus, and the combat grind to be a pastime of sorts, it makes sense to encourage the former over the latter; the XP bias is a way to do just that. Working out the numbers is an interesting question, but even a rather small penalty on the XP gain would (should?) be enough to indicate the intended main activity.

Of course, without a cap on the XP, the grind can still give more XP than anything else, as long as you can repeat it enough times in the same amount of time.


I agree with you, and it's certainly a much better approach than working out the "how" before knowing the "what". (Seriously though: it can be a big problem to just start coding without having an idea of where you're actually going with it. You might end up having to scrap many hours/days/whatever of work.)

Yeah, that's always been my big problem in defining a project right there -- where to draw the line with feature creep. I would have no problem at all with folks who only want to go in and do the combat side, so long as they don't try to wreck the social side when they get bored -- OR vice versa. My goal I think would be to do one thing VERY well and one other thing FAIRLY well (or both very, if I could pull it off), where both are considered viable options based on what someone just wants to do. It's just usually been easier to make a rewarding grind...


I can't say I learned that much because I've never had anything at stake, but my brother got some good training in his flight sim (Air Force) and a couple friends of mine get some real benefit from their racing sims (pro Grand Prix racers) ... and I think that illustrates what you talked about fairly well. They had to be concerned about practicing so they could perform better with VERY expensive pieces of equipment, so they learned more than I did (which is to say, not at all), but it still wasn't quite as good as actually being out there.

It seems like it would actually be beneficial to pick a bias for the game, and then play with the balance to make sure that the VR world is fulfilling without overturning that bias. Feeling it out, I think it's very accomplishable, I'll just have to get in and see what I can make of it. I will say that if I can't make both feel WORTH playing on their own merits, I'll have to scrap the "two realities" idea since a badly implemented feature is worse than just leaving it out.

Thanks again for the sounding board! I'm still trying to settle on a codebase to use. I'm honestly considering CoffeeMud even, since my scripting background is stronger than my C, it's just a matter of the resource hogging of Java... AFKMud is attractive through sheer content, but then, I have this love of having way more features than I'll ever plan to use.

I agree that it should be possible to have a primary focus that you do very well, and a secondary focus as well. And yes, it is typically easier to make combat rewarding with game mechanics.

I also agree that both "realities" would need to stand independently of each other, and be worth playing.

I'm definitely curious to see how this goes!


Java has gotten much better since its early days in terms of resource consumption. It's not all that bad unless you have fairly draconian hosting limits. Still, the best way to find out is to just turn it on and see what happens in terms of memory usage. CPU isn't an issue, since MUDs don't do very CPU-intensive operations to begin with, and even then, Java JIT compiling will help a great deal. (Looking at benchmarks, Java can be quite close to C/C++.) I've written plenty of Java that needs to be fast, and know many people who have as well; it's really not that bad at all.