This article is aimed at relative beginners to ChoiceScript Game Development. However, it assumes that the reader is already familiar with most aspects of ChoiceScript. If this is not the case, the best place to start would be with the first in this series of linked articles: A Basic Tutorial
This article discusses Basic Scripting Techniques, offering some general tips and other things to consider based on experience. It is intended to help you develop a methodical and orderly approach to game scripting & basic testing, from which to adapt and better develop your own techniques.
It's not crazy to talk to yourself!
*comment Code below determines the final route _not yet_ chosen
The *comment command allows you to talk to yourself... literally. Anything on this line is essentially "scripting notes" to yourself (or anyone else with whom you might share the code) and will never be displayed in the actual game.
Leaving comments for yourself is a useful habit to get into, especially where it applies to complex or confusing scripting. While it's all fresh in your mind you may think "I'll remember what this does, no problem" but -- believe me -- several months down the line you'll most likely be left scratching your head and trying to figure out what it does, or how it does it, or why it works in that particular way... all so that you can make a now-necessary minor change, preferably without breaking it or creating new bugs. Spending ten or twenty seconds typing a quick *comment now could save you much, much more time later.
Building a *choice body
The following is an example of how story narrative may conclude with the need for player interaction, in the form of a decision to be made:
The winding dirt track eventually drops down into a deep, forested valley, where it splits into three paths. The main path continues east, heading into the depths of the forest. The southern branch appears to skirt the edge of the forest, generally heading downhill towards the distant coastline, while the third branch slants north, heading back up into the hills and seeming to lead towards the mist-shrouded mountains on the horizon. *choice #Continue along the main path eastwards, heading into the forest. #Turn south, skirting the edge of the forest, towards the coast. #Turn north, staying to the high ground, heading for the mountains.
While the above is not yet a valid *choice command as it contains no additional scripting to handle the player's input (and so would error), there are two different but equally important points worth noting here:
1. When first devising a new *choice, it is always a good idea to first lay out all the intended options exactly as shown above, before adding any extra scripting for actually handling each #option. Not only does this help to clarify things in your own mind, it also sets the correct indentation level for each immediately. As you script the first option, so will the second and third options be pushed farther and farther down the page, making it harder to get the indentation exactly right if only added later -- especially when working on nested *choices (choices within choices within choices). In essence, you will find that always immediately laying out all the intended *choice #options as above will be useful in avoiding indentation errors as your scripting hierarchy expands.
2. Strictly speaking, this is a "poor" type of *choice, as it gives the player no actual information to aid in making a decision. However, if this is intentional branching to add such as replay value (each of the above routes leading on to different encounters, for example) then there is absolutely nothing wrong with this type of route-branching *choice.
If, however, two of those options would result in immediate and automatic character death, then this would indeed be very poor interaction-prompting. You would essentially be dictating the character's fate based on pure random luck, having in no way indicated which might be the only safe route, nor allowed for the possibility of the character's own stats playing a part. In essence, it is important to bear in mind that death by sheer random bad luck rarely makes for a compelling or enjoyable ChoiceScript game.
Using narrative placeholders
*choice #Continue along the main path eastwards, heading into the forest. AAAAA #Turn south, skirting the edge of the forest, towards the coast. AAAAA #Turn north, staying to the high ground, heading for the mountains. AAAAA
Another useful trick to consider, shown above, is inserting a common, eye-catching "reminder" placeholder for yourself wherever you later intend to add story narrative. This may be within a *choice body as above, within a *if / *elseif / *else section, following a new *label you've just created for future use, or indeed anywhere and everywhere intended to be a branch or other continuance of story narrative. As your scripting hierarchy expands, or the narrative itself becomes more conditional, this simple trick makes it much easier to keep track of (and later actually find) all such intended branching still yet to be done. It can be a useful habit to get into from an early stage.
Using scripting placeholders
It's generally a good idea to test each significant section of your scripting as you go, by running the game in your browser locally. Adopting certain practices can make this easier, of which the following is one useful example.
*choice #Continue along the main path eastwards, heading into the forest. (You are now working on this option) *goto todo #Turn south, skirting the edge of the forest, towards the coast. AAAAA *goto todo #Turn north, staying to the high ground, heading for the mountains. AAAAA *goto todo *label todo This section still to be done. *page_break *ending
While working on *choices likely to deviate considerably, it's worth considering using a temporary *label at the bottom of your file, as shown in the example above, so that you can use a placeholder *goto where required to prevent returning an error during testing.
The above example effectively and easily makes that entire *choice statement valid, allowing you to work on scripting everything resulting from the first option and to actually test it in your browser as you go. Without those placeholder *gotos and a valid *label reference, the game would return an error at this point, making it impossible to properly test your first #option's extended scripting until you've completed all the scripting for all three (or more) #options.
Switching between mini-scenes
Within a single scene .txt file it is common to include what are essentially multiple mini-scenes (or vignettes), where the narrative jumps to a new time or place (or both). It may be only minutes later in the player-character's perspective, or it may be hours, days, weeks, months or even years later. This abrupt time-or-place displacement can be quite jarring for the reader if you still always use the default *page_break ("Next") button as is normally used for continuing through successive pages within the same mini-scene.
Consider instead using alternative button text when moving between two entirely different mini-scenes, along the lines of any of the following examples:
*page_break End of Scene *page_break Scene End *page_break Next Scene *page_break Later . . .
Or whatever you feel is appropriate for your game. By this means the reader becomes subtly attuned to the difference in button wording from the normal "Next", so making the transition between two entirely different mini-scenes considerably less jarring on a subconscious level. This is essentially the same principle as that behind the *finish button's default wording being "Next Chapter" instead of just "Next".
Start a mini-scene with *page_break
*label new_mini_scene *page_break Next Scene
Generally speaking, you will almost always start a brand new mini-scene within your scripting with a new *label section. This *label will also often be referenced by multiple *goto commands, at the end of all the various different routes through earlier mini-scenes.
By always placing the *page_break Next Scene (or whatever your preferred button wording) at the very start of each new mini-scene -- before any actual narrative or other scripting -- you don't have to remember to place a *page_break Next Scene immediately before each & every *goto command jumping to this new *label.