Interactive Fiction pet peeve:
#Twine, #interactivefiction, #gamewriting, #rpg
On itch.io, there are quite professionally presented Twine games that, by all accounts, strive to be *games* (RPGs, specifically), and not interactive experiences in the broader sense.
Essentially all of them have passages of text filling my entire screen, and sometimes more.
...why?
I am not reading a wall of text on a screen, I can promise them that--unless the writing gives actual novel a run for their money.
Interactive Fiction pet peeve:
Not to mention that Twine allows for significantly more variation in its presentation of choices or other interactive components than listing them at the bottom.
Obviously, huge amounts of writing didn't deter these authors, and neither did doing/comissioning art, taking care of layout, etc. A bit more knowledge of Twine's capabilities couldn't have been beyond them.
@Scriv I feel as though listing options at the bottom of the passage is so well established as a convention that there's little benefit in opting for anything else unless it does something more effectively for that specific game. The one time it bugs me is when those options essentially duplicate details listed in a very brief passage: that always feels redundant.
True, it is a convention, which is probably why it has been internalized by writers, especially if they're coming at it from a gamebook/Choices of Games perspective (as I suspect many are).
A counterpoint, though: hypertext is an even better established convention--in terms of how used we are to interacting with them--and you make a good point about choices designed/phrased in a certain way feeling redundant and tedious after very short passages.
Also, I quite enjoy the interplay of tagging certain words/phrases as interactable and the actual interaction they allow--which doesn't exclude adding choices below.
(Though that poses additional challenges, designing choices well and phrasing them compellingly/competently.)
I think that requires thinking about a game as a world where we provide "rules of motion" and the player can do ~anything allowed by those rules (and thus the rules need to work well _with each other_ in a way that is legible, because we can't exhaustively test all possible interactions), as opposed to one where a game is a choice between an easily enumerable number of paths that can be tested exhaustively. This approach not only affects tests, but also spills over to implementation: if someone has the former approach they're like to have their code grow in a similar fashion.
Obviously one can see some gradation of views inbetween. However, I think that one can place a clear(ish) demarcation line on "the outcome cannot be tested by enumeration of possible «distinct» playthroughs" (the main source of fuzziness is the notion of distinctness here).
Having actions modify the current "scene" is an example of a thing that requires the latter approach, because you would often have more than one such action and it soon gets infeasible to exhaustively verify their interactions. Similarly, doing that by e.g. octuplicating a scene gets very infeasible very quickly.
@robryk @DamonWakes
Yep, that's true, though steps could be taken to make things more manageable--and I was in any case approaching it from a "knowing the rules of engagement for writing interactive text specifically". After all, a passage + choices in the end doesn't require the author to know any of them, necessarily. Anyone can do it, even on paper.
My initial post was referencing the kind of interactive writing in which you can essentially do the same thing on paper. ->
And following from that, these texts--irrespective of how many people actually like engaging with them--were setting my sensibilities a-tingle by not looking for ways to conform and use the interactive environment in a more interesting way.
I do get your point re: being easier to test, but that only applies when a particular choice elicits a new branch in the story. Not everything needs to branch, and one can set a flag through any number of means, not just choices.
I don't know whether it's actually easier to test. It's just that it's easier to test if you have a mindset of "a computer can only follow simple rules, therefore rules that we give to it must be very exhaustive" (which ignores the possibility of creating rule interactions that have some properties by construction).
If you have this approach, you'll think that conditionally using pithy language to explain something (or just expanding explanation in-place) will obviously need another scene. For that reason you'll (a) avoid doing such things (b) do them badly when you do (which reinforces the mindset of "computers are stupid so we need to test everything").
I haven't personally seen people do that in IF contexts, but I've seen that failure mode when people learn programming.
_Especially_ when it's tech for writing things, because you need to understand how people read things, too. (This is another instance of the problem that appears when creating software for human users: it's hard to find a single person that both understands what would be useful and what is feasible, and that's ~essential because communicating either is very hard.)
And I think Twine has made things slightly worse in this regard, by showing a model which admits few simplifications-by-making-things-independent. Imagine trying to model liquids in Twine: you'd (IIRC; I never wrote in Twine, but read reference manual some time ago) have to basically have a variable for each pair of possible container and possible liquid (or possible fill level). The abstraction of "class of objects that happen to be able to hold liquids" is not available, and you cannot abstract away the knowledge of all possible liquids from each of those objects.
This makes it hard for people to realize that such abstractions are a useful thing in general, and IMO harder to notice abstractions that _can_ be expressed in Twine if you've never had experience with something that admits more of them.
Oh, it's quite possible, and I don't even think it needs directly writing new JS into it. I'm talking about Sugarcube here, specifically, which scales amazingly with an author's "technical" skill.
But it's true that the visual metaphor it uses heavily encourages functional fixedness.
@Scriv @DamonWakes Hmm... I can't find understandable reference documentation for SugarCube, so I might be wrong below.
All Twine stories I looked at (and I might be remembering very badly or conflating it partially with ink) implemented inventory by having a variable for each item "is the item held by player" and having a conditional part of inventory page dedicated to that item.
In that model adding a new item requires modifying inventory page and at least marginally modifying location pages of locations where the item can be dropped (I believed that this was the reason why dropping was rarely implemented).
This can probably be solved by using TwineScript and making some _single_ small modification to each location page. But, that basically means that the user has to discover how to do that, create all the abstractions ("each location has a list of items, each item has to be able to describe itself, should have a condition that describes whether it can be picked up, ..."), and implement them. This requires a lot more experience with designing things in a precision-oriented setup than using a system that provides some abstractions at this level.
I'm probably wrong about Twine in 20 ways in what I wrote above and would really appreciate corrections.
Here's the Sugarcube docs, they're quite comprehensive :))
@robryk @DamonWakes
Oh, and forgot to mention this wonderful extension to TwineScript by Chapel, a power user of some renown:
https://twinelab.net/simple-inventory//#/Guide
@Scriv @DamonWakes Yeah, this indirectly seems to confirm the way I see Twine's abstractions: the inventory keeps a list of things that are identified by a name and don't have any other properties. If you wanted to be able to hold a bag with its own contents, the backpack's inventory would need to be its own global variable, and couldn't be made a property of the backpack. If the game contained two bags, and the player could pick any subset of them, you'd need to have a separate global variable for each of them. If there was an unlimited number of bags available, you'd have to do something different that doesn't seem supported by that library.
I think the way I would describe what I find missing is that tool authors do not get tools to make what they create composable.
@Scriv @DamonWakes I've found that and found it somewhat confusing: all it says about TwineScript is that it's basically JS, but it also says that you can't have anything with a method in a story variable. If I treat that literally, it's somewhat badly defined, because ~everyobject in JS has methods that can be overridden. I think it wants to say "story variables will get serialized and deserialized and you'll get whatever comes out" but beats around the bush in a way that just makes it less clear. If that's true, it's sad, because it robs abstractions of their ability to appear simple :/
@robryk @DamonWakes Oh, it can definitely do it. You'd need to a couple of additional things compared to how you'd do it in pure JS (though you can actually use pure JS in SugarCube), but it's there:
https://www.motoslave.net/sugarcube/2/docs/#guide-tips-non-generic-object-types
Well, "The .toJSON() method needs to return a code string that when evaluated will return a clone of the instance." means that you essentially can't have methods (or rather, can't store any information in methods, because you need to be able to serialize all the information).
This is getting somewhat over my head now, haha. I mean, it certainly can use methods (created using JS syntax), and also create classes, because I've done it. As to what "information stored in methods" means... I'm now sort of lost. :))
And in any case, what Sugarcube allows already goes quite a bit beyond basic Twine and simply concatenating passages in boxes, which is what I was getting at.
Re "information stored in methods":
Consider a terribly silly example (there are probably tons of ways to do the same thing in some other way): you want to have objects, some of which sometimes can be waved by the player. A natural way to do this is to populate a field on the object "tryWave" with a function that (a) determines whether player's attempt to wave this object succeeds (b) provides text to describe what happens (c) modifies the state of the world accordingly (e.g. if this was a wand that creates frogs when waved, a frog should appear in the current scene). In particular (c) could _change this very field_: if the wand should only produce a frog once, then a totally reasonable way of dealing with that would be to change the value of this field to a function that doesn't produce frogs anymore. (Also, if you had a wand that could change that other wands are doing, then having a possibility to change that function becomes essential.)
This is not something you can really serialize in a toJSON method that works for all objects (or even one that works at all, if the "tryWave" function is changed on an object at runtime). There are some very cumbersome ways to try to circumvent that issue, but they (a) would fail mysteriously if executed incorrectly (b) require more knowledge of weird technicalities of JS from the author of that piece of fiction.
@robryk @DamonWakes Well, what I can say is that b) in particular already means that Twine or maybe any other tool for writers simply isn't what one should be looking for.
Ink, in particular, has as a core tenet that the writer should, for the most part, simply write, and is modeled explicitly away from the text being subservient to code, having to be quoted, made part of functions, etc.
@robryk The more code-heavy functions should be taken care of by code-cognizant people, so we're looking at a two-person job, in the end.
Sugarcube simply allows for both jobs to be done within the same environment, and ink can interface with different engines code-side.
@Scriv @DamonWakes Hm~ Yes, I can see that this approach makes sense. Though I'm sad that it moves everything away from simulating a world that the reader can amuse themselves by playing with the world _in ways that are emergent from the rules_ and not necessarily anticipated by the writer.
@robryk @DamonWakes It can be emulated well-enough, I think, taking into account the writing-first constrant, of course. @joningold, in particular has a number talks of how they tackled this for games like Sorcery! and Heaven's Vault (though I don't think it has one for Pendragon, where they made the most use of it, I believe).
Here's one:
https://www.youtube.com/watch?v=HZft_U4Fc-U
@robryk @DamonWakes
Maybe I misunderstood, but I was referencing authors working with tech as opposed to people creating the tech for authors to work with. In this case understanding how people read is also crucial, of course, but more from the POV of "how do I make them read on/how do I make the interaction engaging", specifically using the medium, and not because people just like to read epic fantasy romance in every medium the come across.
@Scriv @DamonWakes I also meant authors (but I would expect same to be true for people who make things that authors use). I didn't really think of "how people read" in terms of "how to be engaging" (though it's possibly even more important) but rather in terms of "how to present this mental image that I have with words, complicated by it not being a single mental image but a family of them".
@Scriv @DamonWakes The special issue that appears here in all its force is that you need two different kinds of creativity in the same person.
@robryk @DamonWakes It's what game writing/narrative design largely is, yes :))
@robryk @DamonWakes Welp. Yes, haha. Creative use of tech--even if it's tech for writing things--is hard. (Saying this from a position of someone who definitely finds it hard.)