I’ve been writing Squiffy games for a couple of years now and really enjoy it. It lets me write gamebooks, which is what I’m more interested in. But below are some lessons I’ve learned which I hope might help someone just starting out.

1) The Squiffy Editor: While the Squiffy editor is good enough, it will occasionally mangle code or work on strange ways. I’d suggest that every session you spend coding, you start by saving off your current file to a new version number (i.e. “MyGame5.sq”). Trust me – if the editor breaks (or your javascripting goes south) it’s better to lose a nights code than an entire game.

2) Pathing: A lot of my games are pretty complex with lots of paths that branch all over the place. For this, I use Microsoft Excel to plot my various adventures. Generally progress is “down” and options extend “right”. Code that is done is cell-colored green. Code still needing work is yellow. Broken or critical code is in red. And the actual section names can be cut and pasted into the cell comments, so you can easily jump your editor to a section requiring your attention.

3) Branch testing: often I’ll need to branch test (or, as I develop, to navigate quickly through the game to a specific spot). For that, I place a debug section at the bottom of every section. Set a Boolean value called “debug” – when you test, set it true. This permits you to click on options that might be randomly based on circumstances not easy to duplicate (it’s raining, it’s dark, you have an umbrella). It is especially good in random / combat situations where you need to win or lose to get somewhere. Example:

{if debug: -DEBUG-
[[combat win]]
[[combat lose]]
}

4) Things To Do: I once had a game where an inventory item kept bumping up. I noticed it but have the devil of a time finding out why. Finally located a section where I’d set an item to 1 just to force a branch. Now, for any temporary code I include (or path that will be coded later) I add a comment of “TTD”. This way I can search for all occurrences of this and make sure I’ve cleaned out all my scaffolding. Example:

<TTD>
@set item=1

5) Javascripting: Java scripting is important. Without it, you can’t randomize or have sections that run through and change things without a user prompt. However, it you break your code, you’re going to have to work through everything you’ve done to find that small typo that caused it all. So it’s always good to click the run button every line or so coded just to make sure you didn’t break anything. Let me tell you the night where I wrote fifty lines of code and then found out something was busted.

6) Understanding Squiffy Attributes: My first couple of attempts had to rely on javascripting because using the @set command sets a variable in the section it occurs in, regardless of your Squiffy logic. However, using the {@} addressing method will permit variables to only set if logically executed. Further, rather than setting them as soon as the section is run, they only execute when the code flow rolls over them. This means you can test for something being true and THEN set it to false, in sequence. In the example below, change the value for “a” and see what happens.

[[test]]:

@set a=1
@set b=0
@set c=0

{if a=1:
@set b=1
{@c=1}
}

a: {a}<br>
b: {b}<br>
c: {c}<br>

7) Reference Manual: If you don’t quite get what I’m saying in {6) above, check out the reference manual located below. This really changed the power of my Squiffy code and opened things up to real development.

https://dynalist.io/d/kocz1psBWP_sDFR0bk8wApfY

Anyway, good luck and good game design!

@Bluevoss, you really know how to give instructions. Thanks for taking the time to help others.