Having read the current News on this site and Sorisor's list of


alternative ways of coding 'specials', I've got a couple of


comments re what's been said about our approach at TerraFirmA.


Your comments overlook what we see as the major advantage of


TerraScript, the scripting language used for TerraFirmA's quest


puzzles, which is that it can be used by people who aren't C


coders. People who have never written a line of code in C in their


lives (like me), and who may have no access to the main code of the


game, can write the script for a quest, as well as the zone file


and other quest information (the basic quest description and a set


of hints which players can buy from our Bard mobile); in other


words, they can supply a quest which is already complete and can


pretty much just be dropped into the game without lots of work


being required from the C coders, who are then free to concentrate


on general game systems, implementing new features etc.


TerraScript is a major step forward in that it means that new quests


can be brought in much more quickly (after normal quality control


and editorial checks, of course), and more people can work on


quests and have a much higher level of involvement in bringing the quests they have designed to reality.




Re the disadvantages you say there are: first, TerraScript is


not limited in any way in what can be done with it so long as the


supporting libraries that it needs are there, and as we are


converting more existing quests to TS as well as creating new ones


that way those libraries are being built up. Second, here is no


extra lag experienced by anyone doing a scripted quest versus a


C coded one.




Those comments aside, it was interesting to find a little out about


the different approaches.




Firefly (Kate Moore)


TerraFirmA

The comments I had sent to Crimefighter were a very general outline of the different strategies used in various MUDs. Since I


never saw any of Terrafirma's, Northern Lights' or pDirt's code,


I could only go by the info that people were willing to share.




You're right, a simple script language can make things much easier for people who are unfamiliar with coding in general. Nevertheless the code will most likely not be bug-free and a coder will have to


verify everything is ok before it can be installed.


From my own(!) experience I can say that I'm usually faster writing own code than trying to understand other people's code and tracking down the potential problems. Having builders write code themselves may lift some work off the coders, but not overly much.




People needn't necessarily have code access to write specials on other MUDs either. Designs like NL and pDirt allow to put the code directly in the zonefile, all that is required is a good documentation about the interface to the MUD (just like the script language has to be documented).




As you say yourself, Terrascript can do whatever the library provides and if that is not enough, the library can be expanded. That in the end means that for exotic code, the coders have to expand the library and then have to deal with quest code again.




Most well-written AberMuds use up less than 1% CPU usage even on slow machines. So the loss of speed that an interpreter causes is unlikely to cause lag for players, because lag occurs mostly due to net congestion rather than high CPU load. It's still slower than compiled code. It would be interesting to have a comparison about the efficiency of code among the various MUDs, rather than a chart about each MUD's size, but I guess it is impossible to do because they all run on different machines.




Nevertheless it's a fine piece of work and a great progress in the way AberMUDs are coded. Hopefully some other MUDs will also invent


interesting concepts rather than using the old-fashioned methods.


In that case I'd probably write a more complex overview about the different approaches in a future newsletter.




** Sorisor **

It's certainly true that the first TerraScripts people write


may have bugs in, and scripters use a system by which scripts


are uploaded via an in-game editor session similar to the mailer


to put them on the server and test compilation from within the


test mud, and iron out these bugs themselves if at all possible.


A new script has to compile with no errors before it qualifies


to be made active (also done from within the game) and actually


tried out. But I wouldn't want to suggest that there isn't a


learning process that takes some time and effort (and also help


from other people) - new scripts being written at the moment


rarely need intervention from a coder though; more often they


will have improvements suggested by more experienced scripters.




As you say, not all alternative systems require code access,


either - I'm certainly not suggesting TS is the only way round


that - in general I just wanted to mention what we see as a major


advantage, without suggesting that it is the only system that has


that advantage or better than every other system under the sun.




I'd be interested in reading any more complex overview that


you write in the future, with an open mind in the sense that I


wouldn't be biased towards my own mud's method, but all the


same with a particular interest in all methods that result in


systems that are easy to use and accessible to the widest possible


range of people, not just because that saves work for coders but


also because it increases the involvement and sense of achievement


of those other people in bringing their quests to life.




Firefly