Building in different codebases

[Molly O'Hara]

Some of you know me already. I’ll be moderating the Builders’ forum together with Alayla. Our backgrounds are a bit different, she’s been building in LP and Godwars code, while most of my own experience is with Circle, although I’ve have a past (very long ago) with Mythran and Diku too. Together we might cover most of the bases.

I don’t know how many builders joined the list yet, there seems to be a slight overweight on the coding side. But hopefully we’ll have some interesting building discussions too, once we get things rolling.

I admit the subject is a bit ‘dry’, but I’d still like to start with stating some basics about the different codebases, in particular how they work for us Builders. Alayla's post about building tools already gave me a reminder of how different our building environments are.

Sometimes it is as if we didn’t even speak the same language. I’ve seen this problem on Building Forums in many Discussion boards. You describe something that to you – and anyone else using a similar codebase – is very simple and self explanatory, but someone used to a codebase with another approach to things might interpret what you are describing in a totally different way than intended. Sometimes I have seen this lead to rather heated arguments that were just founded in misunderstandings and could have been avoided if we had known a bit more about each other’s conditions.

In particular I’d like to focus on what works particularly good – or bad – for builders in different codebases. You know; the features you love the most in your OLC. And those little irritating flaws that you might have adjusted to over the years, but still wish would be different. And since there are so many coders on this list, we might actually be able to get some input about how to get them improved a bit.

So I’ll explain the basics of Circle in a coming reply to this post, and hopefully Alayla will tell us a bit about LP and Godwars, which obviously are very different from Diku, and Sandi could perhaps tell us about ROM. And other builders can fill us in about the codebases they use later, (for instance Merc, of which I know next to nothing myself although it is a Diku derivate too).

[Alayla]

An interesting topic, Molly. First, a small correction: I have never worked on Godwars (which are a merc derivative) or any other Diku. Recently I started helping out on Gladiator Pits, which is going to be Godwars II - a completely different beast from Godwars I, except for theme.

But since I have much more experience with building on LP muds, let me start with those.

What I love most about building in LPC is the freedom and flexibility. LPC is great for perfectionist area crafting. Since you don't rely on any predefined scripts, you can make a room or mob or item as detailed and interactive as you wish. In area building it rarely happens that you'd hit your head against the limits of the mudlib, so with a basic knowledge of programming logic a builder is almost self-sufficient. Another very nice thing is being able to update your objects and put them into game on the fly, without rebooting the system. The only flaw, on the building side at least, is that a lot of your knowledge is mudlib specific, and since most LP muds run modified mudlibs, you can't take that knowledge and get right into building on another mud.

Godwars II are going to be very different. The world is coordinate-based, with no rooms for the largest part. A lot of the content is generated or semi-generated. Descriptions are fully dynamic, which in itself will be a challenge, if the bits and pieces are to form well-flowing sentences in every possible situation. I will certainly share my experience here when I get some, but I haven't really started working with the system yet. But I am looking forward to an everchanging world with a life of its own, and it's a vision I find exciting.

[Alayla]

I just realised it might be worth it going into more detail. I wouldn't know the difference between a mobprog and a DGscript if you killed me, and I imagine some people who build on other codebases have only a vague idea of what LPC building looks like.

Here is an example room I put together, details of the functions etc. may vary depending on mudlib. If it needs explanation, let me know.

And I'm really sorry about feeding Tyche to the Grue. But... he mentioned it first in another thread.

[Molly O'Hara]

Building in CIRCLE
Circle may not be as versatile as LP, but it sure is easier to work with. I actually shuddered a bit at Alayla’s example, since to me it looked a lot more like coding than building. Building in Circle is much more straightforward, and the OLC is very logic and simple to understand even for a beginner - although sometimes a bit circumstantial. Anyone can learn to build in OLC in a very short time. (This doesn’t mean that anyone can become a good builder, but that is another story).

Rooms, mobs, objects, resets, shops and scripts are all stored in separate files, and you use the same set of vnums for all of them. You edit rooms using the command ‘redit <vnum>’ and the corresponding commands for the other kinds are medit, oedit, zedit, sedit and trigedit respectively. Each command brings up a menu that in turn has a number of sub menus, and then you just work through those, one step at the time.

Rooms and exits

Circle, like most Diku codebases, is room based. One thing that I find a bit circumstantial in Circle compared to Mythran is making new rooms, in particular the exits to them. In Mythran, (as I believe in most Dikus), you make a new room simply by making an exit to it from the room you are in. This automatically creates both the new room and a two-way connection to it.

In stock Circle you have to create both the rooms first, only then can you make the connection between them. The exits have to be set in OLC from both sides, or they become one-way exits. Also it’s important to make doors exactly the same from both side, or they won’t work properly (i.e. you shouldn’t set a normal ‘door’ from one side and a pickproof one from the other).

Lately we have implemented Buildwalk in our Mud, which makes room-making a lot easier, since it immediately creates the new room with two-way links in the direction you walk. We have also implemented a copy function for rooms, mobs and objects, which will make an exact copy on a new vnum. Neither of these features exists in stock Circle however. I am a bit split in my opinions about the copy command. It obviously makes building much faster, since you can create one room/mob/object with the flags you want, and then just use that template and change the descriptions. The downside is that it encourages lazy builders to make repeated descs, something that I am generally against.

The same goes for grids. We have implemented the Wilderness code, which automatically sets generic room descs, based on the sector of the room. This is nice for ‘filler zones’, but personally I prefer individual descs. Obviously you always have the option to replace the default descs, which of course also means more work for the builders.

You can add as many extra look descs as you want to the main room description, for any number of keywords. You can also add descs for looking in all directions (even the ones you cannot walk in). We have also implemented ‘LOOK BEHIND/ABOVE/UNDER <OBJECT>’ descs for an infinite number of keywords, plus LISTEN/SMELL descs for rooms. These descs have to be set individually for now, but we might implement a system where a generic listen/smell descs would be pre-set based on the sector, and then you can choose to go in and edit them manually or keep them generic.

Mobs and objects
Making mobs and objects in Circle OLC is easy, and there are a lot of different types, flags and affects built into the menus.

Mobs and objects are set up pretty much the same; an alias list, a ‘short desc’, a ‘long desc’ and a ‘look desc’.
The short desc is what is put in a sentence when you interact with the mob/object, like for example ‘the backpack’ or ‘the elf’. Example ‘The elf picks up the backpack from the ground.’ The long desc is a one-liner about what you see of the mob/object in a room; ‘A backpack has been left here by someone.’ or ‘An elf is wandering through the forest.’ And the look desc is the more elaborate description that you get from typing ‘look backpack’ or ‘look elf’.

Mobs only have one look desc, but you can set as many keywords and extra descs as you like on your objects, plus the SMELL/TASTE/FEEL descs that we’ve implemented in our mud. Or you can choose to leave the look descriptions out altogether, which lazy builders in low quality muds often do.

The rest of the menus deal with all the different object and mob types plus all the stats, flags and affects you can set on them. (The lists of these are practically endless and only limited by the imagination of the builders and what they can persuade the coders into adding to the OLC).

Over the years we’ve added tons of flags and object and mob types to the OLC, many of them designed to fit into the crafting system that we still are working on, others to make the mobs and the built in quests more challenging. One of the best examples of the latter is the !display flag, with which you can make objects like containers and portals not show up in the room at first glance, although they can be looked at and manipulated with the normal commands, (very useful for quests). Our building manual instructs the builders to always make references with keywords in any of the room descs when using this flag, because we don’t want to force some silly ‘guessing games’ on he players.

There are also flags to restrict the use of certain weapons, armor or tools, based on the race or class of the player.
There are flags to make mobs aggressive towards all players, or just against good_aligned or neutral_aligned. Mobs can get almost all the skills, spells and abilities that players have through different flags, in addition to their level and tier. A very useful flag for mobs is QUESTMOB, which automatically sets the flags detect_invis, sense_like and infravision, which all Quest mobs should have to work properly.

Balancing mobs and objects is usually a bit tricky, especially in new Muds. We have solved this problem rather pragmatically with a code addition that automatically sets all the stats of a mob, based on the level and type. This eliminates the risk of unreliable builders making ‘cheat mobs’ that are pushovers to kill, but yield astronomic amounts of money and exp, and consequently it also makes the task of checking new zones easier for the Head Builders. The same thing goes for spells; the code automatically caps any attempts of setting ridiculous amounts of damage. ‘Addaffects’ on objects still need to be checked manually, but we have guidelines for those, to keep the builders’ enthusiasm for overpowered items in check. This might all limit the possibilities a bit, but it is mainly a sound precaution. And if we want to make a mob particularly challenging – or even impossible - to kill, there is always the DG_scripts to use.

Resets
You can ‘load’ an object or a mob into the room to look at them and manipulate them, but to have them stay in the room after a crash or reboot, you have to ‘reset’ them, which you do with the command ‘zedit <room vnum>’.

Resets are a bit bewildering in Circle at first. This has got to do with the max amount allowed in the mud for each mob and object. For each object and mob you reset, you also have to set the max amount, and for objects this needs to be pretty high, because players are in the habit of hoarding some objects, and if they do the objects ‘max out’ and don’t load any more.

This means that you cannot just reset 1 pile of gold coins and one Guardian into a vault, if the max is set at 100 for both. Because each time the zone resets, a new pile and a new mob will be loaded into the room, until the max is reached – or the mud reboots. So to ensure that just one pile appears, you have to first remove it from the room in zedit mode. And if you actually want more than one of a certain object in the room, for instance three wads of notes, you have to use a container to put it in. For mobs you don’t have any other option than to set a low max.

Some reset commands are also dependent on others, and if you don’t do them in the right order, they will screw up.

This means that the finished reset in the vault might look like this:
0 - Remove a pile of gold coins [6845] from room.
1 - Load a pile of gold coins [6845], Max : 100
4 - Remove a safe [6873] from room.
5 - Load a safe [6873], Max : 20
6 - then Put a wad of notes [6844] in a safe [6873], Max : 100
7 - then Put a wad of notes [6844] in a safe [6873], Max : 100
8 - then Put a wad of notes [6844] in a safe [6873], Max : 100
9 - Load a guardian [6845], Max : 1
10 - then Equip with a broadsword [6867], Wielded, Max : 100
11 - <END OF LIST>

You also have to reset doors as open, closed, locked or hidden in zedit, (after making the doors and keys in question in redit and oedit of course).

Shops I think work pretty similar in most codebases, so I won’t go into them here.

The feature that I like best in Circle is of course the DJ_scripts, because they supply the tools for letting your zone come to life. But I’ll leave these, and the comparison to Mob_progs, to another post.

[Sandi]

In response to Molly's suggestion I speak of ROM, there's not too much to say she hasn't covered in her post on Circle. As can be seen below, the various descendants of Diku are much the same, yet different enough that the files are not interchangable. The differences are of more concern to a coder, however, than to a builder using OLC.


Diku:
#7000
mud monster mudmonster~
The horrifying Mudmonster~
A horrifying Mudmonster is slowly evolving from the mud ...
~
It sure looks like something out of a horrormovie. It strongly resembles
a huge figure made up from mud alone, and it sure looks like it had human
flesh for breakfast and is strongly intent on having the same for dinner
- Perhaps you?
~
64 524288 -250 S
12 9 2 4d6+140 2d7+1
100 15000
5 5 0


Circle:
#7000
mudmonster mud monster~
the horrifying Mudmonster~
A horrifying Mudmonster is slowly evolving from the mud...
~
It sure looks like something out of a horror movie. It strongly resembles
a huge figure made up from mud alone, and it sure looks like it had human
flesh for breakfast and is strongly intent on having the same for dinner
- Perhaps you?
~
gqr sk -250 S
12 9 2 4d6+140 2d5+3
100 13000
6 8 0


Merc:
#7000
mud monster mudmonster~
the horrifying Mudmonster~
A horrifying Mudmonster is slowly evolving from the mud ...
~
It sure looks like something out of a horror movie. It strongly resembles
a huge figure made up from mud alone, and it sure looks like it had human
flesh for breakfast and is strongly intent on having the same for dinner.
~
64 32768 -250 S
12 9 -2 12d12+120 2d6+5
100 4000
5 5 0


ROM:
#7000
oldstyle mud monster mudmonster~
the horrifying mudmonster~
A horrifying mudmonster is slowly evolving from the mud ...
~
It sure looks like something out of a horror movie. It strongly resembles
a huge figure made up from mud alone, and it sure looks like it had human
flesh for breakfast and is strongly intent on having the same for dinner.
~
human~
AG P -250 0
12 0 2d10+150 6d9+100 1d10+3 none
0 0 0 8
EFNU 0 0 0
rest rest none 5
0 0 medium 0


Smaug:
#7000
mud monster mudmonster~
the horrifying Mudmonster~
A horrifying Mudmonster is slowly evolving from the mud ...
~
It sure looks like something out of a horror movie. It strongly resembles
a huge figure made up from mud alone, and it sure looks like it had human
flesh for breakfast and is strongly intent on having the same for dinner.
~
65 32768 -250 C
12 9 -2 12d12+120 2d6+5
100 4000
5 5 0
13 13 13 13 13 13 13
0 0 0 0 0
85 3 0 0 1 1 1
0 0 1705 0 0 0 1 0


GodWars:
#7000
mud monster mudmonster~
the horrifying Mudmonster~
A horrifying Mudmonster is slowly evolving from the mud ...
~
It sure looks like something out of a horror movie. It strongly resembles
a huge figure made up from mud alone, and it sure looks like it had human
flesh for breakfast and is strongly intent on having the same for dinner.
~
64 32768 -250 S
12 9 -2 12d12+120 2d6+5
100 4000
5 5 0

[Sandi]

I'll not continue with rooms and objects, as I think the point has been made. As Molly mentioned in her original post, there are often misunderstandings that are simply matters of different terminology, rather than differences in the structure, at least among Diku derivatves.

One thing that can't be seen, however, is that Diku placed everything in several large files, one each for rooms, objects, mobs, shops, and resets. Circle continued this with folders, each folder containing a file for each area. Merc changed things, creating area files that had separate sections for rooms, mobs, etc. Again, the differences are superficial, and transparent in OLC.

[Scandum]

Here's the format of MrMud, which never implemented OLC and ended up focussing on offline building instead. It doesn't ship with the mud monster but does have good old John.

#6000
john lumberjack~
John the Lumberjack~
John the Lumberjack is here, looking for some trees to chop down.~
He is six feet tall and looks quite strong, muscles bulging under his heavy,
chequered shirt. His features are worn with hard work and his expression
is one of a peaceful man leading a simple life.
~
ACT_BODY|ACT_RACE
AFF_CLEAR
350 S
5 BODY_HEAD|BODY_TORSO|BODY_LEG|BODY_ARM BODY_LEG|BODY_ARM 1d6+27 1d8+2
50 RACE_HUMAN
POS_STANDING POS_STANDING SEX_MALE

[Molly O'Hara]

Quote, Sandi:

Circle:
#7000
mudmonster mud monster~
the horrifying Mudmonster~
A horrifying Mudmonster is slowly evolving from the mud...
~
It sure looks like something out of a horror movie. It strongly resembles
a huge figure made up from mud alone, and it sure looks like it had human
flesh for breakfast and is strongly intent on having the same for dinner
- Perhaps you?
~
gqr sk -250 S 12 9 2 4d6+140 2d5+3
100 13000
6 8 0[/size]

Ummm... actually it would come out like below, at least in our Mud. but that's probably beacuse we added a lot of stuff to the OLC over the years.

#7000
mudmonster mud monster~
the horrifying Mudmonster~
A horrifying Mudmonster is slowly evolving from the mud...
~
It sure looks like something out of a horror movie. It strongly resembles
a huge figure made up from mud alone, and it sure looks like it had human
flesh for breakfast and is strongly intent on having the same for dinner
- Perhaps you?
~
16801832 0 0 0 64 0 0 0 0 E
12 9 2 4d6+140 2d5+3
0 911450
8 8 1 1
BareHandAttack: 4
Str: 10
StrAdd: 100
Dex: 20
Int: 8
Wis: 10
Con: 10
Cha: 9
Class: 3
Subskill: -1
E

I remember having huge problems when we switched code from Myrthan to Circle, and I was landed with the task of converting the 40 already existing zones. The basic convertion was done by the coder, but so much screwed up in the process that every room, mob, object and reset in the game had to be edited manually.

The mobs weren't the worst part however, what really screwed up was the objects and resets. I remember every object in the game suddenly humming and glowing... *shudder*

One funny thing about compatible and not compatible files is that about 6 years ago our old coder made an off line Port for me, so I could work on the zones on my home computer without being logged on to the mud. Over the years we added tons of new stuff to the OLC, but the off line port still worked, until the day about a year ago, when our present coder added 'segmented' mobs. (The idea about these is that one mob is put together by a 'Head mob' and a number of 'sub-mobs' or members. Attack one part and all the rest kick in, and you have to kill the head to end the fight. Great for things like hydras, octopuses and wolfpacks).

Anyhow, this addition was what finally crashed my off-line Port.

It comes up at the end of the mob file like this, a number of vnums representing the segments;

E
J 53062
J 53061
J 53060
J 53059

I am no coder, so I have no idea why my Port refuses to start with a segmented mob in the file, while it happily accepts additions like listen/smell/ taste feel descs on rooms and objects and subskills on mobs. But no doubt there is a logical reason for it.

[Sandi]

[Alayla]

Thanks all for the examples. It looks pretty straightforward.

How do you make dynamic descriptions using that system? In LPC you'd just script it the way you script everything else. We also use function strings on MS, which makes things even easier.

[Sandi]

[Molly O'Hara]

Alayla wrote:
How do you make dynamic descriptions using that system? In LPC you'd just script it the way you script everything else. We also use function strings on MS, which makes things even easier.

It's easy enough, you use a DG_script.
Either a greet trigger is set on the bear itself, in which case of course only the first alternative of the messages would trigger.

Or you'd set an entry trigger on the room, with an if-check, to check if the bear is in the room or not. If not, the second string would trigger. This would make the script slightly more complicated:


wait 1 s
if %findmob.21311(21332)%
* (the first vnum is the mob, the second is the room)
%echo% And the worst thing is - that you have awakened the bear!
else
%echo% Fortunately, the bear doesn't seem to be at home right now.
endif

You can do almost unlimited things with scripts, including having the bear attack only under special circumstances. For instance there could be a 50% chance of it being asleep.

But I think I'll leave the details to another thread, where we could perhaps compare DG_scripts with mob_progs and LP scripts.

[Alayla]

[eiz]

[Alayla]