Scenes are the primary component of making a story. Each scene carries effects and may have prompts. In each story, a start scene is required. This is like opening page 1 of a book.

The first parameter of defscene is the scene identifier, this is used by prompts and other story functions. All the following parameters are executed when a scene is executed.

(defscene start (text "Hello world, this story is short") (prompt ending "It was short lived") ) (defscene ending (the-end) )

Effects

To send messages or demonstrate other effects, special functions are available.

text will send a text message, it needs at least 1 parameter and will concatenate all other parameters when forming the text message.
image will result in sending an image in particular, the first parameter must be a full direct link that can be saved
wait will wait some seconds before contining with the effects thereafter. This may be used to set the pacing of a scene.
continue is similar to wait in that it blocks the subsequent effects, but the result is that the user must give input to continue. This may be best used for long scenes without branches and or long texts to let the player experience a scene at their own pace.

(text "Hello world") (image "https://i.imgur.com/3ncGVzn.jpg") (wait 2) (continue)

Prompts

Prompts are how the game gives the player options, it has two parameters.

Scene identifier, for example (defscene eat-cookie ...), use cookie.
Option label, this is what shows up as a button or option.

Prompts will always be provided on the last message. Prompts may be added throughout execution, it is up to you to not have duplicates.

(prompt scene "Button text") ; ^ ; Refers to the defscene name ; (prompt another-scene "Another button") ; ^ ; Label the option will have

Storage

Whenever you save something, you can later access it with load by using the same identifier across scenes. You can modify and read the same storage variable multiple times in a single scene too.

Sometimes not everything is initalized. To make sure your code behaves normally, it is best practice to include a default value when you load something.

; You can save and load values by using an identifier ; Identifier ; v (save cookies 10) ; ; Value to be stored ; v (save name "mudkip") ; In case you never stored the value before, it will be as if it were 0 here. ; | ; v (text "You have " (load cookies 0) " in your inventory")

Functions come first after the left parentheses. Here, if is a function that takes three parameters

Condition
What to execute when the condition is true, hereby true-path
What to execute when the condition is false, hereby false-path

Within the condition (< (load cookies 0 ) 5), the function <, otherwise named less-than, is a logical operator which takes two parameters. Suppose the result of (load cookies 0) is 3 then the function will reduce to (< 3 5) As with normal math, 3 is less than 5, so (< 3 5) is reduced to true.

To perform multiple operations within a single parameter, use the do function. It accepts as many parameters as you give it. Consequently, the last parameter is what do will reduce to.

(if (< (load cookies 0) 5) (text "You don't have enough cookies") (do (text "You has so many cookies!!") (text "Like, so many, I could take " (load cookies 0) " of them!") ))

Samples

Want to see some code in action? Check out the samples.

Hello World
Demo Man - includes multiple scenes, some storage, some logic
Money and Muffins - includes multiple scenes, loop back, storage, logic, customizations
Cookies - includes multiple scenes, loop back

Limitations

Scripts you write for games operate in two phases: definitions and dynamic. The definition phase is used to figure out the structure of the game, using commands like(defscene). The dynamic phase is involved in any action a player makes. For example, if they choose to smell the cookies, the smell will then be executed.

In particular, it is important to note that each phase of execution has limits in place. Namely, how many executions, calculations, storage load and save, etc. can occur.

It is unlikely for you to experience these limitations unless you create a sufficiently large game, or make a mistake that would otherwise be considered a 'soft-lock' or a crash.

During development, you will be notified when any errors, crashes, or the like while play testing in the editor. However players on published stories will only experience errors in the worst conditions. If a player experiences a crash, it likely will result in a bug instead and execution will continue. This may result in a player suddenly having no money in a game, or whatever the crash would have affected.

Publication

In order to publish a game, the script needs to be saved and then prepared for publishing. You always will be able to review or revert to previous versions of your game scripts. Once you are ready to publish, go to and find the saved code you wish to publish. It will likely be marked as Is Current Draft. Then mark that code as commited with . Finally, you should be able to hit . However, if the game is already published, changing the committed codewill instantly be what players experience, even for existing sessions.Be wary that any incompatibilities between code versions may result inbugs the player experiences.

Unpublishing a game is a serious decision and may result in terminating or losing the progress players have made in their current session.