As a builder, generally speaking, I would refuse to build anywhere that didn't have in-game scripting in one form or another.

Are you saying that you are closed-minded to the possibilities of a MUD that does not offer scripting to builders?

Why is this that difficult?

For all intensive purposes, yes. But as the saying goes, there are exceptions to the rule.

To me, in the context of this topic, it is simply the ability for builders to create game content through writing code. Something that I have no plans to allow in my code-base. But let's poison this apple some more, game content can be considered to be a scripted experience in the being there and doing something that someone else has authored sense. You are acting out their script. Whether this authoring was done in a fancy data-driven UI or cobbled together through coding, is equally feasible. Though of course, offering the latter option is easier and it might be argued the lazy approach.

That is the main advantage of using a mob prog like scripting language, they're very easy to understand, and mobs use player like commands to interact with the world. Needless to say that classic mob progs have issues, but that's outside of the scope of this discussion.

I always cringe when I see DG scripts that loop through lists doing low level object handling. Centralization is key if you want to keep a mud manageable.

It's for all intents and purposes.


This leaves me with the understanding that you would not refuse to build on a MUD that does not offer scripting, but which still allows you to build in a satisfactory way. That would be an acceptable exception, right? If this is the case, then I consider your assertion that you would refuse to build on a MUD that does not offer scripting to have been a kneejerk reaction. I'm not trying to pick at straws here, but between your last post and the one I am responding to, you have basically asserted nothing substantial (I would refuse! But maybe I wouldn't!).

I'm sure Dean doesn't need my flight to his defense, but perhaps he was simply making a strong statement to show his support for being able to write actual code as a builder.

Yes, Runter hit the nail on the head.

Serves me right for posting before I've had a coffee to get my day started. :sad:

If you want to write "actual code", be a coder. If you want to build, you shouldn't need to write "actual code".


Edit: My 300th post is the 30th post in this thread! Wheeeee…..

A drawback of such a clear-cut separation of roles is that the builders are forced to rely on the coders whenever their content requires special functionality. Such code also tends to be of limited use due to its specialised nature, so the coder may not even consider it worth the time investment.

Coding isn't a boolean skill - there are many degrees of competence. It's not unusual for builders to have sufficient programming ability to write simple scripts for improving their areas and mobs. That doesn't necessarily mean they have the skill (or desire) to take on a full "coder" role, but they could certainly help reduce the coders' workload.

lpc

I think ideally you want a DSL (domain specific language). Both mobprogs and mushcode partly accomplish that by incorporating commands that someone who has played Diku or Mush for a while becomes familiar with. For example, a builder who animates a mobile includes the same or very similar commands in the mobprogs that they would use as a player. There are several domains here though, creating/decribing/manipulating/animating. Decide what a builder does in your game and create an interface that uses metaphors that make what they are doing in the language easy.

Honestly, I don't think that scripting languages like Ruby and Python are appropriate for direct manipulation by builders (although they're better than nothing if anything because the coder can go in to write the scripts for them without messing with the presumably more complex core). If they're going to be writing full code in those languages, they might as well be working on the core. Lua makes it easy to construct true sandboxes, but even then you're arguably presenting an inappropriate interface.

I'll respectfully have to disagree on some things. We've heard a lot about the downsides, but I think there are some rather large upsides to using a language like Ruby or Python. In particular, if I were building it's the tool I would want. I think a lot of builders aspire to perhaps learning how to write in a real language. Perhaps this is a good way. There's a lot of resources out there for them in the first place—And if they are elevated to working on the core one day then they have considerable knowledge towards the end. I don't see why, in particular, these scripts have to be complex. They could possibly be complex. But considering the things that a lot of the scripting languages out there atm accomplish they could be very short and very readable. I think some domain specific languages used in MUDs are very complex. Odds are everyone new would have to learn these. It's entirely possible that new builders may have experience with a language like Ruby or Python or Lua.

actor.print "You press the button and the elevator moves to the third floor."
otransport actor,  third_floor
third_floor.print "#{actor.name} has arrived."

I don't find that inappropriate compared to what other scripting languages used in the community might look like to do the same thing.

I'm just saying that in my experience, things that might seem simple to you or me are not so simple when it comes to builders, and while obviously they can eventually figure it out, there is a (sometimes significant) learning curve. The tool that you or I would want is going to be rather different than the tool a non-programmer would be using.

And indeed, simple examples are hopefully simple, and your example is fairly simple. My concern, and more importantly, my experience is that as complexity increases, a "full" language will become more complex at a faster rate. It takes work to keep that rate of difficulty increase manageable.

I think you missed the actual part in "actual code". I said nothing regarding having a system in place that allows builders to create most/all of what they want without bugging coders to add new functionality. And for the record, I don't consider "simple scripts" to be "actual code". Additionally, something along the lines of what David previously described (having a library of available parametrized scripts that can be attached to NPCs/objects/etc, and even layered on them) would suffice to allow for builders to create the things they want without having to write "actual code". I tend to favor solutions similar to this one.

No, I've been following the term since David Haley introduced it to the discussion in post #16 as "actual code that can do things beyond those hard-coded things you've put in".

In other words, its the only solution for the builder "whenever their content requires special functionality" beyond what has been hard-coded.


So where is this new functionality going to come from, when the builders want something beyond what has already been hard-coded and aren't allowed to write "actual code" themselves?

Well, unless your builders are working on the core to begin with, there will always be things that simply can't be done without enhancements to the core. You can get a lot done if you provide functionality chunks that can be manipulated, without actually writing code: for example, take this action and apply it to all people; apply it to all people meeting some criterion, etc.

But sure, yes, eventually functionality will need to be added to the core somewhere, or into the game logic section but beyond the reach of the builders. (You probably don't want average builders running amok with core game logic, after all.)

But there are also many things that can be done without modifying the main game, and hardcoded functionality isn't going to cover the same range of possibilities.

I'm definitely not against the idea of such functionality, but my point is that if that's the only tool available to the builder then they will hit the creative wall faster than they would if they also had access to (and knew how to use) a decent scripting language.