robryk @robryk@qoto.org

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

@Scriv @DamonWakes

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.

@Scriv @DamonWakes

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

@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 :/

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

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

@Scriv @DamonWakes

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.

@Scriv @DamonWakes

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

@Scriv @DamonWakes

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.

@Scriv @DamonWakes

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.