I’ve made reasonable progress the last three days…
Friday, June 7
I spent a little time thinking about how to implement difficulty
checks (should be trivial) and displaying requirements (not so
much).
But the big thing I did was to go through the entire StoryNexus
Reference Guide and summarize it. It’s amazing how much of it is
about different ways to display or check qualities. Where do they
appear in the UI (if anywhere)? Do we display them as strings or
numbers (or icons, or progress bars)? Do the strings identify
single values or ranges of values?
Now I can see why Alexis Kennedy said,
“the fundamental characteristic of ‘qualities’ in the Failbetter
sense is that they are all created equal […] This was a
deliberate design decision […] but now I think it erases too
many potentially useful distinctions. And, in fact, the subsequent
development […] saw many, many attempts to add, or hack in,
different ways to describe the value of, and changes to,
qualities.”
But I still think that problem goes away if you have a set of
building blocks for quality-based narratives instead of a machine
which plays a particular kind of quality-based narrative and
requires new buttons and levers and knobs for every variation that
it wants to allow. I don’t think the StoryNexus restriction of
“all qualities are non-negative integers” is the real problem.
It’s more a question of whether users can extend the system and
rearrange it to suit their needs.
A naive approach to the building blocks style does have its own
difficulties. If you just hand new authors a giant set of blocks
and say, “here, go build something”, that’s overwhelming. How
many different pieces do you have to understand? How many
different possibilities do you have to discard to find a design
you like? But if it’s introduced well it can be very beginner
friendly. You need a good default structure which just works
straight out of the box, and which is relatively easy to customize.
And you need a good cookbook explaining how to do specific common
tasks.
Saturday, June 8
I went through my StoryNexus summary and made a list of things to
implement. Most of them are interface pieces that can be add-ons
and are also easy to implement individually. So I have lots of
little easy tasks now. But there are a couple of things that need
to go into the core. Filtering/sorting cards by priority, for
instance. And I probably need some support for choices succeeding
or failing based on a skill check and a random die roll. And
support for a cancel button (the “Perhaps not” buttons in
Failbetter games). But I think all of those are straightforward.
So the big piece that’s left is displaying requirements so players
know why a particular card or choice is locked. I have an idea how
that will work, but I’ll probably let that marinate for a few days
while I implement some of the little stuff.
Sunday, June 9
I didn’t get any more done yesterday because farm work went into
the evening. But this morning I wrote a first draft of Basic
Abilities (StoryNexus’s stats which get better or worse as your
attempts succeed or fail) and a <<gotoresult>>
macro for use in
<<link>>
s and <<button>>
s. The difficulty checks are code, not
tags, so it’s separate from the other requirements, but I think it
will be OK. It’s fairly readable. If you define a skill:
<<set $cunning to new BasicAbility('broad', 25)>>
Then you can make a button that checks it:
<<button "Button Title">>\
<<skillcheck $cunning 80>>\
<<gotoresult "Result">>\
<</button>>
It will go to the passage “Result Success” if the skill check
succeeds, or “Result” if it doesn’t. If you create “Rare Result”
or “Rare Result Success” passages, it will go to those 20% of the
time. And of course the difficulty could be a variable instead of
a hard-coded number. And it works with <<link>>
as well as
<<button>>
. And if you leave out the skill check, it will always
go to “Result” (or occasionally “Rare Result”).
This took me much longer than I would have liked (I spent about
two hours fiddling with it), but I’m still figuring out how to
design interfaces that work with the grain of Twine and SugarCube.
I think I’m getting a handle on it, so hopefully the other “simple” pieces will be
quicker. Other types of stat/trait objects should certainly be
very easy. I have JavaScript code somewhere for Choice of Games’s
Fairmath, Inkle’s ratio-of-choices, and Chris Crawford’s Bounded
Numbers, so I might throw those in there just for fun. We’ll see
how my time goes.