So, this is a controversial topic, but I'm curious what those of you out there who BUILD worlds have to say about this. Of all the various codebases (Dikurivative, LP, what have you), which ones had the easiest OLC system to use? Which ones felt the most powerful? Which ones did you find the most productive in actually building a good sized world?

I ask, because I stand at a crossroads. My antique DikuMUD has no OLC, and much of the world it has was built by hand, using a text editor directly on the world files. If the game is to be reborn in any way, it has to move on to a more dynamic system, and the aging C codebase has pretty much exceeded my patience for doing such a major systemic redesign.

I can easily write a conversion system to read my old data and transform it into a new format, but that won't be worth much if I end up in an environment where the new OLC is too annoying to get anything done. Combat, spells, game mechanics can all be rewritten, but ripping out or drastically changing the building interface feels far more invasive to me.

So what do you guys think? I realize I'll have to sit down and work with several systems to see what *I* like and don't like, but I'm interested in what you guys who do building more than coding have to say. What codebases or mudlibs did you like building with, and why?

Out of all the OLC systems I have worked with I would have to say (and it is just my opinion) CoffeeMUD has the easiest and most flexible system.

One feature it does not have (that I should code) is "buildwalk". I miss that from other systems.

I have always been partial to the ACK!MUD OLC, which was kept intact with just a few updates/improvements in AckFUSS. It was the first OLC I've ever used, and the one I still keep going back to. You "build" to be placed in an editor state then swap between room/mob/obj with "redit/medit/oedit" as you wish. Each mode has some common commands (toggling affects flags, adding a reset, etc) and other commands unique to that mode, obviously, like race on a mob. Everything is command driven; no menus to wade through – type and it shall be so. There are also dated, but still relevant, building guides for the ACK!MUD OLC both in the code repository and articles sections here.

Two of the "upgrades" I gave the old ACK!MUD OLC were a buildwalk (autodig as I called it) and automatic obj statting. Just walk around a zone to dig out and link rooms within the specified vnum range automatically. Then you only have to go back to hand link a few special cases. You setup a table of "max values" for objects at end-game level, with different modifiers per slot type (ie: a sword is hr/dr, a shield is only ac…etc) if you want. Then just "aobj" and the object stats are set to a % of max based either on level or level + slot type. Bonuses are also added automatically for rare flagged items.

If I do happen to sway you to my dark side, I'm always available for any assistance :)

edit: Bonus plug – the native AckFUSS area format is all key/value text fields and you could even write a small module for the Areaconvert tool I released to read in your format. Saving in AckFUSS is supported natively.

The one used in NakedMUD is fairly straight forward, and has capabilities of embeding python scripting in it. Of the few that I have used, I like the interface and power more then the others.

I've built on both Circle and Smaug and much prefer Smaug's flexibility over the menu-driven Circle. More recently I've switched to LoP (a Smaug-rikutive) that also has a few additional features. The differences show how easy it is to modify the OLC code.

Building is quick and easy, with edit mode toggled on/off, rdig to create new rooms that auto applies the next available vnum, mapout to create ascii maps that then create the rooms, vlist command to see all mob, obj, room vnums at a glance to find available ones.
Resets are simple by area or by room, including listings. You can set a random percentage on an object to load, create random exits and can create dynamic parsed room descriptions that checks and displays various info based on the player looking at it.
Default attribute values are set on npc's, wearlocs can be restricted, no need to set a class/race to an npc, objs can be created with random stats.

I could go on and on but you get the idea. Personally, I hated online building and was sad when Smaug's keyed area format could no longer fit the offline area editor I was using, but now I enjoy it. You don't feel like you're stuck in "you have to build now" style.
Plus, anyone familiar with Smaug is probably familiar with Herne's infamous building guide. Currently I am modifying it for LoP and hope to get it in as part of the code distribution, something most code distro's seriously lack.

I prefer the OLC (and by extension, DG scripts) in TBA MUD and CWG Rasputin. I can see the channels I need to see while in the menu and also talk on them, so I see no problem with sticking with menu-driven (for me).

Personally, I like the Menu systems from Circle. Because not only are they nice, but they add a bit of a safety net. You're constantly looking at the stats of something, you never need to really consult a helpfile to see what flags there are, just select that part of the menu and it'll list them for you.

Now, I've never actually built on a Circle. I've only used the OasisOLC port for Smaug. So I have very little experience with DG Scripts. But I'd venture to say that embedding Lua or Python, or Ruby would be far supierior to anything that we have on the market currently.

Now, all that said, I prefer a mixed system. Where the Menu-Based and the command line interface are both available. I hate going into the OLC Menu to make one small change when I can just "mset mob numattacks 5" instead of "medit mob;b;d;5;0;q".

For straight mob creation, the menu is great. It's hard to miss anything, because you're staring at it all between modifications. But for a quick edit, I'll always default to the command line, rather than the menus for simple speeds sake.

For those who've never seen the OasisOLC menus (Bear in mind, mine have been changed, slightly.):

– Mob Number:  [21037]
1) Sex: male             2) Name: guard man
3) Shortdesc: the guard
4) Longdesc:-
A guard patrols the streets of the city.

5) Description:-
                                                                          
6) Class: [warrior    ], 7) Race:   [human      ], 8) Level:  [   16], 9) Alignment:  [ 1000]
A) Stats
   Strength:     [   16], Intelligence: [   13], Widsom: [   13], Dexterity: [   16]
   Constitution: [   13], Charisma:     [   13], Luck:   [   13]
B) Health and Damage
   HP:  [  345/  345],  Mana:  [  100/  100], Moves:  [  150/  150]
   DamNumDice:  [    1], DamSizeDice:  [    1], DamPlus:  [   20]=[   23]
   HitNumDice:  [   15], HitSizeDice:  [   15], HitPlus:  [  300]=[  315]
   DamRoll:     [   22], HitRoll:      [    3], Armor: [     -18], NumAttacks: [   0]
C) Gold:     [       0], D) Spec: spec_guard            
E) Saving Throws
   Save vs Poison: 0 Save vs Wands: 0 Save vs Paralysis/Petrify: 0 Save vs Breath: 0 Save vs Staves: 0
F) Resistant   : 
G) Immune      : sleep charm
H) Susceptible : 
I) Position    : standing
J) Attacks     : 
K) Defenses    : parry dodge
L) Body Parts  : head arms legs heart brains guts hands feet fingers ear eye
M) Act Flags   : npc stayarea
N) Affected    : detect_hidden
O) LoadMsg     : (none set)
P) ExtractMsg  : (none set)
Q) Quit
Enter choice :

Lol, Oddly enough the Syntax highlighting looks almost like the way my menus are colored. If only the Menu Options were dark green. Now, like I said, this makes it hard to forget to set something on a mob. Because you're always looking at it all. And it lists the flags out, so you don't have to look them up. But for a quick fix, the command line is much faster, so it's really up to the individual as to what they prefer. And this is why MW does and SW:TSW will support the Menu-Driven and command line.

One of the things I like about Nakedmud is the way that the menu driven OLC is just a front end to the Python script which prototypes each room, object or mob, so you always have the choice of using the OLC or editing the script directly.

Write your own. Then you get what you want and you can make it as flexible and ease of use as you can.

Lola probably has the best editor when it comes to handling large mob/room/obj programs, it also compiles mobprogs and gives error messages if anything is wrong, does highlighting when checking a finished mobprog, and has a hyperlinked help system for builders. Given the majority of the time is spend working on programs on quest oriented muds this might be pretty important to some.

The OLC engine itself is fairly standard, with support for toggling multiple flags at once, creating and deleting links two-ways by proving the 'both' argument, an area checker that reports all kinds of problems (including overpowered items) with an option to fix them automatically, and a wizmap command that shows a map of surrounding rooms.

I've often thought that menus were nice for this reason, but I've more often thought that there are other solutions for this.

If you look to smart shells (really any of the standard ones) you get very nice tab-based auto-completion. You can do something like: ls myfi<tab> and it will do one of several things (give a list of possible completions, cycle through them, etc.).

Why not bring this paradigm to MUDs?

> mset mob class <tab>
warrior thief cleric ranger wizard
> mset mob class w<tab>
warrior wizard

One very big reason "why not" is that many clients do not support character mode; they insist on sending one line at a time. This makes working with a character-sensitive terminal shell basically impossible.

But, if you moved enough of the "shell" into the MUD itself, then the need for the client is all but obviated. That is, if the MUD itself knew about command history, completion, etc., you'd have less need for a smart client, especially as a builder where you don't necessarily care about things like combat triggers and scripting.

I hate this term because MBA types overuse it, but I honestly feel like this would be a paradigm-shifting change in how we interact with MUDs. Shells have been this sophisticated for a while now; why should MUDs lag so much?

That's my goal right now for my project. My OLC is going to hook into Lua, which will allow for a more flexible system.
This will make it really easy to add fields to each game object.

I'm a huge fan of D.A.E.M.O.N. But then again, I haven't released it yet :P ROCS all grow'd up :P

What does this buildwalk do? Sounds like you'd just walk in a direction and it'd create the new room for you as you walked, is that what it does?

Yup. It lets you create rooms just by walking around. Walking in a direction such that there is no room there will create that room and appropriate exits.

Buildwalk is basically an automated rdig. In some muds you toggle buildwalk on, and then do something like "n 2305" and it would make an exit to the n to room 2305. Other systems you just walk and it uses the next available vnum in your area.

I find myself disliking buildwalk because it adds an extra step for me in the building process. A lot of areas I'll build, the main feature will be a maze of either shifting exits or where there's a single path through and the wrong way will take you all the way back to the start. Or other mind-wrenching things. Where exits will randomly disappear. There's also the time I build an area where it would make the exits when you entered the room, and it would always be a random direction, but would always lead to the same place. So players who tried to map it, always had different maps, even when they went in a second time. Which was humorous.

Hmm. That's a really interesting feature. Which base supports this feature? I'd like to take a look at it, perhaps put an implementation of it in my mud, and give it a toggle (for maze builders like Kayle :D).

An additional feature some buildwalks have is being smart enough to know when it logically should be connecting to existing rooms. In games where the game relies on logically connected rooms it is quite nice. An easy way to achieve this would be to use a search algorithm to find a node that possibly exists in relation. You can do this by simply saving a coordinate which changes as you search. The search would be for 0,1 1,0 -1,0 or 0,-1 depending on the direction. (Also up and down exits would introduce a y)

There's a snippet for Smaug muds in the code repository here, and I /think/ Circle has it.

Also called autodig! [link=file]2259[/link]