25 Feb, 2010, Runter wrote in the 1st comment:
Votes: 0
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.
  • 25 Feb, 2010, Scandum wrote in the 2nd comment:
    Votes: 0
    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.
    25 Feb, 2010, David Haley wrote in the 3rd comment:
    Votes: 0
    Being somewhat brief here due to time constraints, but …

    Runter said:
    How important in a codebase is a powerful scripting language available to your builders?

    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.

    Runter said:
    Your players?

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

    Runter said:
    What areas of design are most important to be scripted?

    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.

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

    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.
    25 Feb, 2010, David Haley wrote in the 4th comment:
    Votes: 0
    Scandum said:
    LPMud are probably an example where so much is scripted that there is often little to no consistency.

    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.
    25 Feb, 2010, Scandum wrote in the 5th comment:
    Votes: 0
    David Haley said:
    Scandum said:
    LPMud are probably an example where so much is scripted that there is often little to no consistency.

    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.
    25 Feb, 2010, Orrin wrote in the 6th comment:
    Votes: 0
    Quote
    How important in a codebase is a powerful scripting language available to your builders? Your players?

    I've found it more a hindrance than a help to be honest.
    Quote
    What areas of design are most important to be scripted?

    I prefer to script all the game logic.
    Quote
    How important is it to have scripting available stock in a codebase? As opposed to having it available as a separate project/module/patch.

    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.
    25 Feb, 2010, Runter wrote in the 7th comment:
    Votes: 0
    Scandum said:
    David Haley said:
    Scandum said:
    LPMud are probably an example where so much is scripted that there is often little to no consistency.

    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 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.
    25 Feb, 2010, Runter wrote in the 8th comment:
    Votes: 0
    Quote
    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.


    This is an interesting insight. Why exactly do you loathe it?
    25 Feb, 2010, David Haley wrote in the 9th comment:
    Votes: 0
    Runter said:
    This is an interesting insight. Why exactly do you loathe it?


    Probably for similar reasons to what I said:
    I said:
    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.

    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.
    25 Feb, 2010, Orrin wrote in the 10th comment:
    Votes: 0
    Runter said:
    This is an interesting insight. Why exactly do you loathe it?

    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.
    25 Feb, 2010, KaVir wrote in the 11th comment:
    Votes: 0
    Orrin said:
    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 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.
    25 Feb, 2010, David Haley wrote in the 12th comment:
    Votes: 0
    KaVir said:
    Admittedly I don't have any builders

    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.

    KaVir said:
    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 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.
    25 Feb, 2010, JohnnyStarr wrote in the 13th comment:
    Votes: 0
    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.
    25 Feb, 2010, Runter wrote in the 14th comment:
    Votes: 0
    Quote
    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.


    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.
    25 Feb, 2010, David Haley wrote in the 15th comment:
    Votes: 0
    JohnnyStarr said:
    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 issues.

    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.
    25 Feb, 2010, David Haley wrote in the 16th comment:
    Votes: 0
    Runter said:
    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.

    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?
    25 Feb, 2010, Runter wrote in the 17th comment:
    Votes: 0
    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.
    25 Feb, 2010, Runter wrote in the 18th comment:
    Votes: 0
    David Haley said:
    Runter said:
    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.

    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?


    Yes, indeed.
    25 Feb, 2010, David Haley wrote in the 19th comment:
    Votes: 0
    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.
    26 Feb, 2010, Idealiad wrote in the 20th comment:
    Votes: 0
    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.
    0.0/75