Well, I thought it was pretty nifty still. :thinking:

Offline or online does not change a lot anyway, you could have a thread polling for any changes in the files/db/whatever data storage facilities, and loading everything then.

Missed the second question:

The room grid should be a very capable automapper for any conventionally laid out zones. It makes a certain number of passes, which you may have to increase if your zones allow for more than 100 rooms, and builds the layout of rooms on the same level as the starting room you give it, putting "walls" for adjacent but unconnected rooms, and marking some rooms w/ up/down staircases. If the user goes up or down, the map is redrawn at that level starting from the landing room.

If the zone has spatial paradoxes like overlapping rooms or mazes etc., the grid may display some rooms with odd exits off to the right, disconnected from the rest, or it may not show them at all (if they overlap spatially with another room). We have many zones with such oddities, which is why I've added the "list" view.

The whole UI, icons included, is now in the repository. It's been debugged pretty thoroughly and includes a few other niceties beyond the screenshots posted here.

@KaVir

I realize I was a bit grumpy with you earlier in this thread regarding the O in WebOLC. The bottom line is, given the level of effort vs. value, I will always consider a web UI for in-game creation a "developer's toy" feature, to borrow a phrase from one of your recent post on TMC. Especially since telnet OLC is already a given in nearly all servers, and does its job fairly well as a tweak tool.

Where telnet OLC struggles is in 'macro-editing', and this is what I wanted to supplant. I designed this tool to make area building easy for lay people, and for MUD admins to have an easier time balancing a large amount of areas. For anyone who runs a developer instance and runs quality control on stuff they add to the production instance, this should be very near an OLC replacement even in its current implementation.

That said, if you're looking for something capable of in-memory editing, feel free to download the package and take a look at what it would take to make it your true OLC "developer's toy."

Also, the absence of a license is the license.

When I used the term "developer's toy", I was referring to features that don't really add anything useful, they're mostly just an indulgence for things the developer finds cool or wants to test out.

An example from my own mud might be the code for assigning a gender to new characters, which uses a combination of pattern matching and a soundex parser to guess if they're male or female. The previous solution simply gave them a 50/50 chance of being male or female, and I doubt anyone would have even noticed the change if I hadn't documented it.

But OLC isn't a toy, it's a tool, and it has some very strong advantages over offline building. It's no coincidence that most muds long ago stopped using offline building tools, and instead added support for OLC.

P.S: An absence of licence means an absence of explicit rights, unless the work has been placed into the public domain.

In my experience as builder and then dev, a large part of the appeal of OLC had to do with the fact that I could build from any computer and not have to keep track of files. Another advantage was that the OLC was usually in sync with any game customizations while the old offline building tools were generic and their output required further tweaks. Both of these advantages are preserved in a web-based building tool that connects directly to the world data. (In fact, I remember that in my building days I felt both OLC and offline tools fell short of the flexibiltiy I wanted, so I used an advanced text editor for the first draft of some pretty large zones. This tool is my attempt to produce something I would have liked to have back then.)

I think this tool needs to be judged on its own merits, and not by lumping it together with old offline off-browser building tools (from which it differs in many important aspects), or by dismissing it on the basis that it doesn't automagically know how to update your live game while it's running. Like I said, if you already have methods of in-memory editing, then you can hook this interface to your live server as a user-friendly extension to your existing OLC. All this is is a bunch of pretty smart, modern, web forms that (IMHO) make macro-editing easier and more intuitive. If you looked at the screenshots and don't agree, then there are obviously no action items for you here.

I enjoy building online because of the social interaction and everything else that is present while building. I couldn't do a builder port, an offline building tool, etc. because the social aspect of MUDing is very important to me. Sure, I could have the MUD up while also building on another port or in another window, but honestly, I'd much rather do it all in the same window. When I'm coding, I'm rarely social on the game because most of my time is in another window, and it breaks my concentration to constantly be switching back to the MUD window to see what the latest chat is. So usually, when there are a lot of people on and a lot of socializing going on, I'm normally not coding. That's when I'll do some of my most productive building, however.

But anyhoo, that's my 2 cents. I think it's great when someone is putting effort toward thinking outside of the box and doing something that might help promote any aspect of MUDing, making building more accessible, easier, or quicker… so good job! But I thought I might throw in my perspective, and I suspect the perspective of others who might not find an offline or browser based building tool something they would be likely to use.

It might be something for MUDs to consider offering as an option for their builders, though, because what fits for one doesn't always fit for others.

One of the main advantages of OLC is that your changes take place instantly, and everyone shares the latest version. That means you can change things on the fly (eg making adjustments for a quest while the quest is running), work together with other builders without accidently wiping over each other's changes, fix problems the moment they're drawn to your attention and have your corrections applied immediately, test things out while they're simultaneously being developed, get other staff to walk through your area proof-reading your work (and correcting it when necessary), etc.

Your offline editor "requires a reboot or soft boot for any changes to take effect", which means it disrupts the gameplay - so in practice you won't want to update it very frequently or it'll annoy the players. If two or more builders wanted to work together on an area, they'd have to take turns. Will you have some sort of version control system for that, or would they need to organise it themselves?

KaVir,

I feel that we've covered this ground already.

If a capable coder gets exited enough by the UI, they can certainly add a real-time communication layer. A basic implementation of this could involve using a Flash telnet object to push / pull data as well as to let the builder view the world and socialize normally. This is very doable, but it will be a lot of work that may or may not be re-usable by others. I would personally recommend going that way only if you're writing/maintaining a codebase or if you're planning to turn this UI into a "both play & build" web GUI.

Another option is for someone to write, or expand upon an existing, protocol that will standardize the way an external interface updates stuff in-memory. This will increase the re-usability of the UI but again, it's a separate huge project.

Neither of the above projects passes my cost-to-benefit evaluation, but it may pass other people's. This is the reason I'm sharing the web UI part of my implementation, hoping it has some use to someone other than myself.

As it is now, from the point of view of people evaluating this UI, it is a collection of dynamic web forms, with some nice visuals. You can adapt it to your needs or you can ignore it. Getting hung up on the fact that it's not going to come into your house and bake your favorite cake is, well, unfortunate.

What is this 'macro-editing' you mentioned, and how does OLC lack flexibility?

'Basic' Olc has nothing to edit all the area rooms flag at once as an example, or sector or anything. That is macro editing. But about flexibility ? OLC does not lack any…
The UI Bedlam created is really nice, and it is probably easy enough to make it so it works real time instead of updating a databse. Or even make a command to poll the database and apply the changes whenever you want. I create dynamic area in game already (my random maze are dynamically created in game, not using any file), so it woul be easy enough to load an area after boot.

The only reasonable distinction one could draw from online vs offline creation is that latter of the two would not affect the software using that data immediately and perhaps requires importing the data at some other time. In other words, I don't believe that it's necessarily indicative of online creation to be able to edit in the same interface as you play the game. One could have online creation that's completely segregated in a web based editor, and as Plamzi says, I think it may be easy to convert offline creation to online creation with a communication layer.

Since you can just install a simple snippet to handle that, I don't really consider it a deciding (or even relevant) factor. Forget I asked.

Fair enough, but you necro'd the thread and addressed me by name, so I assumed you wanted another response. Of course you're welcome to use whatever type of editor you like, that goes without saying - but personally I moved away from offline creation 15+ years ago, and have no desire to go back to it now.

Of course this is all rather academic anyway, as your editor isn't designed to handle the sort of mud I run.

Let say it is often easier to make a db request for those case than to have to code anything. I coded some of the one I wanted, but I admit I rarely need it as a matter of fact.

Actually, I meant macro-editing as in macro-economics. The use cases where I find the new UI really shines:

* Laying out a huge new area. Initial layout of a 100-room zone can literally take 2 min. And it's a human-designed layout, not a random dungeon you can generate in code and that will forever look random. It's very nice to have a "bird's eye" view of the area you're building, and it also help spot problems, move rooms around, etc.

* Editing an area in which many of the rooms have same or similar descriptions. You can copy room properties from one cell to any other a second. If you copy to an empty cell, a room is created and auto-linked.

* Balancing an area by editing multiple item and mob stats or tweaking where and how many entities load. In addition to the fact that all entities are listed and you can jump to them easily, there are now hyperlinks that allow you to edit a mob's items or jump from the room where a mob/obj loads directly into editing it. This makes balancing flow.

* Setting flags on multiple items/mobs/rooms at once (without having to write special code for yourself or your builders).

* This one's Bedlam-specific for now: The UI lets builders see what icons the iPhone and we app will use for their entities. It helps me identify entities with missing artwork.

Interesting stuff.

Curious, if there was something like this that also allows builders to add (upload?) graphics and sound files?

Plamzi:every candy command you allow had to be coded at some point, so it could be coded in OLC anyway. What you did though is allow totally newcomer to actually use your interface and build without the need to know any commands at all, and that is the nice part of a graphical tool. Hell I do not even remember all the command I coded to ease my life when building (like setting all mobs a flag or all rooms a flag or something else). And the fact it is not graphical (and still vnum related) makes hard to select only some of an area rooms to apply the command as well.

Makes me think that if someone is motivated enoughlike you were he could probably build an interface that does everything with msdp too. That would be truly great
And it just gave me an idea..will make multiple mob/room selection possible with mxp, easy enough :)

FYI, the tool is now a true Web OLC (see the updated first screenshot in the OP). Builders can now socialize, synchronize, and see/test their changes as they make them.

After a little bit of testing in builders' hands, I'll hook this puppy to the production server so we can use it make tweaks and push updates at runtime. The in-memory update logic is actually smarter than vanilla OLC - it is careful to update existing mobiles, objects, and rooms in a way that doesn't disrupt the current game state.

@Jhypsy Shah

So far, the media is provided by us only so we can steer clear of copyrighted material. I suppose that if we allowed people to customize the web app (for themselves only), we could be more liberal about that. But honestly, not too many people use the web app to play. People fall either in the category of "I love my existing MUD client" or "I love my iPhone app".

Nice, I was pretty sure it would not take long to make it that way once you had it working offline anyway. What was your technical choice ? Updating the database and having a daemon check for changes every xxx time or the user decide himself to push the update online ?

Another question, how do you check for overpowered item ? Soa builder cannot sneak in some special stuff only he has access to ? (with mprogs as an example. so the item is perfetly hidden to anyone but the builder)