So, where do the scripts go? We still haven’t described the game definition files, but just to describe broadly – scripts can be embedded in the following places:
– In the ruleset file: This is probably where most scripts will go, and they will usually have one of three purposes – having things happen automatically in the game (cards moving from place to place, scores changing, and so on), making conditions for certain things to happen (validating if a card can be played, for example), and calculating various values (how much score is given for a certain move, for example).
– In the table file: This will probably be less common, but scripts can be used for messages displayed to the user on the table. Using scripts we can form any message we want, and include conditions for determining when messages will or will not be shown. Remember that the table is only for display, and should not mess with the game rules – scripts in the table must be limited to getting information, not doing anything that affects the game.
– In the card file: This is meant to implement special actions certain cards can do. In more complex games, you might want certain cards to have special abilities, and if they’re unique to one or a few cards you might prefer to put them in the card definition instead of implementing every possible card ability in the ruleset. Then the ruleset can run the scripts defined in the cards whenever the card is played.
Now, for the language itself:
The scripting language is weakly typed – variables do not have a fixed type they must conform to. Variables may be declared in the variables section of the ruleset, but do not have to – if an undeclared variable is used in a script, it will be created on the fly with a default (null) value. Variable names may contain letters, numerals and underscores, and must begin with a letter.
The following operators may be used for assigning values to variables: = += -= *= /=
Functions are called in the usual c-style way – the name of the function followed immediately by parentheses with a comma-separated list of (zero or more) arguments. Currently there is no way to define new functions, but that is planned for the future. A list of available functions will be published shortly.
The engine supports the four standard arithmetic operators: + – * /
Conditions And If Clauses
Conditions usually appear inside <condition> tags for game actions or events. The standard conditional operators are supported: == != > < >= <= && || ! Note that if you’re editing the ruleset XML file directly, the special characters <, >, & must be escaped to avoid confusing the XML reader.
if(“var1 >= var2”, “var1 += 2”, “var2 += 4”)
This clause will check if the variable var1 is bigger than or equal to var2, if so will increment var1 by 2, otherwise increment var2 by 4.
Running code on the fly
A special function called “eval” is available, which takes a string parameter and runs it as a script. This will often be used for running code embedded as card properties – for example, if your cards have a property called “action”, you might run this script after a card was played:
This will take whatever script is written in the “action” property of the card and run it. If the eval function is run with a null or empty argument, it does nothing.
That’s it for now on scripting. Next we’ll take a look at making complete rulesets, so you’ll be able to start making your own games.