BlobbieScript was designed and written to replace the archaic Easyact system which had far outlived its usefulness. Easyacts were originally designed by Dimwit (Aaron Buhr) and are the basis of mobprogs in Merc 2.2. BlobbieScript is fully backward compatible with previously written easyact code (and thus quite possibly with mobprogs). Despite the compatibility, the features and power of the BlobbieScript engine are nowhere near as limited as that offered by these older engines. BlobbieScript was designed and coded from the ground up and is a bytecode language rather than a run-time interpreter. A quick benchmark has shown that the engine can process 60,000+ lines of BlobbieScript per second. Optimizations are known and are scheduled for sometime in the near future that could bump this up to about 80,000 lines per second. To see a couple of examples of BlobbieScript, please see the examples section.

Flaws in the Easyact Engine

The Easyact engine was a great engine in its hay day and served to be the basis for many other MUD scripting engines; however, it is well past its usefulness having reached somewhere around 10 years of age. Someone really should have put it out of its misery a long time ago. The following outlines the deficiencies encountered in the Easyact engine:

• Not real-time, variables are expanded macros
• Scripts are parsed on every run
• No looping constructs
• Nothing ensuring data is valid for duration of execution
• Poor support for expressions
• No concept of instance variables
• Code is a mess and poorly scalable
• No simple way to access internal data fields

Almost all of the features in the new BlobbieScript engine arose to solve inadequacies of the easyact engine. The following is a list of features that were (or will be) implemented to meet and exceed the shortcomings of the Easyact engine:

• Backward compatible with existing Easyact code
• Real-time data access
• Looping constructs
• Block protection for time sensitive routines (mutexes)
• Fully exploitable precedence based operations
• On the fly declaration and access of instance variables
• Static variables
• Associative array data containers
• Contextual resolutions for accessing internal data fields
• Variables use copy-on-write method of copying
• Easily extensible
• Return values from scripts for scriptlet embedding
• Line continuation breaks
• Error messages which pinpoint problems
• context manipulation (thread management)
• User function declaration (after initial engine)

Previously the Easyact engine supported some simple block control mechanisms. Some of the mechanisms worked well, others not so well. The 'if' statement is a good example for one that generally works well. One of the greatest drawbacks of the 'if' statement though, is its lack of support for joining conditional expressions. This is solved in the new engine. The following control blocks are supported by BlobbieScript:

One of the biggest problems in creating the BlobbieScript engine was to try and add in real language support while adding the flexibility of evaluating expressions as can be done in almost any other programming language. To maximize ease and backward compatibility there exist two modes of expression evaluation: pure and impure.

Pure expressions are any expressions that are part of a block control expression or part of a function's parameter part. These are called pure because they do not require special treatment to be evaluated in their context. To illustrate, the following is now possible:

The difference between pure and impure expressions is also illustrated above. Notice to get the power of expression evaluation within a non- block control statement the expression needs to be evaluated with the special %() function. This is because for backward compatibility reasons the new engine guesses that anything in a block control statement is any of variable, function, or string. Given this interpretation all tokens extracted are considered to be implicitly joined by an invisible concatenation operator. Since this may become confusing if a variable is used that blends into an actual word the following can be used to ensure the end of the variable:

The advantage of such expression evaluation is that it gets rid of the old system of $.calc( 1, +, 3 ) since this can be expressed as %( 1 + 3 ). Moreover the engine fully supports integers, floats, strings, and associative arrays (AKA: dictionary, string indexed array, hash).

In addition to block control expressions and normal expressions there are comments, continuations, and block tags. Comments begin when a pair of forward slashes "//" are encountered and end at the end of the line.

The \ at the beginning of a line denotes that the expression continues from the previous line. This was added so conditionals can be nicely formatted for easy reading.

Block control tags are more for aesthetic purposes. I come from programming background which uses braces to denote code blocks. Normally BlobbieScript doesn't support these blocks due to backwards compatibility; however, for the sake of good looking code (IMHO) any line containing only a sequence of "{" or "}" characters will be ignored.

Finally a semi-colon is permitted on most pure expressions where one would make sense. The behaviour of the engine is to strip it if it is the last character on the line. Note that commands normally passed on to the game's command interpreter will retain any trailing semi-colons.

The for construct enables easy iteration over an expression. Unlike the while construct, the for loop provides a means to initialize, test, and update the evaluation.

    Example:


    for( @i = 0; @i < 10; @i++ )
    {   
        %echoTo( @i, @self )
    } 
    endfor;

The above for loop will output the numbers 0 to 9 inclusive to @self. Studying the expression we notice the following pattern:

    Example:


    for( [INITIALIZE]; [TEST]; [UPDATE] )
    {   
        %echoTo( @i, @self )
    } 
    endfor;

So when the for loop is encountered the INITIALIZE portion is processed, then the TEST part is processed to determine if the contents of the for block should be processed. If the contents are processed, then upon reaching the endfor construct the engine will process the UPDATE expression and then the TEST part. Subsequent runs through the loop will repeat this UPDATE/TEST parts until the TEST fails and the loop ends.

The foreach construct enables easy iteration over an array's values. This simplifies the task of updating a series of items, mobiles, rooms, or anything else in an array.

    Example:


    foreach( %roomGetMobiles() as @mob )
    {   
        //
        // Give a little regen bonus.
        //
        @mob->hitpoints += 2d3
    } 
    endwhile;

    Example (with index):


    @mobiles = %roomGetMobiles()
    foreach( @mobiles as @index => @mob )
    {   
        //
        // Move to Elkin fountain.
        //
        %move( @mobiles->@index, 115611 );
    } 
    endwhile;

Operators are at the epicentre of any kind of logical and mathematical processing. To facilitate the power that BlobbieScript will exhibit, many of the most common programming operators have been implemented. Some of the operators can be expressed in more than one way since not all programming languages use the same style. Remember operators will only be functional if found within a pure context, otherwise they are treated as part of the plain text input to the MUD's command interpreter.

As with all expression evaluation mechanism there must exist a set of rules of precedence to ensure that what the user expects to happen, actually happens. BlobbieScript uses the following order of precedence, from highest to lowest, for its evaluations -- operators on the same line are of equal precedence:

Traditionally Easyacts only supported pre-set variables of a single character nature. While the most triggers still support these basic preset variables, newer triggers now use more readable named variables. For instance $i traditionally was a variable whose contents were a text pointer to entity for which the script was defined. While this can still be used, the more object oriented nomenclature of @this, or @self is preferred. These can also be written using $ but to break from the past it is suggested that all variables use @ instead of $ (similarly for function $. has been deprecated in favour of %). Additionally, script authors can now declare variables of their own naming on the fly.

There are currently five types of variables used in the Worlds of Carnage. The first two are types used by BlobbieScript. This style should always be denoted with the '@' marker such as @foo. These types of variables are only known to the script in which they appear, meaning two different scripts, even two different instances of the same script, will see a different value for @foo. As I have said there are two types, script variables can be declared as static, if so their values are remembered from one script instance to the next (and subsequently can be shared by multiple instances of the same script). The programmer needs to take care when declaring static variables since ANY variable in the static expression will become static and can thus block normal script variables.

Another type of variable is the entity variable. Entity variables can be applied to a rooms, mobiles, or objects. Entity variables can be set using %setEntityVar(), retrieved using %getEntityVar(), and unset using %deleteEntityVar(). These variables are a great way to share information across multiple scripts, especially quest, or game information. For convenience three other functions exist: %setVar(), %getvar(), and %deleteVar(). These are a shorthand for accessing the entity variables of the script owner. For instance:

The fourth type of variable is persistent. These variables are saved and can be restored even after a crash. Such variables can be used to ensure an object is unique or to save ownership of some residential portion of the world. There is a multitude of uses for such data. When saving a persistent variable, the variable is shared amongst all entity instances with the same vnum. These variables are manipulated with the following functions:

The fifth and final variable type persists in the player's save file. These are known as player vars and can be set for players, objects, and rooms. The following functions are used to manipulate their values:

Player vars set on a room are exactly the same as saved vars since rooms can't be saved to player files, but only one instance of a room with a given vnum can ever exist. The following table summarizes the variable types:

Scripts are fired when events occur. These events can be triggered by a player, a signal, or for a multitude of other reasons. There exists a set of default variables (many cryptic due to backwards compatibility) that are instanciated to facilitate knowledge of what elements played a key part in the firing of the script. These variables are listed below:

Many events in the game can be be caught by various event handlers. These event handlers are known as triggers since they trigger some kind of functionality when the event occurs. There are three entity types that can trigger an event. These entities are rooms, mobiles, and objects. Some event types can be triggered by multiple entity types, such as the random event. Most triggers will run an associated script; however, the text ones will merely present some text to player that cause the trigger to fire. Additionally there are a few types that don't do either and are for hacking in special functionality such as the set_skill trigger. Following are the lists of events that apply for each entity type:

The easyact system provided a fairly rich set of functions for accessing the data structures that define the state of the mud at any given point of time. For the most part these functions have been carried forward with the same functionality. Where errors have been detected in the conversion process the errors have been corrected. One concept that was deprecated was the "*ERR*" or any similar type of return value when data is erroneous. Rather than this a null data structure is returned which can be tested with the %isNull( ) function. This is a more consistent and flexible approach to error handling. Generally speaking functions names are case-insensitive; however, for historical reason the %v( ) and %V( ) functions are case-sensitive. Functions are shown with any aliases they may have. I'm high on long names for clarity of code, so you'll notice some function names are just longer versions of the traditional short versions.

This operator is powerful enough to warrant an entire section describing its use. Unlike other operators the resolution operator "->" is highly contextual and the actual functionality is completely dependent on the leftmost value of the resolution. Since this operator may be strung together in sequence to resolve a multi-level path for a container, it may not always behave as expected when the leftmost operand does not support multi-level resolution. This is true of strings. Currently