29 Sep, 2006, Davion wrote in the 1st comment:
Votes: 0
Several of us have spent time digging through our OLC code adding features to let our builders have an easier time, as well as make the interface as natural as possible. Some of the additions that have been mentioned are auto-digging and auto-assigning vnums. I have implemented a template system for mobs, and objects that let you get a basic object/mob to modify. Ie.

medit create 2122
level 20
template warrior

Then the stats and class would be set up for a warrior (low mana, high hp, skill based. Lots of hitting. No spells. Set a spec function for it, etc) all based on the level you set it at. The Objects pretty much the same, though there's a lot more to it. 'magic sword' would set flags, 'evil sword' would set another set of flags. Also mentioned where randomly generating maps so builders don't have to pound out the shape of an area all the time. I'd love to hear more ideas. Possibly get someone to add it to an existing, or create a new OLC to raise the standard!
29 Sep, 2006, Skol wrote in the 2nd comment:
Votes: 0
One thing that might be handy is an 'age' or 'size' in reference to the mob difficulty. IE Race hobgoblin, age young (or perhaps handle that via level…)

Another thing I did on mine was to have the mob stats auto-roll, but an extension of that would be to have setable stats (str/int/dex etc) or rolled. That way if you don't set it, they're just rolled when create_mobile() runs, if you do set them, then it uses those. (For the really strong/weak/smart etc mobs, unique ones).

One thing I did for drink containers was to have it compute and show you the things it did (for easier building):
[v0] Liquid Total: [1000] Drinks Total:[200]
[v1] Liquid Left: [1000] Drinks Left: [200]
[v2] Liquid: [red wine] Drink Size [5 ]
[v3] Poisoned: [ No ] Proof: [ 30]

It does the same as original, but is much more informative. By computing drinks left (based off drink size from liquid type) etc. Just gives much more info which can help builders make better areas.

This kind of thinking can be used throughout OLC as most of it was left wide open (at least in the version I use rom 2.4b2 olc 1.7 I believe or previous, I've modified it for so long I can't remember).

One thing as a table-top gamer… I'd love to see swords be d6/d8/d10 for dice, daggers d4/d6 etc, I've seen some funky crap over the years. Daggers that are 12d12 etc. As an old DM it makes me want to slap a builder ;p. But that's probably more constraints than most want in an OLC.

I think one thing an OLC could do nicely is to standardize stats on mobs and objects. Seeing a level 40 rooster in a 101 level game… makes me want to slap a builder. So perhaps a generic race table with max/mins for level, auto sizes, damages etc.

Anyway, I ramble. :D
30 Sep, 2006, Valcados wrote in the 3rd comment:
Votes: 0
One thing I've been thinking about lately is the idea of having the MUD track mob difficulty on a mob by mob basis, by recording how much actual damage it does, how long it lasts, etc. If you trace the development of many advanced hack 'n' slashs MUDs, you'll see that early on, they enjoyed very sensible exp calculation code which did a great job calculating exp on the fly based on simple principles. As the code evolved, new features were added into combat, but not accounted for in exp calculation. It's particularly bad in SMAUG, where it's reached a point where there's almost no correlation between how "hard" a mob is and how much exp it gives. What would be nice is if imms could simply calibrate the system, for example by specifying how much exp a specific, fixed mob ought to give out, and the MUD would then gather statistical data and adjust all mobs according to the calibration. I probably won't have enough time to actually work on this any time soon, but it seems somewhat on topic in this thread so I thought I'd bring it up. :devil: As a former builder, lemme tell you, I sure appreciate coders who do things to help OLC :biggrin: Keep up the great work :alien:
30 Sep, 2006, Guest wrote in the 4th comment:
Votes: 0
You can use a client buffer to write rooms without bothering with that.. you can set up a script in notepad like:

north 1024
north
east 1025
east
south 1026
south
west 1027
west

for instance, to create a loop and just copy+paste into telnet. there is also the ability for mobs to dig exits and have some limited power creating and manipulating objects built into NiMUD's OLC language
02 Oct, 2006, Justice wrote in the 5th comment:
Votes: 0
Of course online creation can be improved. The trick is knowing how, and I assume what is needed varies from mud to mud and area to area.

What I do is look at where builders spend the most time. In my mud, that's generally writing descriptions and adding links. I've found the average builder can generally create a mob or object in a matter of minutes.

I've implemented tools to simplify the creation and linking of rooms. Personally, I don't mind if multiple rooms in an area have the same description… within reason. Consider this… when building a wilderness area, virtually all rooms have the same sector, flags, etc. Because of this, I allow builders to copy a single vnum onto multiple rooms. To add a little flair, you can copy multiple vnums onto multiple rooms, which selects the copy vnum for each room randomly. The builder is of course, free to change anything. Often this is done by leaving the copy room's description blank and filling that in after the room is linked.

Besides repeated attributes on rooms, there are common linking patterns. It's common to use a "grid" of rooms to represent a large open space, like a field, ocean, pond, square, plains… Another common pattern are winding pathways like mountains, forests, tunnels tend to use.
My room linker is capable of linking rooms in a grid, with the x and/or y axis wrapping. It can generate random linkages with or without a coordinate plane. Without a coordinate plane, no branch ever connects to another branch, the coordinate plane can detect when 2 rooms are adjacent and has a % that a link will be formed. Additionally, it prevents rooms from overlapping. I have a directional link which can link 2 grids on top of each other (on the ocean, under the ocean, oceanfloor, in the air). It can also generate straight lines. Finally, I have a "maze" linker which takes 2 sets of vnums and populates all exits in the first set to a random room in the second set. It can optionally add the randomize exit reset to the room.

In a smaug, alot of effort is necessary to setup resets. You need to load the eq, give it to the mob, force them to wear it, then instaroom. It's not that difficult for a single mob, but quickly gets monotonous if you wanted say… 5-10 guards in an area with 3-5 pieces of eq each. A dozen citizens… etc. To help with this, I've written wear templates which allows you to build the eq set once and "apply" it to each mob. The steps are identical… load the eq, give it to the mob, force them to wear it, create template. Although you can avoid the second/third step by wearing it yourself. This assumes you don't have any "god" eq. I'm working on adding templates to the prog and script code available to me, and giving mobs/objects an onload trigger. The idea here is to allow the mob to apply template when it gets loaded. this reduces the # of resets and makes it easier to change the eq a mob wears by re-writing a template. It also has the option of randomly selecting a template (templates?) on load. The only issue I can see is that it prevents different mobs of the same vnum from using different eq. A solution to this is to have a reset that applies the template.

Finally, objects and mobs are tough. What I do for these is pretty simple… and doesn't require any code. I have a massive area where I build "props", or generic examples of objects. These are level balanced, and have appropriate stats. They can be used "as-is" in an area, or copied onto a vnum for minor changes to be made. What this does is frees the builder up to work on important mobs and objects, leaving generic citizens, animals, guards etc. It allows the builder to create shops and eq sets for the mobs with a minimum of effort. Since there is a central set of eq used for reference, it also helps maintain the balance of the game.

In the future, what I'd like to do is allow builders to generate batches similar to aliases. The idea being that a builder writes the commands in a buffer similar to progs, and uses $0-$9 for variables (as is common for clients and aliases), then executes the batch using the appropriate arguments. This will allow builders to create mini-commands to find things that need to be repeated, but are monotonous.

For now the scripting system is providing this task (and better imho), for example, a builder recently used my copy code to generate 1000 rooms from a small set, and discovered that he screwed up the flags. Since the flags in question weren't in every room, a simple rat wouldn't work. We wrote a script that takes a single room, checks if a flag exists, and if it does, removes it. We then ran a loop for each vnum and removed all the offending flags with a minimum of manual labor.

Anyway, just a few ideas on the time-saving features I've added for builders. Oh yeah, Valcados, I've long since contemplated better logging. What I think would be nice to have is a sum of combat rounds, damage received, and damage dealt. Maybe an average numfighting and max numfighting. When an NPC dies, this information could be stored on the index and used to generate a sum/average for that vnum. Of course, still thinking about it, this info would be greatly skewed by players of different levels attacking the same mob. You could increase the info available to account for this.
03 Oct, 2006, Guest wrote in the 6th comment:
Votes: 0
While ours may not have been a colossal improvement, we did simplify the tedious details of mob and object creation to some degree by allowing the code to handle calculating stats on mobs and some portions of objects if they had certain things set to an "autocalc" value we determined ahead of time. It saves quite a bit of time in the long run.

We also installed the Smaug port of the Oasis OLC code to make working on things easier for those who don't much care for the command line. Personally I can work with both, but I do tend to think the menu driven controls are easier to learn.

I'm also looking forward to seeing what Darien comes up with in his new Rom OLC he's working on. :)
03 Oct, 2006, Justice wrote in the 7th comment:
Votes: 0
I've found that the usefulness of menu systems over command line depends on what you're doing.

Menu systems are easier to learn, and tend to work well for prototyping something. Command line interfaces are better for quick finite changes, such as tweaking. They're also faster if you know them well.
03 Oct, 2006, Brinson wrote in the 8th comment:
Votes: 0
I prefer command line for speed.
03 Oct, 2006, Splork wrote in the 9th comment:
Votes: 0
Kjartan built Sloth's OC over the course of its first few years(92-93). I'll be honest, while it is original, it can some times be brutal on new Immortals. While we continually add to ours in the hopes of making things that much easier, I am looking forward to seeing what Darien comes up with as well.

Hopefully it will provide everyone with ideas(and maybe even snippets) that we can use in our own codebases.

Splork
04 Oct, 2006, Omega wrote in the 10th comment:
Votes: 0
Dariens OLC is called ROCS (Rom Online Creation Suite) Incase you must know, and its in allot of development.

I'm not going to get into all the neatoness of it, but, anyone who uses it, will beable to use area's from any other ROCS mud. How is this done, well, if you can't figure that out yourself, Id recommend learning alittle more about the ROM code.

But ya, as for features, you can expect allot of COOLNESS, i really don't want to say too much about it right now, because I want it to blow all your minds when it comes out, plus i don't other people seeing the neato little features i've got planned and pre-release them for Ivans, or add them to their own base.

Tis all a big secret :)

Notably, being raised by a security professional, and am in the business of security myself, it has one of the most powerful built-in security systems for an OLC system.

You'll all understand when it comes out. But i'll tell you this, Its going to be great.

So-far the demo-product of it, is capable of saving the area's to the new format, and loading the new format.

I'm now adding the features to change vital data, add more data to everything, and give better features to play with.

So Just be patient :)
04 Oct, 2006, Brinson wrote in the 11th comment:
Votes: 0
You know what I'd love to see?

Areas that aren't vnum dependent, but rather the vnums are assigned when the area is loaded.(or something else to that affect that I haven't thought of)
This way when people install stock areas they don't have to worry about conflicting vnums.
04 Oct, 2006, Conner wrote in the 12th comment:
Votes: 0
I'm not sure how you'd be able to accomplish that, but it would create some interesting possibilities.. though it'd be a mild night mare for any items or mobs or even rooms that are hard-coded in if their vnum changed each time the areas were loaded up.
04 Oct, 2006, kiasyn wrote in the 13th comment:
Votes: 0
mobprogs would be a pain.
04 Oct, 2006, Conner wrote in the 14th comment:
Votes: 0
That's very true too. You'd be talking about having to change a lot of very fundamental components of the mud, at least for Smaug anyway.. I can only assume that most of the other codebases out there would have at least similiar issues though.
04 Oct, 2006, Cratylus wrote in the 15th comment:
Votes: 0
I've seen some nifty GUI-based builders for diku derivatives…
just click the checkbox if you want this or that, put in the number
for the level, etc. Pretty cool.

Are there diku builder apps that let you map out rooms? You know,
like draw a line from this box to the next box and that's your new room,
then you can add the description.

-Crat
http://dead-souls.net
04 Oct, 2006, Brinson wrote in the 16th comment:
Votes: 0
One called Genesis. I haven't done much with it but toying it seems pretty neat. I'm not sure the area type output but it says it uses templates and can be adapted to any area file type.
04 Oct, 2006, Justice wrote in the 17th comment:
Votes: 0
Brinson said:
You know what I'd love to see?

Areas that aren't vnum dependent, but rather the vnums are assigned when the area is loaded.(or something else to that affect that I haven't thought of)
This way when people install stock areas they don't have to worry about conflicting vnums.


Having attempted this, I can honestly say it's more of pain than helpful. Vnum conflicts are the only reason I know of to do this, and they're generally easy (though tedious and time consuming) to resolve. Someone posted a renumber utility here, which I haven't looked at yet.

That being said, I've got a codebase that does this. It's a scratch C++ codebase (GZA 0.1a) that is based on the pk mud GroundZero. Basically the "area loader" can offset the vnum during load time. As people have mentioned it does create some difficulties, but most of these are easily resolved. The difficult one is how to deal with progs, well… scripts in my case (I use javascript of course). What I ended up doing was giving rooms, mobs, and objects a "keyword" and the keyword can be used to load them instead of a vnum.

This allows a fair amount of flexibility because if multiple objects have the same keyword, the actual object loaded is chosen at random. Of course… the GZA code is designed to play like GZ which is a DIKU, but the code is radically different. Objects are composed of multiple types, which generate events that can be picked up and chained together.

A simple example of this would be the "napalm" object type. Which has a 'timer type' that pulses 10 times, once a second. Each "pulse" triggers a 'damage type' that applies 'fire' damage to the room. After 10 pulses, the timer fires an 'alarm' event, that triggers the object's extraction.
05 Oct, 2006, Conner wrote in the 18th comment:
Votes: 0
Cratylus said:
I've seen some nifty GUI-based builders for diku derivatives…
just click the checkbox if you want this or that, put in the number
for the level, etc. Pretty cool.

Are there diku builder apps that let you map out rooms? You know,
like draw a line from this box to the next box and that's your new room,
then you can add the description.

-Crat
http://dead-souls.net


I haven't seen any like that yet, but would love to. Hell, I think it'd be awesome if one of the various area editors could even just load the file and give you a graphical representation (line drawings would be ample) of the rooms in the area, let alone being able to create them that way.
05 Oct, 2006, Brinson wrote in the 19th comment:
Votes: 0
No one reads my posts, eh?

http://bmedia.t35.com/genesis
05 Oct, 2006, Conner wrote in the 20th comment:
Votes: 0
Brinson said:
No one reads my posts, eh?

http://bmedia.t35.com/genesis


I quoted a post that came before yours, so it ought to be reasonably obvious that I hadn't gotten to your post yet.. Justice posted in response to one of your posts, though plenty of us have done that, myself included.. so what makes you say that no one reads your posts?

As for your link, that looks pretty cool, but, as you pointed out in your post that no one read, how do you tell it what the format for your area files is?
0.0/71