I’ve ported a cyoa game to Dialog. It works a bit so far, but I had some problem to make it work like this game was designed first.
The problem is the description (here in the #start node) of a link, is called from within the linked node (here in the #rosebud node):
#start
(disp ) You extend your wings. A warm, buzzy feeling spreads through your body
as you leave the hive.
( offers rosebush)
(* offers #poppies) rosebush
(label *) Follow a scent of roses.
(disp ) You hover for a while near the pink rosebush.
( offers #poppies)
But in traditional CYOA games, you generally make the description of the choices within the chapter itself:
Start chapter
You extend your wings. A warm, buzzy feeling spreads through your body as you leave the hive.
Follow a scent of roses.
Follow a scent of poppies
Rosebug Chapter
blabla
I’ve managed to mimic this behavior this way:
(I just declare the label within the first node, and not in the destination node)
(intro) (activate node #start) #start
(disp *) You extend your wings. A warm, buzzy feeling spreads through your body
as you leave the hive.
(label rosebush) Follow a scent of roses.
(* offers rosebush)
(label #poppies) Follow a scent of poppies.
(* offers #poppies)
You can add a condition to a label, to check if a particular node is active:
#start
...
(label #rosebush) (current node *) Follow a scent of roses.
#poppies
...
(label #rosebush)
(current node *)
You decide that you prefer to go to the rosebush, it’s a nicer place.
I realize this is far from obvious to a beginner, so I’ll be sure to clarify it in the manual. Thanks for pointing it out!
Conditions can be arbitrarily complex:
(label #rosebush)
(current node $N)
($N is one of [#start #poppies])
Follow a scent of roses.
To save typing, you could even define a helper predicate:
(label $Target)
(current node $Origin)
(label $Origin to $Target)
Then you can define labels like this:
#start
...
(label * to #rosebush) Follow a scent of roses.
Or even like this:
(label #start/#poppies to #rosebush) Follow a scent of roses.
Thank you, it’s working now! It’s a nice trick, it will be a good idea to put it in the Dialog manual.
I still have problems with general texts in parenthesis, they are recognised as predicates, but it’s not a strong problem, I’ve adapted my text.
I’ve managed to convert automatically an old little CYOA game I’ve made, into Dialog. There are already several HTML CYOA engines (and Dialog looks great in this aspect), but it’s even better to be able to convert it to a C64 game!
oh, of course a backslash! How didn’t I think of it? I was already confused by all my work for using some regex in my conversion tool that I didn’t expect Dialog to support this simple syntax…
I’ve worked more on my converter. I’ve managed to convert the first episode of the Lone Wolf gamebooks:
I’m considering Choice Mode on the web version. I’ve played around with the standard library to try to make each choice link clickable, but how its actions work is still a bit unclear to me. What’s the easiest way of doing that while still keeping the usual behaviour for purely keyboard-driven terps?
This will turn each choice label into a link, and clicking it will simply input the corresponding number.
But it will also enable library links for nouns printed using (a $), (A $), and the default appearance of handled items. If that is a problem, I could add a separate flag for enabling just the choice links.
After a choice is made, the links and their numbers are no longer relevant. Rather than clearing the display with (clear), you can use (clear links) to turn old links into plain text. This could be done e.g. when displaying any node:
Thank you. I belatedly found a section about it in the Understanding chapter, so apologies for asking obvious questions. The default functionality looks very nice indeed.
I’m curious, though: do you envision Dialog going further in the direction of allowing mouse-driven choice based games? I’m intrigued by the possibility (I would much prefer building a game on Dialog as opposed to Twine), but I’d also understand if you see it as a departure from the original goal of a lean, retro-friendly ruleset.
The term “mouse-driven choice based games” has many connotations.
For instance, many choice-based stories have the player navigating a branching tree of alternative plot lines, where parser-based stories have the player exploring a geographical space while encountering a fixed set of plot points. Dialog as a language can support either of these scenarios, but the standard library is based on a geographical world model with rooms and objects. On the other hand, it would be relatively easy to create a new library from scratch, for node-based navigation without a world model or a parser.
Another common difference is that Twine-like stories often allow the reader to play with (elaborate, alter, rephrase) the text on the page, whereas a traditional parser game only lets the player decide what action to take next. The past is forever fixed in a transcript, and the author has full power over the point of view through which those events are narrated. I like the idea of a fixed transcript, and Dialog reflects that. Sure, with a little creative use of (clear), it should already now be possible to mimic the cycling links and other kinds of malleable text common in choice-based fiction, where players can adjust the words on the screen and explore the corresponding changes in meaning. But I don’t see the language opening up much further in that direction, at least not for now. It’s better to focus on a single output model and do that well.
We’ve also seen many recent games that are hybrids between classical parser and classical choice. Some combine geographical navigation and object manipulation with hyperlink input, and that’s an intriguing design space that I’m currently looking into. Whether that will result in new language features is unclear, and I hesitate to promise anything. But any new development will probably remain true to the notion of a fixed transcript, co-written by the game and the player, from beginning to end.
If you don’t mind me adding to this conversation real quick: I just wanted to throw out there the fact that I spent quite a bit of time implementing a real object based system in Twine with locations, a complex inventory system, default actions, object reactions to events on other objects that were present, etc. Basically attempting to implement a parser-style object world inside Twine.
You know what I learned from that experience? You literally couldn’t tell. From a player perspective, there was no difference between a complex functional object system and faking it via flags. The interface is just too limited. Since the author is the one providing all of the given actions, they’re also in control of what the player sees, and therefore can mimic an object world very easily without actually implementing one. This is the approach that I use now.
So basically what I’m saying is that using Dialog (or any other parser game) for a choice based system is like killing a fly with a bazooka. It’s needlessly overkill. If you don’t like Twine but want to make a choice based game, there are other alternatives that are quite decent. Twine is just the most popular (mostly because it’s the most popular, and as such is always recommended first, and so remains most popular). I think you should try exploring other hyperlink engines before trying to get Dialog (or Inform or whichever) to perform a role it’s not really intended to. I think the end result would be a bit lackluster as well because you’d also lose control of the HTML formatting that is one of the benefits of making a hyperlink game.
@lft That’s quite interesting. The importance of a fixed transcript didn’t occur to me, but it makes sense.
@tayruh Well put. I’m not sure my desiderata carried over, though. When it comes to replacing Twine, I’m not really interested in the Dialog standard library; that’s not really on my radar. Dialog is wonderfully put together in that regard, but the absence of a world model is not where I think Twine falls short.
I find myself having to articulate what I want to like about Twine, and the ways I feel it falls short. I want a language that provides two things:
ubiquity: i.e. the language is popular and stable, meaning I can quickly learn whether or not my concept is viable, whether bugs exist to prevent me from realizing a project, and what workarounds can be devised. I feel Twine offers this, if through its community rather than the language itself.
formal elegance: this is a bit of a cop-out, but essentially what I refer to is terseness, expressiveness, descriptive power, syntactic orthogonality, predictability, early catching of categories of error, etc. As I see it, Twine falls short on this metric to the point where I’m reluctant to even use it.
It comes back to my ADHD, I think. I can’t focus on a story when I know there’s something I’m failing to consider somewhere in the code, and every choice in Twine’s syntactic model down to its Javascript foundations seems built in support of uncertainty and caprice.
I understand Twee is recommended for this scenario, but that doesn’t sit right by me either: if you have a graphical paradigm, then that paradigm should be fully integrated into an effective workflow, supporting and supported by a purely textual representation. As far as I can tell, Twine rejects that. I don’t want to spend my energy focusing on scanning hundreds of passages in search of one single misspelled variable. I don’t want bugs to result in silent, deferred failure.
I’m fairly sure my issues could be mitigated through discipline and skill if I had a surfeit of active brainpower. I don’t. My ability to focus is decidedly limited, and I simply don’t want that energy to be spent on makework.
Something like Dialog is far more suited to my ideal workflow in that regard, and that’s why I would enjoy using it for choice-based games. Not due to its admittedly impressive world model.
Ah. Well, I can’t help you with the error catching bit. That’s one of the downsides of working with an interpreted language. The script doesn’t know its broken until it gets there. That’s more an issue with JS than Twine, but the end result is the same.
As for the “purely textual representation”, have you looked at the tweego compiler? That’s what I use when I mess with Twine. I don’t use the Twine IDE because, honestly, it’s not very good. But Twine in your favorite code editor and a command line compiler isn’t that bad.
Anyway, I’m not trying to defend Twine or push you to choose it. There’s a lot I dislike about Twine, which is why I went and made my own. But I’m not pushing that either. Just giving suggestions, I guess.
I appreciate that. And I may well give Tweego a try. But I have to quibble on the particulars.
I agree that Javascript is most likely a culprit. I don’t, however, consider my issue with variables and silent failure an artifact of an interpreted language. There’s nothing about that paradigm that requires misspelled assignments or checks to initialize new variables, for instance, nor anything that precludes user-defined data structures (even nested to arbitrary complexity) or tables of arbitrary complexity, or for that matter a compact, orthogonal representation.
That’s mostly an aside. I’m grateful for the advice, believe me. But that’s the reason why I find Dialog enticing in this regard.
Dialog can easily export to a C64 program, and just for this reason I prefer to use it instead of Twine. But my system (textallion) can export to Dialog and Twine, so it’s easy to use it as a preprocessor for any of those systems.
I think this is an overgeneralization. You may want to build a choice-based game with a lot of internal state and find that a rule-based programming model is the best way to do this. Either Dialog or Inform 7 would support this approach (in their rather different styles).
I’m not necessarily talking about a world model with objects and inventory and actions, which is what a parser-based IF system offers you. I’m talking about any complex internal logic.
Look at my game Bigger Than You Think, which is basically a choice-based game with optional one-word input. (Source code: Bigger Than You Think: Source Code .) This has a partial world model – there’s an inventory and rooms, but no use of actions. I used I7 rather than Twine because I7’s rule system was an obvious way to express what was going on. All the game logic is in the “perform rulebook”, and all the output text is in the “state-desc rulebook”.
Obviously I could have implemented this in Twine or raw Javascript with a bunch of flags. From the computer’s perspective, every program is “just a bunch of flags”. But different programming models offer leverage on different problems.
I understand what you mean with your simile, but there have been so many times in a parser game where it would be helpful to offer the player a menu for certain interactions (especially conversations) and times in choice-narratives where I’ve wished that there was an easy way to manage inventory and dropped items could stick in passages that could be tagged as locations.
You’re right that it probably makes less sense from a player perspective, but these types of hybridizations can make things easier from an author perspective. The I7 extension “Hybrid Choices” was a game-changer for me, and there are other menu type solutions that work great in different situations. AXMA has been the best solution for me since it offers a side-menu, and Sugarcube - as well as other choice frameworks - do similar things.
Can I just say how glad I am to have choice mode as an option in the standard library? I’m not actually working on choice-based games, but it’s a wonderful prototyping tool to help work out the overall structure of the very large parser-based epic I’ve been poking at for years.
