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.
@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.)
_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.
