Top Mud Sites Forum - View Single Post

Blobule · 04-11-2003, 06:18 PM

Late last year I announced my decision to create a new MUD scripting language here. At that time I asked for suggestions (short of object oriented). Since then I have completed (some sugary items are still missing) the new language which I call BlobbieScript. At any rate the thought of embedding a language like PHP crossed my mind before I set out on that endeavour. At the time I had a couple of major problems top consider: security due to the wide array of functions, and backward compatibility. To switch languages would mean losing all of the pre-existing scripts on my MUD. Another thought presented itself too, PHP is a real programming language and to that end not very intuitive to the untrained builder. At WoC we used easyacts, I believe these are the predecessor of MobProgs, and as anyone might tell you, MobProgs are interpretted and (if anything similar to easyacts) macro based. Thus there was no support for real time variable access since variables were calculated then expanded through the script. This was unacceptable. Also there was no support for looping contructs, which brings me back to PHP, controlling infinite loops in PHP would require a thread so as to not affect the MUD itself. This opens up a whole jar of worms since the structure of DIKU was not designed for such things. At any rate my final decision was to make a 100% backward compatible scripting language, BlobbieScript. Having created the engine myself I was able to easily control the execution contexts (for looping) and able to retain 100% backward compatibility with easyacts. Now having had it active on our MUD for 3 months, I don't look back. The engine is tight and builders can create simple scripts that are like issuing the commands at their client whilst advanced builders can create almost anything their imagination can dream up (special procedures are defunct). Incidentally I also add a protected block contruct for emulating mutex/semaphore locking. Really the block just guarantees the block of code runs to completion before returning control back to the MUD server (there are checks in place for scripts taking to long to return control). Another advantage of writing my own engine was how easy it was to add support for stopping the code, stepping through it, and viewing the running scripts variables. The next step on our MUD is to convert all the socials, dreams, spells, and skills to use the new scripting engine. Currently builders can create custom commands or override existing game commands via script. Also on the agenda is to create a new type of zone command script that will deprecate the current zone command system and use scripting instead. Anyways hope this gives you another perspective.

Cheers,
Blobbie.

04-11-2003, 06:18 PM	#10
Blobule New Member Join Date: Jul 2002 Location: Canada Posts: 17	Late last year I announced my decision to create a new MUD scripting language here. At that time I asked for suggestions (short of object oriented). Since then I have completed (some sugary items are still missing) the new language which I call BlobbieScript. At any rate the thought of embedding a language like PHP crossed my mind before I set out on that endeavour. At the time I had a couple of major problems top consider: security due to the wide array of functions, and backward compatibility. To switch languages would mean losing all of the pre-existing scripts on my MUD. Another thought presented itself too, PHP is a real programming language and to that end not very intuitive to the untrained builder. At WoC we used easyacts, I believe these are the predecessor of MobProgs, and as anyone might tell you, MobProgs are interpretted and (if anything similar to easyacts) macro based. Thus there was no support for real time variable access since variables were calculated then expanded through the script. This was unacceptable. Also there was no support for looping contructs, which brings me back to PHP, controlling infinite loops in PHP would require a thread so as to not affect the MUD itself. This opens up a whole jar of worms since the structure of DIKU was not designed for such things. At any rate my final decision was to make a 100% backward compatible scripting language, BlobbieScript. Having created the engine myself I was able to easily control the execution contexts (for looping) and able to retain 100% backward compatibility with easyacts. Now having had it active on our MUD for 3 months, I don't look back. The engine is tight and builders can create simple scripts that are like issuing the commands at their client whilst advanced builders can create almost anything their imagination can dream up (special procedures are defunct). Incidentally I also add a protected block contruct for emulating mutex/semaphore locking. Really the block just guarantees the block of code runs to completion before returning control back to the MUD server (there are checks in place for scripts taking to long to return control). Another advantage of writing my own engine was how easy it was to add support for stopping the code, stepping through it, and viewing the running scripts variables. The next step on our MUD is to convert all the socials, dreams, spells, and skills to use the new scripting engine. Currently builders can create custom commands or override existing game commands via script. Also on the agenda is to create a new type of zone command script that will deprecate the current zone command system and use scripting instead. Anyways hope this gives you another perspective. Cheers, Blobbie.