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