Area variables anyone?

Hello again everyone. I am proposing yet another idea. What if we gave each area in SMAUG (or SWR in my case :P) a set of variables that can be set using mob/obj/room progs?

Imagine a player walking into a long, dark hallway (has the dark flag :P), but then they flip a light switch and the lights come on (no more dark flag).

Or perhaps a player is wandering through a dungeon of somesort, and he must deactivate a trap in another room before he can unlock and take the tresure in the chest in a different room.

Or maybe a player finds an elevator, but it doesnt work. It turns out they need to remove a piece of metal thats jamming a wheel in the shaft, then they can use the elevator.

You may notice I think more sci-fi examples (because I run an SWR), but I'm sure there are plenty of ways fantasy muds could employ it too.

Thoughts? Bad or Good idea? Any reason NOT to do this?

Sounds like a great idea to me. I can't think of any reason not to do it, and I can think of lots of reasons to do it.

I'm not sure if I would tie it to just one area, but rather make them mud-wide flags. After all, sometimes you might want an action way over here to affect an action way over there.

Hmm, good point. But how would you suggest doing it? Lots of mud wide variables, a variable array of some sort, or a structure perhaps?

In C++ it would be trivial, which is one of the nice things about C++: you could just use a map of variable name to value.

In C, if you wanted to be efficient about it, you would use a tree or hash table. Since I don't think efficiency is an issue (after all you're not talking about hundreds and hundreds of variables) I would suggest a plain old (doubly) linked list. When you want to look up a variable, you traverse the list.

Otherwise, a binary search tree is pretty straightforward. The trick is in keeping it balanced, if you really care about that. (Again, I'm not sure how much you should care about efficiency.)

Yes, a doubly linked list sounds alright. I suppose I'll go see what I can do now :)

This turned out quite nicely. As I am building area's with it now I'm wondering how I managed without it before. It adds a lot of depth and flexibility to my areas. :)

If anyone wants to get a system like this setup just send me an e-mail or something and I'll help.

Here is a bit of info on how mine works.

ALL mudvars are stored in a text file (mudvar.txt) in the system directory. Thus, all mudvars are then read from the same file.

Several commands allow for easy creation (do_makevar), deletion (do_deletevar), viewing (do_showvar), and manipulation (do_editvar).

Mudprog ifcheck's have been modified to allow checking of this. Any mob/obj/room prog may check the current value of a mudvar. The syntax is like this:

Supposing the mudvar named dog existed, and its value was 1, the program would then echo Woof!

In addition to checking the state of mudvars, I also made it so you can check if a mob/obj/room has a certain flag set. I also made two mpcommands, which allow you to set a mudvar or toggle a room/obj/mob flag.

So, if you wan't something like this and you need help getting started or get stuck somewhere, send me an e-mail or IM me or something.

Just curious, how many of you MU* owners/programmer's have a system like this (or a system that poses the same purpose) in your mud currently?

Sounds like nice work. It's indeed a very useful thing to have/ :)

My MUD has something similar but not quite as sophisticated - variables are numbered, not named (you have to look up what they mean in a help file table.) It was implemented right before I arrived and I haven't really had the need to improve it. Our builders aren't always big on elaborate interaction, so it's not really missed anyhow.

To anyone scoping such a system, you can make it even better.

I've enhanced this fine little piece of code. Now you can set a timer and a default value so it will reset itself every so often. Also, it keeps a function pointer so that when the mudvar's timer runs out a function can be called.

These simple updates actually improve the greatness of this system dramatically, as now they can be used for even more things, such as quests and the like.

Just thought I'd say something about it... :P

Ah, but is there a snippet for it? I've been thinking of putting something similar in, and with a map variable it would be quite easy I think, since the look up is all name based. I was also considering adding a small buffer to it that could be used, for example, to have a small mob prog in it:

mprat 100 113 mpsetroomflag dark

Allowing it to reset the area by the builder instead of having to code a function for it. Unless thats what you meant already :)

Sadly, there is no snippet for it. I've become quite attached to this system, and while I don't mind helpping people set up their own I don't really want to spread mine around.

As for the buffter, that would be quite feasable. However, on my mud I'm really the only builder as well so I have no problems just coding functions for myself. :)

Huh. I guess I never really looked that close at how rprogs worked, and there is quite a bit to it.

To bypass this, I merely have a char pointer to a string which is then parsed using interpret with the mob being the supermob. This works for one-line progs (such as the one you showed Greven), but it wont really work in the long run.

Any way to make it more like room progs without having to copy room progs and hack it to pieces? I should take a closer look at it when its not 1:30 AM...