STYCHES documentation

What is Styches

Styches is a script processing engine which takes an author defined script and interprets it in real-time to produce output on a variety of mobile devices. It was developed primarily to aid authors of Interactive Fiction (IF) in producing works that can be played on those mobile devices. It also works on desktop browsers. For mobile devices, the engine is wrapped into an app that the player can install on their device.

Styches works almost entirely with hypertext links which are defined by the author. The player then selects those links to make choices within the game. Within the Styches environment, a passage of text and/or a set of instructions are divided into ‘paragraphs’. Paragraphs can by strung together to form a passage of text and can also contain both links to other paragraphs and instructions (or ‘commands’) which can manipulate objects and variables in order to present a story that reflects the player choices.

How does it work

Styches takes a plain text file and converts it into a downloadable script that the engine can then process. The processed files are held on the wordsnotpictures.com website and can be browsed and download via the mobile app. One of the key requirements for the system was that games can be playable offline, so all of the game script and transient data are resident on the device itself. Due to this requirement, since there is limited storage space on a mobile device, there is a limit to the number of games that can be loaded at once.

What is NOT in the documentation

This documentation does not describe how to write IF. There are many excellent resources on the Internet describing the many forms of IF. Writing IF is a hybrid discipline that requires command of both writing skills and programming skills. The documentation contained here will assist you with the programming side, but even then, it assumes you have a basic grasp of procedural programming. Again a quick Internet search will uncover any number of ‘programming primers’. Additionally, this documentation only describes the tools that are available within the Styches engine; how you use those and how you present text and choices is entirely up to you as an author.

Autosaving

The system saves the state of play after each player choice such that after the app is closed down, the player can resume play at exactly the point they previously reached. When the game is deleted from the device or if the game script is updated, this auto-saved state is lost and the player must start from the beginning.

Save & Restore

In addition, the player may choose to manually save the game at a given point such that they can revert back to that point at a later date. Again, if the game is deleted or updated, this saved state is lost.

Registering at wordsnotpictures.com

It is not necessary to register on the wordsnotpictures website in order to download and play publically available games. However, if you are an author and would like to write your own games, you will need to register. Once registered, you can create your own private game script and play it on a mobile device. The mobile device must log in with the same username/password combination. You can also play your game within a browser and share a link with others such that they can play it online. The link is given on the ‘upload and test’ page on the wordsnotpictures website. Once you are happy with your script, you can contact us to have your game made public. Once this happens, it will appear in the list of available games and can be downloaded by anyone. We will sense check your work and whilst we have no editorial control, we will not publish (and may at our own option delete and suspend your account) any works which are offensive, obscene, defamatory, racist, harmful, unlawful or illegal.

Creating a script

A script is a simple text document that is formatted in such a way that the script engine can interpret it. The format of the script is quite rigid and doesn’t cope well with errors; you have been warned! It is the area that we are going to try and improve on next.
To create a script simply generate a document using your favourite text editor (notepad, notepad++ and so on) and then save it locally. The format of the script file is given below in the section on Script Documentation

Creating a 'game' and uploading a script

On the wordsnotpictures website there is an ‘Upload and Test’ page. In here you can define your games name, a short description, a longer description to be displayed in the game catalogue and an icon. Along with these, you can choose your script file and upload it. As soon as this completes, you can test it out within a ‘pseduo’ mobile device right within the browser window. You can only have one game in the wordsnotpictures database at a time. If you are working on several projects, simply keep all of the scripts separate and upload them when you want to test the game. Each time you upload, the existing script is deleted and replaced with your new game.
Please note that the game name, short description and long description cannot contain any line breaks and are restricted in the character they can contain.
When you first create your game, a random icon will be assigned. This can be over-written by an icon of your choice but please be aware it must be a .png format file of exactly 200x200 pixels. Please also respect copyright for any pictures that are not your own work.

Testing a script

You will probably find you spend quite a lot of time in the iterative process that is programming; make a change, test, work out why it didn’t work, make a change, test……. To this end, there are many ways to test out your scripts.

Local testing

From the Upload and Test page, there is a button that brings up a popup window that tries to emulate a mobile device; currently it is a fixed size although that may well change shortly. Given that there are a multitude of mobile devices and they all have different specifications, this popup window is a ‘rough guide’ to what your work will look like. It is however very quick to use and provides a good first view.

Testing on a device

If you have access to a mobile device, then you can download the Styches App. Within the app, you can log in using the same credentials as you registered with on the website. Once logged in, you should find that your own game has been added to the catalogue and you can download it to your device.

Testing in a browser

Additionally, you can click the link at the bottom of the Upload and Test page to get a full browser window view of your game. You can refresh this page each time you upload your changed script if you prefer that way of working. However, please remember that the display on a mobile device is considerable more restricted than a desktop or even tablet, so what looks good and works well in that environment may not be quite so attractive when displayed on a device with more limited space.

Debugging

It is, to be honest, not simple to test your script; certain conditions are detected by Styches (mismatched braces, for instance), but some such as misspelled variable names, object name and locations will simply cause the script to output content you weren’t expecting. You can use the DEBUG command to display a list of all objects (with all their attributes) and all variable. This is best done when using a desktop browser since there can be quite a bit of extra content on a page and that text can require quite a wide screen in order to display the full information.

Pointing others to your script

You can share the link at the bottom of the Upload and Test page with anyone; access is not restricted to the registered user (i.e. you!); this functionality is provided to allow access to your game for beta-testing and comment; however, this method of playing through a script resource intensive for the webserver and therefore it is not the recommended way of consuming the service. Any account/game which abuses this may well be removed from the website and the data deleted. Styches is deliberately designed to work with mobile devices and the App is the way that games should be consumed. Please only use this method for a few testers etc. If you wish to provide the game to a wider audience, please contact us and we will make the game public.

Script documentation

Prohibited characters

Before we do anything else, let’s just clear up some challenges which might cause you problems from the get-go. Please DO NOT USE caret characters ‘^’ anywhere in your game script. It is used internally by Styches.

Restricted characters

Other characters are used within the script to define special sections of the text or to indicate that the script is referring to a feature. You should be very careful to use these at the right places and it would be our advice to only use them for their special purpose. If you only use them when required, the script will be much easier to understand and correct if there are errors.
The following characters have special meaning to the Styches engine:

: the colon character is used to separate the name of a paragraph from its description and to separate some command options as you will see later. Be careful with the use of colons!
[ ] used to enclose a link to another paragraph
{ } used to enclose a command
, used to separate parameters in a link so please don’t try to include commas within a link EXCEPT to separate these parameters
\ used insert a line break into your text. By default, text you enter will be formatted into one paragraph.
| used to separate parameters in a command so please don’t try to include pipe within a link EXCEPT to separate these parameters
$ used at the start of all variables; probably best to only use the dollar symbol for this purpose within your script
# used at the start of a paragraph name to depict that the paragraph is also a location; see later for details
_ the underscore character is used to separate words in a paragraph name; paragraph names can’t contain spaces, so underscore is used instead and Styches replaces them with spaces. This only applies to paragraph names, though.
* an asterisk is used in certain commands to signify ‘any object’; see the command reference section and also the ‘dotted notation’ section later

Paragraphs

Everything in your script is a paragraph. Each paragraph has to have a unique name, followed by a colon followed by the description. The description is free text along with optional links and optional commands. All text that is not enclosed within either braces ‘{…}’ or square brackets ‘[…]’ is just displayed on the page for the player.

When interpreting a paragraph, Styches reads everything up until there is a single semicolon on a line on its own. Styches IGNORES all spaces, tabs and new lines before any alphanumeric characters at the start of a line and after the last alphanumeric. This allows you to format your paragraph how you choose BUT remember that spaces are trimmed off too, so be careful with splitting a sentence across more than one line.

e.g.
ParagraphName:I am a line within a paragraph

Is the same as

ParagraphName:
I am a li
ne withi
n a paragr
aph

Of course, you wouldn’t ever actually do that, but when we get on to commands later, you will see that this can be quite helpful.

The name of the paragraph cannot contain any spaces; if you want spaces in the paragraph name, use underscores instead. These will be changed to spaces by Styches. The name should only be made up of alphanumeric characters and the underscore. It IS case sensitive.

paragraph_name:This text will be displayed to the user.

Comments

Within your script file, you can insert comments by starting a line with a double forward slash ‘//’. The complete line will be ignored. However, DO NOT follow a continuation character with a comment!
// I am a comment line
paragraph_name:This is line one.\This is on a new line.
// I am a comment too

Paragraph names

Every paragraph within your game script must start with a unique name. The name cannot contain spaces and must be made up of alphanumerics and underscores. It is recommended that you always use a paragraph name that reflects the functionality of the paragraph.

Locations

If the paragraph name begins with a ‘#’ character, then this indicated to Styches that the paragraph is a ‘location’. A location is somewhere that the player and objects can be located; When a player is ‘in’ a location, the ‘#’ character is stripped off and underscores replaced with spaces. The name is then displayed in the title bar on the screen; because of this, you may want to be careful with your capitalisation of the paragraph name. The current location is also saved in a special variable called ‘$location’ which you can use in your script to test where the player is and you can also set this variable in order to ‘move’ the player to a new location. When you set the $location variable, no other processing is done, so you may have to also call the description of your new location too (see CALL in the Commands section).
In addition, there is a special location that is used with Objects (see below) called ‘PLAYER’. If you use objects in your script, the location of an object is set to PLAYER if it is in the players inventory.

Paragraph processing order

Every time the player selects a link, there are a series of paragraphs which are processed in the following order.

alwaysbefore
?
the paragraph that specifies a transition from the old location to the new location ?
the paragraph that has been selected
alwaysafter ?

The paragraph names above with a question mark are only processed if they exist in your script. ‘alwaysbefore’ and ‘alwaysafter’ are processed every time a new paragraph is processed and are used for logic such as counting moves, stopping any further processing if desired (such as when the player ‘dies’ or ‘loses’) or tracking other game mechanisms.

Moving between locations

If the new paragraph to be processed is a location (i.e. its name begins with a ‘#’), then Styches will check to see if there is a ‘transition’ paragraph defined in your script. A transition paragraph is one whose name is the last location name followed by a period ‘.’ followed by the new location name. If such a paragraph exists in your script, it will be processed, just like normal.

e.g. #xxxx.#yyyy

You can have a wildcard location in these transition paragraphs that will match any location and are indicated by using ‘#*’. You might use this to account for leaving a location via any number of links but want the same processing for all of them. For example if we had a room called ‘#Dining_Room’ with exits (defined by links of course) to ‘#Hallway’ and ‘#Garden’ AND we wanted to perform some special logic when leaving the Dining Room, we would create a paragraph in our script with a paragraph name of:

#Dining_Room.#*

Regardless of whether there is a transition paragraph or not, then the paragraph defined in the link will be processed.

Special paragraphs

Each script file must always contain at least one mandatory paragraph. This is the #start paragraph and is the first paragraph that Styches processes whenever the game is started from scratch. Usually, this paragraph is responsible for initialising any variables, creating any objects, outputting some welcome text and then moving the player to the first ‘real’ location. You, of course, do not need to use objects or variables in your script if you do not wish to.

However, if you do use objects, then the following paragraphs must be defined. They are the default actions to take when manipulating objects and are called from within Styches; you can override these for each item if you wish. When these paragraphs are called, the special variable ‘$this’ is set to the object in question.

drop:
drop is called whenever the player selects the ‘drop’ button from an object in their inventory. It normally makes a simple statement such as ‘You drop the xyz’ and then call the DROP command.

take:
take is called whenever an object has been listed at a location and the player selects it; you do not have to use this paragraph to actually move the object to the players inventory if you wish; you can make it describe the object if that is your preference.

examine:
examine is called whenever the player selects the ‘examine’ button from an object in their inventory. Remember this is the default for all objects so it will normally make a bland statement.

use:
use is called whenever the player selects the ‘use’ button from an object in their inventory. Remember this is the default for all objects so it will normally make a bland statement.
Additionally, the following paragraphs are optional; they will override the default actions within Styches. Styches check to see if the special paragraph exists in the script; if it does then the new paragraph will be run instead, otherwise the built in action (and output) will be taken.

quit:
quit is called when the player selects the ‘Quit Game’ option from the File… menu. (see the ‘QUIT’ command)

save:
save is called when the player selects the ‘Quit Game’ option from the File… menu. (see the ‘SAVE’ command)

restore:
restore is called when the player selects the ‘Quit Game’ option from the File… menu. (see the ‘RESTORE’ command)

inventory:
inventory is called when the player selects the ‘Inventory’ button. Remember that if there are no objects with a location of ‘PLAYER’ then the inventory button will not be displayed. (see the ‘LIST’ command)

As already mentioned, there are 2 other special, optional, paragraphs which can added to your script. These paragraphs are described above.

alwaysafter:
alwaysbefore:

Links

Every player choice in the game is represented by a hypertext link which the player can select OR through a button on one of the popup menus. Each link (explicit in the script or via buttons) gives the name of a paragraph to be processed when it is selected by the player. A link can define an ‘exit’ to another location for instance, allow the player to uncover extra information or take extra actions. How they are used is entirely up to you, the author.

Format of a link

A link is inserted into a paragraphs text by enclosing it within square brackets ‘[…]’ and has 3 parts inside. The first part is the section of text that will be highlighted and selectable by the player, the second part is the name of the paragraph to process if the link is selected and an optional third part is an object name. Each part is separated by a comma ‘,’

e.g. [highlighted text goes here,newparagraph]
or
[highlighted text,newparagraph,objectname]

Please be aware that since a comma is used to separate the different parts of a link, the parts themselves can’t include commas. Also, please make sure that there are no extra spaces between the parts of the link.

If anything is given as the third part of the link, then the special variable ‘$this’ will be set to this value and this allows the new paragraph to perform logic based on the value of this variable. For more information see the section on variables and also the Command section of this document.

Continue... and (or return…)

When Styches process a paragraph, it watches out to see if there are any links within the output. If there are no links, Styches will automatically add a link which is labelled ‘Continue…’ and if selected will process the paragraph for the current location. If there is at least one link in the output BUT it does not target a new location (i.e. the link directs Styches to a paragraph beginning with a ‘#’), then Styches will automatically add a link labelled ‘(or return…)’ at the end of the output. This link, if selected by the player will process the paragraph for the current location. If you do not want Styches to add these automatic paragraphs, then see the {STOP} and {FINISH} commands in the command reference section.

Commands

Commands give instructions to Styches that can, in turn, make changes to the flow of the output. They can be used to present options to the player, keep track of counters and flag that you use behind the scenes and manipulate objects.

Format of a command

All commands are inserted into paragraphs by enclosing them in curly braces ‘{…}’. Inside the braces you give a command followed by a number of arguments, the number of which depend on the command. These arguments are separated by the pipe character ‘|’.

e.g. {Command|argument 1|argument 2…..}

Variables

Variables are used to keep track of numbers. These variables are given unique names by you, the author and it is advisable to make those names reflect the function for which you have created the variable. For instance, a variable that you create to track the players hunger state might be called ‘PlayerHunger’. There are rules about naming variables though:

All variables must start with a dollar symbol ‘$’

There can be no spaces in the name of a variable

Stick to alphanumeric (a thru z and 0 thru 9) characters only

Variable names are case insensitive (i.e. Avariable, aVariable and AvarIaBLe all refer to the same variable)

Variables can contain integer values and text; any processing that refers to the numeric value of a variable will convert it to an integer, so 12.545 becomes 12 while ‘some text’ becomes 0

To define a variable, simply call a command that stores a value in a variable. This is usually the ‘=’ command and it is good practice to initialise a variable at the start of the game and set it to a known value. However, you don’t have to do this.

Special variables

Styches itself uses variable to track a couple of states and you can read and set these just like any other variables.

$location
contains the ‘location’ that the player currently is (in Styches terms); this is actually the name of the paragraph that was processed that started with a ‘#’. Processing paragraphs that do not start with the has character do not update or change the $location variable.

$this
contains the id of the object that is currently being manipulated; as we shall see shortly, we can call the same paragraph and give it an argument; this argument is saved in the $this variable and you can use it in your logic within that paragraph if you wish.

$title
contains the text displayed at the top centre of the page. Normally this will be the name of the current location. However, you can override this by setting the $TITLE variable yourself within the script.

Variables as parameters in commands and links

Most commands listed below can accept a variable as a parameter, such that rather than explicitly specifying an object, location or value, we can use a variable instead.

Objects

An object is a set of values that represents something in the game that the player can pick up, examine, drop and use. By default, when creating an object, it will be listed whenever the players location is the same as the ‘location’ attribute of the object. That listing will include a link that the player can select which will change the location from whatever it currently is to ‘PLAYER’. It will then be listed whenever the player views their inventory via the button on the screen, again with a link. Selecting this link will present the player with a set of options to examine, use or drop the object. These actions all have default responses unless they are overridden. For full details on all of the attributes of an object and the default actions, see thee CREATE command below.
If you want to hide an object, simply set it’s location attribute to something that does not match one or your locations or PLAYER. This will mean that the player never sees it and can’t interact with it. You may wish to use this feature to manipulate some ethereal features within your game.
You should note that if no objects have a location of ‘PLAYER’ then the inventory button is not displayed. Therefore if you do not wish to use objects in your script, the Inventory button will never appear.

Duplicate objects, the count attribute and it’s special requirements

There is nothing in Styches to stop you creating duplicate objects EXCEPT each object must have a different identifier. ALL OTHER ATTIBUTES EXCEPT ‘count’ MUST BE THE SAME.
Styches works out that the objects are the same by comparing the ‘name’ attribute; if they are the same, it assumes the object is the same and will perform special handling when the objects are taken or dropped. THIS ONLY HAPPENS with the ‘TAKE’ and ‘DROP’ commands listed below in the Command Reference AND if the objects share an identical ‘name’ attribute. Styches achieves this by manipulating the ‘count’ attribute of the objects such that if 2 objects with the same name are moved into the same location (including the ‘PLAYER’ location), then one of the objects has it’s count attribute adjusted to reflect the new number and the other object is either destroyed (if it is ‘taken’) or has it’s value set to zero (if it is ‘dropped’).

This may be best explained by a quick example:

First lets ‘create’ 2 objects as follows:
Object1|name:example object:count:1|location:PLAYER
Object2|name:example object:count:1|location:room

Then, if the player takes Object2, the count attribute for Object1 is increased to 2 and Object2 is destroyed.

If the player drops Object1 in ‘room’, then the count attribute for Object2 is increased to 2 and the count attribute for Object1 is set to zero.

Count is an attribute that all objects have and by default, as we saw above, it is set to 1. When the count is 1, it is effectively ignored (listings and inventory etc simply print a/an…. for instance). However, if count is set to be a number greater than 1, the list and inventory actions will instead print the count value followed by either the ‘name’ or the value of the ‘plural’ attribute if it is set. As an example, if we have created an object with a count of 3, a name of ‘bullet’ and a plural of ‘bullets’, when we list is against a location of in the inventory etc, Styches will output ‘3 bullets’. If we reduce the count to 1, ‘a bullet’ will be output. Similarly, if the count attribute is set to zero, then the object will not get listed in the inventory (it is effectively hidden from the player). This is all well and good, BUT if we as an author want to check to see how many bullets we have, which object do we check? Object1 or Object2? Well, the secret is to create an object that has a 0 count right at the start of the game script and the Styches will detect this an always keep a copy of that object in the players inventory. Thus, when objects are taken and dropped, the count attribute of this special object will be adjusted up and down and it will always be available for you to test against. If you actually want the player to start with this sort of special object BUT with a count of something other than 0, then give it an attribute of ‘static:Y’ when you create the object. In our example, if we wanted the player to start with 1 bullet, then the object attributes would be:
Object1|name:example object:count:1|location:PLAYER|static:Y
Object2|name:example object:count:1|location:room
Please use static objects sparingly as they slow down the processing of the game script and whilst on a desktop PC that isn’t an issue, on a mobile device, it can cause a noticable pause during gameplay.
Note that if you drop an object that is set as static, AND THERE ISN’T already an object with that name at the current location (which will be the normal situation in most games), then Styches generates a random object name that is an exact duplicate of the original object, makes the location of this new object the current location and sets the count on the static object to 0.

Object attributes

Each object has a predefined set of attributes which are listed below as part of the CREATE command. However, this list is not definitive. You can create an attribute with any name you like (alphanumerics only please) to add something to your object which you can then use to drive logic and output. Very simple examples of this are to add something like a weight, score or monetary value to each object. Please note that not all objects in your script need to maintain or declare these attributes; for an example see the example game script at the end of this document where a torch is declared with a unique attribute of ‘batterylife’.

Advanced object manipulation (or 'dotted notation')

To access and manipulate the attributes of objects within your game, you can use a mechanism, which we’ll call ‘dotted notation’. The basic format of writing this method is the object followed a set of identifiers, separated by full stops (‘.’). The number of identifiers is not fixed and if they are not defined, Styches assumes a value for them. At least 2 identifiers (including the object) have to be given or Styches will not be able to perform the calculation.

With the dotted notation, Styches tries to match all the objects it can with the object ID you have given. Thus, for commands that do not specify a location, Styches will inspect and use all matching objects in the game. Please note that you can specify an object ID, object name or an ‘*’. The ‘*’ means ‘all objects in the game’ and helps when (for instance) you want to check how many items are at a location but don’t care which objects they actually are.

The basic format of the dotted notation is:

<object>.<attribute>.<command>.<location>

where:

<object> can be either the ID of an object, the name of an object or a wildcard ‘*’ which means ‘all objects’.
<attribute> is one of the attributes that an object has, either as one of the standard ones or one that you have defined. If <attribute> is not given then the ‘count’ attribute is assumed.
<command> tells Styches what to add up in order to return the value you want. These are listed below. The only time that <command> can be omitted is for <object>.<attribute>, where the method simply returns the value of the given attribute for the given object.
<location> defines for commands where location is used, the location. If <location> is not given, then the current location is assumed.

For all of the examples in the following section, we are going to make refernce to some objects whose name is ‘coin’ and which have an additional attribute (because we created it when we created the coins) of ‘score’

The relevant attributes of the coin objects are defined as follows:

Object ID name count score location
coin1 coin 3 2 #Treasure_Room
coin2 coin 1 2 #Hallway
coin3 coin 1 2 PLAYER

The first method is the way to get or set the attribute of an object where the first part is the object identifier and the second part (after the ‘.’) is the attribute we want to reference. By way of example, if we have an object ‘coin1’ which has an attribute ‘score’, we could refer to this as:

coin1.score

With this particular method, the <command> and <location> identifiers have no meaning, so are always omitted. If you specify them, they will be ignored.

Remember we said you can set an object attribute using this method? Using this feature, we can change both attributes which we have defined for out own use OR we can set the values of some of the standard attributes. This way we can change the text associated with droping, examining or using an object as well as the paragraphs that are called when those actions are selected by the player. For example, if we wanted to programatically change the ‘use’ label of an object with an ID of sword, we can enter a command like so:

{=|sword.USELABEL|Equip}

The next time the player looks in their inventory and selects the sword, the label on the button will have changed to ‘Equip’. By using this functionality, you are able to change the labels and actions of all of the buttons within your script and use this to create puzzles for the player if you wish.

.NUMBER
Adds up the total number of the given attribute for objects whose name or id match. If the attribute isn’t given, this will return the total number of the ‘count’ attribute.

For example, if we have an objects named ‘coin’ which has an attribute ‘score’, we could refer to this as:
e.g. coin.score.NUMBER would return 6 (2 + 2 + 2 and not 5 as you may have been expecting.)

.SUM
Multiplies the value of the ‘count’ attribute by the specified attribute and returns that number.
e.g. coin.score.SUM would return 10 (3 x 2 + 1 x 2 + 1 x 2)

.NUMBERVISIBLE
Adds up the total number of the given attribute for objects whose name or id match AND are where the location of the object is either the given location or the PLAYER. If the attribute isn’t given, this will return the total number of the ‘count’ attribute. If the location isn’t given, the current location is assumed.
e.g. coin.score.NUMBERVISIBLE would return 4 (2 + 2)

.SUMVISIBLE
Like the .NUMBERVISIBLE. method above, EXCEPT that the result is the ‘count’ attribute of the object(s) multiplied by the attribute specified. The returned value is the total number of the given attribute for objects whose name or id match AND are where the location of the object is either the given location or the PLAYER. If the attribute isn’t given, this will return the total number of the ‘count’ attribute (so you get ‘count’ multiplied by ‘count’, which is interesting…!). If the location isn’t given, the current location is assumed.
e.g. coin.score.SUMVISIBLE would return 8 (3 x 2 + 1 x 2)

.NUMBERLOCATED.
This method returns total of the given attribute for all of the object(s) where the location of the object is the given location. If the attribute isn’t given, then the ‘count’ attribute is used. If the location isn’t given, the current location is assumed.
e.g. coin.NUMBERLOCATED.#Treasure_Room would return 3 (we didn’t specify ‘score’ here, so ‘count’ is assumed; if we’d put .score. then the answer would have been 2)

.SUMLOCATED.
This method returns total of the given attribute for all of the object(s) multiplied by that objects ‘count’ attribute, where the location of the object is the given location. If the attribute isn’t given, then the ‘count’ attribute is used. If the location isn’t given, the current location is assumed.
e.g. coin.score.SUMLOCATED.#Treasure_Room would return 6 (3 x 2)

.NUMBERPOSSESSED
This method returns total of the given attribute for all of the object(s) where the location of the object is the players inventory. If the attribute isn’t given, then the ‘count’ attribute is used.
e.g. coin.score.NUMBERPOSSESSED would return 2 (and not 1 as you may have thought; specifying ‘score’ means that is the attribute that is added up)

.SUMPOSSESSED
This method returns total of the given attribute for all of the object(s) multiplied by that objects ‘count’ attribute, where the location of the object is the players inventory. If the attribute isn’t given, then the ‘count’ attribute is used.
e.g. coin.score.SUMPOSSESSED would return 2 (1 x 2)

Embedded HTML markup

Since all of the output from Styches is essentially HTML, you can embed HTML tags into your game script. However, you must be very careful doing this as it can upset the way that Styches outputs text onto the device. Also, any html that requires an external resource (such as a picture) should not be used as it will not be available if the player is offline. Similarly, don’t include any links to other web pages.

Also, please remember that the player may well have set up the screen colours to their own liking, so there can be no guarantee that a colour combination you have forced through HTML will look how you want.

Some simple tags that can enhance your text are:

<br /> This will force a new line in your text. This is the same as putting the backslash character.
<i>...</i> Makes the section of text between the tags italic
<b>...</b> Makes the section of text between the tags bold
<u>...</u> Makes the section of text between the tags underlined
<q>....</q> Adds quotation marks around the enclosed text.