KaVir asked me recently what sort of building tools or building interface I'd like to have for GW2. Now, coming from an LP mud, my idea of building tools is a text editor and an ftp program. So I'd like to know what other people use and what is their experience with different systems, what are the advantages and drawbacks, and what useful addons or interesting new approaches you have seen and worked with.

I'm interested in both interfaces and scripting systems... and pretty much anything else you can think of. Mapping the terrain, so to speak.

I work in ROM, but much like yourself, my basic tools are the DizzyMUD Builder's Guide, a copy of the source code, and a text editor (with hi-lighting for .are files).

However, I also use a GUI - Nick Gammon's Area Editor. I've become quite addicted to this. It allows an overview of the area not possible with the raw file, and certainly not possible with OLC. Mobs, objects, rooms and resets are presented in a list in the left panel. Click on one, and its 'stats' appear in the right panel, and may be edited with text fields, drop-downs, and radio buttons or check boxes. It's hard to describe how efficient it is, but as one measure - there was recent discussion about redoing an area, and the consensus seemed to be it was often easier to start over. Not so with a good GUI - I've honed the original ROM areas to near perfect balance and grammar.

I'm not sure if something like this is within KaVir's pervue, but if anyone ever offers to make one for you, I'd jump on it.

Other tools that are handy are commands from within the MUD that can return lists for comparison. Like, a list of the dam dice for all level 3 weapons. The AC of all level 5 armor, or conversely, all armor with a total AC of 15. It helps to be able to search for affects, as well.

BTW, if I was starting from scratch, I'd put all the weapons in one file, all the armor in another. Much easier to balance that way.

If you were starting from scratch, I'd keep each individual item in it's own file. It's easier that way. I'd also limit the variance of the power of an item or a mobile. If it's supposed to challenge a player with a powerlevel of x, this item can only by powerlevel x+/-y.

But I completely agree. That the one of the most overlooked components that coders don't do is build useable, accessible and powerful content generation systems. MMO's use 'em. It would help make the builders role easier to transition into, and give them the ability to develop better content faster. Beyond that, a customized Content generation system allows the coder to develop powerful reporting tools so that the admins can quickly go over items, mobiles, and rooms, to make sure that they fit within the pervue of the MUD.

My basic building tools are a text editor, the zone files and an FTP program too, since I do almost all my building in file nowadays. One thing that I couldn’t live without is of course the DG_scripts, so unless KaVir hasn’t already got something equivalent to that implemented, that’s what I’d suggest. I worked with mob_progs too in the past, but found the DG_scripts vastly superior.

Most Muds of course have an OLC for on-line building, but GodWars is obviously quite a bit different from what I am used to. From talking with KaVir I gather that there are coordinates instead of actual room and that the ‘room’ descs are generated by the code based on the player’s stance among other things.

Perhaps it would be a good idea if you’d explain a bit how the Godwars code works for builders, preferably in the new thread I just made below. I’d like to collect some solid information about all different codebases in the same place if possible.

Please note that 'GodWars' is a Merc derivative, and therefore building on it works very much like Merc, ROM, etc.

What Alayla is talking about is the sequel, which is coordinate-based, and will have building tools that are completely different to most muds. In particular there will be no options for writing descriptions, as these will all be handled by the code - instead the tool should revolve around terraforming. Examples might include being able to generate an island or forest, connect a river to the ocean, do a match-check to ensure that the pieces of world fit together correctly, and so on. I'll try and have a think about what sort of options may be needed and then post them in another thread.

If you can find a method, KaVir, of creating a program that will allow your builders to map out regions and have the engine convert them into a file that your code will be able to understand, it would likely be infinitely easier than having the builders try to lay out regions within the MUD itself.

Perhaps it would be a good idea if you’d explain a bit how the Godwars code works for builders, preferably in the new thread I just made below.

Will do. My main intent in starting this thread wasn't getting particular advice (since the mud is very different indeed), as much se seeing what systems there are out there, what people like and what proves tiresome, educate myself and maybe find inspiration.

If you can find a method, KaVir, of creating a program that will allow your builders to map out regions and have the engine convert them into a file that your code will be able to understand, it would likely be infinitely easier than having the builders try to lay out regions within the MUD itself.

There's been talk in the past (and I can't recall who has implemented it and who hasn't) about graphical maps, and reading them in pixel by pixel, allowing a Builder to quickly generate the layout in terrain rather quickly. I also seem to recall people talking about using the same system for resources, and other bits. So then they just load these maps into the system and it creates the area for you.

For a previous incarnation of my project, I coded a system that took a simple ASCII map, and made the rooms for me. So if I wanted too I could just toss it out and start over. Or make quick additions.

But to bring it back, to Alayla's original question, I don't know too many people that have actually flashed around shots of the their OFC and the GUI involved. The only one that I know of is MUD32.

(these were taken during various extremely early stages of development - I have others displaying the region tree, too, but they're not very interesting)

I should mention this is all done online: many of those screenshots were taken while editing the database of our development chat server. The rest were from a local instance of Aetas running on my Linux desktop.

What is:

(Um... I had a screenshot of it, but it seems unifex deleted it - I'll ask him to make a new one.)

The Glorious Future: Sadly, it's not implemented. Imagine something really spiffy. I outlined some of my ideas in the Coding forum.

--

Now, as for KaVir's system in particular, you'd probably essentially have a palette of different tiles, possibly organized by category, that you could arrange on a large grid, and then have a layer on top of that for positioning placeable objects (I'm not totally sure what those are in gw2), with a more traditional editor like ours for editing non-spatial data like scripts and npcs.

Some further comments as requested by Alaya, though they may prove more useful to others, and they are certainly a view of Diku from a MUSH.

Certainly, we all appreciate the power of a command line, and being able to type in an invocation and have it affect the world is cool, indeed. However, I was once wandering through Miden'nir and saw a Goblin wielding a pair of "Soiled Shorts". While I understand how clever re-using the vnums was in the days of DIKU, I really think it should have been fixed by Merc. So, at the top of my list is the ability to address things by a discreet vnum.

My major complaint with all OLCs I've used is the text editor. Being limited to one line really breaks up the flow of my writing. The gymnastics needed to move a sentence from the beginning of a description to the middle, given it's likely to need returns in different places, are a pain. Give me long lines, or give me.... well, it's not that serious, but suffice to say, I don't have OLC on my MUD.

Windows are wonderful, but if you can't resize them, they are more like pages. I like to be able to have two windows open, side by side, so I can compare things while sitting back and sipping coffee, without having to flip back and forth. Also, little sub-screens that pop up and constrain the focus drive me crazy.

Being able to wander through town, see a mistake, and fix it on the spot with a single command, is invaluable. If you don't fix them when you see them, they often get forgotton. I really do wish I could do this on my MUD. My current system system requires me to open another program, find the file, fix the error, then FTP it to the server. The fact I put up with this merely underscores my preference for a GUI, however. The power of a MUSH Wizard, to fix anything, code or text, on the fly, without rebooting, should be the ultimate goal of anyone creating a game server, IMHO.

Certainly, we all appreciate the power of a command line, and being able to type in an invocation and have it affect the world is cool, indeed. However, I was once wandering through Miden'nir and saw a Goblin wielding a pair of "Soiled Shorts". While I understand how clever re-using the vnums was in the days of DIKU, I really think it should have been fixed by Merc. So, at the top of my list is the ability to address things by a discreet vnum.

I think vnums should be abolished as a user interface. See ColdC with its symbolic object names, or MUCK's @register for that matter. It might be nice to have a hierarchical namespace for these symbols, possibly with some kind of context sensitive lookup in the command line interface.

Sandi wrote:

My major complaint with all OLCs I've used is the text editor. Being limited to one line really breaks up the flow of my writing. The gymnastics needed to move a sentence from the beginning of a description to the middle, given it's likely to need returns in different places, are a pain. Give me long lines, or give me.... well, it's not that serious, but suffice to say, I don't have OLC on my MUD.

This is one of the primary reasons I'm writing a custom client. I can't stand line editors.

Sandi wrote:

Windows are wonderful, but if you can't resize them, they are more like pages. I like to be able to have two windows open, side by side, so I can compare things while sitting back and sipping coffee, without having to flip back and forth.

This actually ties in to one of the problems I have with our current editor interface (the one I don't have a screenshot for at the moment), which is that it's an MDI application. See, the problem with MDI, aside from the fact that it's just stupid and wrong, is that having all of your windows as a child of one big useless parent window wreaks complete havoc on those of us who use multi-monitor setups. I'm not a huge fan of tabbed applications either for very similar reasons, although this can be mitigated by supporting multiple toplevel frames as well.

Sandi wrote:

Being able to wander through town, see a mistake, and fix it on the spot with a single command, is invaluable.

This is why I think a custom MUD client with a decent text editor and some other utilities built in is an optimal solution. There are some hacks like mudftp that allow you to almost do this with external applications, but I think it would work a lot better if everything was fully integrated.

Sandi wrote:

The power of a MUSH Wizard, to fix anything, code or text, on the fly, without rebooting, should be the ultimate goal of anyone creating a game server, IMHO.

Oh, it's not just game servers. It's language environments in general. Lisp and Smalltalk people have been proclaiming the advantages of dynamic, on-line development systems with things like interactive debugging and live code replacement for decades, and have been mostly ignored. I would suggest to anyone who is interested in this stuff to go to the Squeak website, download it, and write a small Smalltalk program. It's just a completely different way of doing software, and it is grand.

I prefer command interfaces and text editors meself. I've used things like MZF and Gammon's editor but found them annoying. Not a first, but annoying in the sense that they seem like training programs; good for someone who doesn't build much or is learning to build.

Now I'm not much of a builder meself, but I have built two areas for Merc and ROM. It didn't take long for me to deep six the GUI, and start using all the marvelous features of my text editor on Mercish zone files.

Scandum has a good point in the other thread regarding the direction of MRMud files. That is to produce more human readable text dumps. One way to do that is to do away with codes and produce English (or whatever language that makes sense).

See Eiz point about vnums above. Tiny and MOO and many others have\had the same problem with dbrefs which are pretty much the same nonsense as vnums. Cold does away with that both online and even in database textdumps by using symbolics, and even automatically generated instance symbolics to represent objects. Name collision detection is done automatically as well.

I think I did a lengthy post on the matter elsewhere discussioning symbol tables and automatic name generation. Maybe I'll reprise it and post it in the coders forum.

------
Oh and lastly, online text editors in muds are feeble things. If one is going to do productive online building (and coding) I think embedding better editors might be an good avenue to explore. Of course some people have. Mud++ I believe embedded, or tried to, some stripped down version of Pico. George Reese (I think it was) developed a MudFTP interface for LPmuds where one could use things like Emacs to load, edit and save remotely. There's some Mush/MOO clients that have nice cut and paste capabilities matched to Mush/MOO commands.

I use a small tintin script which opens a terminal and editor of choice. It only works well on small descriptions; mainly because nobody bothered to complain yet. It also requires the mud to display descriptions in such a way they can be captured.

The most useful olc option is probably a map that can be r-clicked and allows editroom/editresets/goto/etc. This would require mxp or an xml terminal.

I feel obliged to point out that MZF is not in the same league as Gammon's Area Editor. Not to say that Nick's program doesn't have a few flaws that would be fatal if there were anything else on the market, but to suggest that unpleasant experiences with the free GUI editors should not disuade one from trying to develop a decent one. (Nor do I ever recommend AE without also recommending TextPad or UltraEdit. You need both.)

eiz, thanks for the link to Squeak. Looks like really good stuff.

(Boy, reading the history of Small Talk brought back memories... 360/33's were my downfall, really... I greatly resented the absence of the STOP button (necessitated, of course, by multi-tasking). I so enjoyed the power of being able to halt things at the current address and hack the code. Suddenly, Operators were mere operators, baby-sitters, firemen stoking the boiler... it was as if the Navigator suddenly superceded the Captain. But I digress... (but not that far if you think about it, compilers ARE evil!))