So I want to know some of your thoughts on the subject of scripting for world design. Of course, any thoughts are welcome, but there's specific areas I'm interested in.

How important in a codebase is a powerful scripting language available to your builders? Your players?

What areas of design are most important to be scripted?

How important is it to have scripting available stock in a codebase? As opposed to having it available as a separate project/module/patch.

Area based scripting has steadily gained popularity. Mortal Realms was one of the first muds featuring WoW like quests (in early 1994), and area based quests subsequently became ingrained with the mud's building culture. As opposed to whatever builders are psyched about on other muds, the difficulty and complexity of their quests was always at the forefront, as opposed to the immersiveness of the descriptions.

Obviously the MUD's world is the most important, not only mobiles, but also objects, rooms, and to a degree areas as a whole. The ability to store states (requiring some form of variables) is of the utmost importance, something not covered by the early mobprog implementation. It is however also important to have game mechanisms in place that aid this process. Mushes for example have incredibly flexible door handling, but it's so flexible that it's impossible to incorporate any game mechanisms, like lock picking, using a crowbar to force open locks vulnerable to brute force, etc. LPMud are probably an example where so much is scripted that there is often little to no consistency. So it's important to script the world, but to add physics where possible. A good example is falling to your death, it can be scripted, but it's much preferable to have a hard coded mechanism. In this regard scripting can be seen as a bad thing if it makes programmers lazy.

A good scripting engine is invaluable to a stock codebase.

Being somewhat brief here due to time constraints, but …


Very much so. (Sometimes the line between coder and builder is fuzzy, in which case it becomes even more important.)
Note that they don't necessarily need access to the entire scripting language; certain common constructs can be encapsulated.

For example, if you have an transport room (you enter it, press a button, and exit somewhere else; e.g., an elevator) you don't need to make them reimplement the script. You can attach the "transporter" script and have them fill in some parameters, and the rest happens behind the scenes.


Mm, meh. I haven't investigated this too much so don't have a strong opinion one way or the other.


Well, for builders, it's mainly rich interaction of the area, with mobs reacting in interesting ways to their environment, quests being progressed based on non-trivial conditions, and so forth.

I think that writing a lot of the game logic with scripts is very nice. (The transport room above is an example although you might consider it building.) Being able to rapidly develop skills (and so forth) is pretty convenient.


That depends on how separate the "separate" project is. If integrating it is basically plug and play, then it doesn't make much of a difference.

Do you have examples of this?

I think there's a pretty big difference between something being written in a scripting language, and something being modifiable by builders.

The scripting language is so powerful that builders have a tendency to hack away and add all kinds of nifty things, but with little consistency. So for example in one area you need feathered boots to prevent you from falling to your death, and in the other area you need a feathered helmet, and in yet another area you need to quaff the fluffy potion.

So in that regard an argument could be made for a simple scripting language combined with more game physics. Downside of that is the need for documentation and keeping the interface clean.

I've found it more a hindrance than a help to be honest.

I prefer to script all the game logic.

A separate module would probably be most flexible to developers.

Nakedmud comes with extensive scripting support using Python and I've steadily come to loathe it. It's at the point now where the for the next project I am probably going to ditch any kind of custom scripting in favour of builders simply selecting from a set of predefined scripts/behaviours and plugging in a few values.

These days you might as well develop the whole mud in a scripting language, so to my mind it's easier to do that using familiar tools rather than with some kind of in game scripting system.

I do know what you mean, but I think that may be implementation specific. I mean, I know of similar cases with people using mprogs in no way of as broad way.

This is an interesting insight. Why exactly do you loathe it?

Probably for similar reasons to what I said:

The more you make people write complex scripts, the more potential for screw-up there is. I agree with Scandum's points re: consistency, I just am not sure it's really a problem specific to LPMuds.

I find that I spend far too much time debugging scripts and trying to figure out which script attached to which object does what. I just find it easier to build the functionality into the main game code where I can structure it how I want, use my preferred IDE, version control etc. I think once you have your codebase/game logic in a scripting language anyway, the need for a separate scripting system becomes less clear.

I find myself in the opposite position - I've built all of the functionality into the main game code, and find myself increasingly wanting to add scripting support for special situations. Admittedly I don't have any builders, so it's not as if the lack of scripting is limiting the creation of content, but from an organisational perspective I think it would be much nicer to be able to create and modify mob functionality independently of the main engine.

I think this changes a lot, really. Non-programmers, given programmers' tools, are more likely to make mistakes that you need to debug, that in some cases might be subtle.


I think that separation of the main engine and game logic "scripts" (be they in a literal scripting language, mudprog, or heck a C++ DLL) is a kind of separate question.

Actually, that's a good point to bring up: what exactly is meant by "scripting" here?

For instance, I still consider it scripting when you make available little modules (like the transport room I was talking about) and builders fill in parameters, rather than write programming language statements themselves. This is scripting because I (as the developer) write scripts (incidentally in a scripting language) that are made available to the builders in a fairly constrained interface.

So it might be useful to define what exactly we're talking about. Several people have mentioned that as you write your whole MUD in a so-called scripting language to begin with, it becomes less clear what is "scripting" and what isn't.

What about an OLC that redefines the user input, as sort of a sugar coated baby language?
For example, you could put more work into the olc interface, so that it enforces the builder to only use
valid syntax, which is converted to a "real" scripting language, then stored on disk somewhere.

This would add more work to the implementor, but keep things streamlined for each builder, thus cutting down
on loops and other potential hazards. If written correctly, you could add acceptable syntax to the intermediate
language as building requires. An example might be adding a conditional statement, instead of allowing full freedom
to write:

if ch.name == "Johnny" then
   send "Hi Johnny!"
end

Input might look like:

> new IF
- ADD EXPRESSION
> ch.name
- if ch.name
- ADD OPERATOR
> ==

Or something to that effect.

Well, in my case it would indeed have the whole mud written in a so-called scripting language. But what I'm specifically talking about is scripting inside of the actual game as a way to empower builders (and possibly players) with an interface to write code to interact with elements in the game itself. Not limited to the depth that systems like mprogs and dgscripts have, but in the same line of thinking.

I think that at that point, you might as well be providing standardized 'chunks' of functionality that the "core engine" knows how to handle, rather than trying to code-generate the relevant script. It's probably easier to deal with as a user, and almost certainly easier to implement.

So you are referring specifically to a "real" (for various definitions of "real") programming language, that builders can write in, that is aware of control flow, variables, and other programming language features? In other words, you don't want constructs that builders can manipulate, but really the ability to write actual code that can do things beyond those hard-coded things you've put in.
Is that correct or did I misunderstand?

One of my current experiments is logically separating definitions from places to execute code. For example, if I decided to write a function to transport an object to a container (in this case a room) I could name it otransport. In this example perhaps code attached through OLC to a message sent would be..

do self.invoker.in_room.each_obj |obj|
  global_script.otransport(obj, some_room_lookup(for_value))
end

The idea is I could have a global space that's more focused and optimized (and perhaps more strict in security to access) and abstract places to attach scripts through OLC in a great variety of places.

Yes, indeed.

In that case, having a scripting language is better than no scripting language. Having very common operations encapsulated in easy chunks (be those mob flags or other things) is better than a free-form scripting language, because you can be reassured that builders aren't doing anything crazy (or buggy).

It might make sense to have this full scripting but set permissions so that only developers can use it. Developers then create "behaviors" (or whatever you want to call them) that builders associate with their mobs. (Personally, I don't care if this happens while the MUD is live, or requires a restart; requiring a restart is easier in many ways.)

Basically it's very important for there to be an easy, flexible way to create dynamic behavior. Most dynamic behavior follows the same pattern, so it should be easy to apply those behaviors. Since you're in a scripting language to begin with, it should be relatively easy for you to write code quickly. You can make life easier by having some kind of domain-specific language that you use for writing programs.

I guess the short version is that being able to add dynamic behavior easily is important. The fact that it has traditionally been done with builder-written scripts was that it's too annoying in C to write up all these behaviors quickly, short of essentially reimplementing a dynamic system as we're talking about.

The problem with predefined behaviours is you're right back to where you started – requiring coders to code 'specials' for builders like they did before scripting languages and progs were available to muds at all. I think the trick would be to define the granularity of the behaviours such that new behaviours (not explictly defined by the coders) were readily composable by the designers.

In any case I agree with Orrin's general sentiment that scripting for builders isn't the best idea.