Continuing the discussion from Dialog vs. Inform 7:
There isn’t anything Inform-specific about the way the skein is implemented. Theoretically someone could borrow the code from the skein and put it in Dialog if implementation language and licensing permit.
A Skein would be interesting, though I wonder how to best represent one.
If I recall, right now it is possible to feed a text script in to a game being run by dgdebug and redirect the output to a file, which can then be tested with diff against expected output, much like blessing. What is missing is some method for adding branch points and jumping back to them in a single input script. (A graph visualizer like Inform 7 has would be nice, of course.)
I think the @save and @restore utilities of dgdebug might be used. Consider the case of going north, then either going east or west. A skein might be:
go north
@save
branch1.log
go east
look
@restore
branch1.log
go west
look
This gives us almost what we want:
An Interactive Fiction
An interactive fiction by Anonymous.
Release 1. Serial number DEBUG.
Dialog Interactive Debugger (dgdebug) version 0m/03. Library version 0.46.
Home
You are here.
> go north
You walk north.
Branch
You are here.
> @save
branch1.log
Note: Successfully wrote input history to "branch1.log".
> go east
You walk east.
Desert
You are here.
> look
Desert
You are here.
> @restore
branch1.log
Note: Successfully read input from "branch1.log"
An Interactive Fiction
An interactive fiction by Anonymous.
Release 1. Serial number DEBUG.
Dialog Interactive Debugger (dgdebug) version 0m/03. Library version 0.46.
Home
You are here.
> go north
You walk north.
Branch
You are here.
> go west
You walk west.
Forest
You are here.
> look
Forest
You are here.
>
Ideally however a skein shouldn’t reprint what’s already been printed, we don’t want the whole story told over and over again just the parts that differ. Maybe dgdebug can be modified so it is possible to @restore quietly? Another thing that may be an issue with large stories with lots of deep branches is that on restore the whole story is processed from the beginning; saving and loading binary dumps may be more efficient, at the cost of portability between systems.
Blessing would simply be saving a log to diff against for regression tests, I think.
I may be missing the point about skeins however, as I never really used them in Inform 7, so maybe there is a use case this doesn’t address.
Maybe this is obtuse of me, but could you not simply chunk each path’s transcript by input prompt and then adopt some kind of diffing logic to merge them?
I’m exploring how to implement this - a skein implementation for Dialog. We’ll see how much progress I make.
The basic mechanics of the skein aren’t too hard, if I can manage to properly run ddebug in a sub-process, feed it commands, and capture resulting output.
The rest is UI; I’m learning Svelte for this part.
I’m more of a back-end person, so we’ll see if I can make it work properly. New stuff to learn!
I think this would make a big difference in Dialog adoption, if I can pull it off. It is a big improvement over the tests my dialog-tool can handle, and it will be more natural to develop tests and visually see the results.
What is a skein in this context? It sounds like it has something to do with debugging/testing of inform games, but this thread is making little sense to me and I’m not comprehending how a skein of yarn as a metaphor could be added to game design.
yeah, i had no idea what any of this meant and simply looking up “skein” didn’t help at all.
but it seems to be this:
https://ganelson.github.io/inform-website/book/WI_1_7.html
and it looks pretty cool.
And reading that linked article, it sounds like a major accessibility hurdle if I ever give learning Inform another go. Don’t get me wrong, sounds like an excellent way for organizing game/story flow visually, but visual aids tend to range from useless to insurmountable obstacle for a blind person.
You don’t need the Skein to program in Inform. I’d go so far as to say that most Inform programmers probably don’t use it much.
EDIT: It would be an interesting challenge to make it accessible, though.
The point of the Skein is not for typical play, it is for testing. Ultimately, dgt will have a mode that runs a skein completely (to all terminal nodes) and reports back on any failures. Alternately, the Skein’s UI can be used as an alternative to typing into the debugger.
I’ve made some progress (running dgdebug in a sub-process, collecting output into the Skein tree) and I’m working on the UI. Fun stuff, but I wish I could focus on it for more than a couple of hours a week!
I’ve been using Sandancer, about 358725 words of source, and time to startup dgdebugger and collect the initial output is ~ 110ms, so bending over backwards to keep the process running (using save and restore tricks) is not actually worth it, at least for now.
Here’s a bit of video of the Skein in Inform 7, that’s what I’m busy reproducing (in some fashion).
I’ll be able to share what I have in a few weeks. It will be much longer until I have a UI as polished as in the video.
This is what I use as a makeshift Skein, currently:
regress: $(files) stdlib.dg
dgdebug -s 1234 $(files) stdlib.dg <regress.in >regress.out
meld regress.out regress.gold
regress.z: dumb.z5
dfrotz -m -s 1234 dumb.z5 <regress.z.in >regress.z.out
meld regress.z.out regress.z.gold
Making progress on this and I’m pretty happy … the UI is clunky and ugly but so fast I’m going to have to add animations to convince the user that anything has happened!
But its not yet anything graphs and nodes; it basically a linear list of “knots” from the start node to a terminal node.
I really like the skein, but yeah, my sense is that I am very atypical in that. Conversely, lots of folks seem to use the built-in “test me” syntax to quickly check a large number of commands and responses all at once, while I almost never do so , so I think to a certain degree they can substitute for each other (and “test me” works perfectly well for visually-impaired folks).
I’m looking forward to having a tool that can quickly run my game across dozens, maybe hundreds, of scenarios and quickly identify anything that changed – programming is all about the law of unintended consequences, and in real life I’m quite the test-driven developer.
For example, with Threaded Conversation there are just so many interactions between quips and characters and other state that I wanted to make sure was just exactly right, and any small improvement or optimization could potentially break everything.
I’ve been making some really nice progress on this, it’s getting to a state where I can share it soon. A key bit I just implemented is “Replay All” which plays through to every leaf knot in the skein (with a progress bar since that can take a while). That’s really critical, since it gives you the feedback of “did anything unexpected change?” after fixing a bug.
The above is a simulation of me fixing a typo. You can see the diff in the red knot. Each knot has those pill buttons that select the next knot below it, and knots that lead to an error get a marker. This skein has 459 total knots (!). Some knots have labels, and the Jump drop down lets you directly jump to a knot.
And, by the way, while building the tool and testing it against Sand-dancer, I did find some typos!
It’s early and incomplete but you can now play around with the new dialog-tool and skein.
It should just be as simple as brew install hlship/brew/dialog-tool.
This branch of sanddancer-dialog has the revised dialog.edn and a game.skein to explore:
I found that using (restart), rather than just starting an entirely new process, only shaved a few milliseconds off of execution time (I was eyeballing things using “replay all”). Again, this was with a non-trivial code base (Sanddancer).
In fact, the problem with the UI right now is that everything outside of “Replay All” is essentially instant. I need to work on some animations to provide feedback to the user that anything actually happened!
I’ve been fleshing out some of dgt beyond just the skein. Just added dgt new to create a new Dialog project from a template. This includes copying the dialog libraries into the new project.
