The Old Gods of IF have gone and they are never coming back, yet we wait.
7 Likes
A comfortable paragraph width for reading is not a physical dimension of the screen, but a restriction to 60-75 characters, regardless of font size rendered.
I agree with this. It’s easy to zoom in, but it’s always nice when Twine and web IF games have short passages in a large font, at least in my opinion.
4 Likes
Good typography is woefully undervalued in general! I’m sure I can come up with a more specific hot take tomorrow, but you’re spot-on about the excessive line lengths.
5 Likes
Hitchhiker’s Guide to the Galaxy the Movie is better than Hitchhiker’s Guide to the Galaxy the Game. Even having read the books before playing the game, the game is just impenetrable even by Infocom standards. Game’s older than me, but if it truly is the most commercially successful of Infocom’s library, I’m willing to bet its sales figures were inflated by fans of the franchise picking it up, unaware of what they were getting themselves into coupled with no Internet to warn them against it and lack of decades of low quality licensed games to make people wary.
3 Likes
I don’t know the answer to this, but I remember a very confusing conversation with my sister (who works in PR) about this topic a few years ago. I mentioned something about coding, and she stared at me in surprise and said “… you can code?”
I stared back in confusion and, after a pause, reminded her that I have a degree in computer science.
After a bit more confused staring at each other, it turned out that in the PR field (at least within the circles she was operating in), “coding” means web design, not programming.
Moral: it’s really hard to get people to agree on what words mean. But that’s very much the opposite of a hot take, so I think I’ve missed the point of this thread.
8 Likes
My actual hot take: the existence of multiple story formats is a disaster for getting people into Twine. Several times I’ve gotten curious to learn more about how to make stuff in Twine, started looking stuff up, and then got bogged down in analysis paralysis about whether I’m learning the right format or whether in a few months I’m going to regret wasting my time and find myself throwing everything I’ve learned away to pick a different format instead.
18 Likes
This.
The point here is that people now go full lengths to provide a smoother experience to players while we didn’t do the same for programming languages. The power of Inform7 (apart from the language itself, that made me make a complete game first time ever after 30 years of trying) is per example the recipes, and the fact you can find sections and examples on the right side of the screen.
Also, “real coders” tend to be extremely jargonesque when asked about anything. Two examples:
- how do I set the flag of X?
- It’s in the DM (inform6)
You don’t say? It’s a 400 pages book.
Or, which is even more splendid:
- I need to set a 10 digits code for a door…
- Why don’t you use an array?
Ah ok. I need to discombobulate the gostak. Cool.
(No harm intended for coders, I still enjoy the help—but when trying to finish a game I want the game finished, not to REALLY learn about coding)
3 Likes
I think this really gets at the heart of why Photopia has the reception that it does – it tried to do a thing that was novel and interesting, and this intrigued people enough that now there’s 20+ years of games iterating on what it did! So if someone played any of those first it’s no surprise that they might find Photopia underwhelming relative to its reputation.
My unpopular opinion is that this also applies to a lot of the early breakout Twine games despite not being all that old relative to other IF classics. Queers in Love at the End of the World is one in particular where I can see why it was groundbreaking at the time and why it’s considered a classic, but it still left me pretty whelmed when I actually played it. Some things are just too influential for their own good!
10 Likes
100%. When Twine first appeared, simplicity and ease of use were its main attractions, coupled with the ability to modify the player interface in an infinite number of ways. Now I just find it… confusing. As a beginner I wouldn’t know where to start. But here’s my hot take: the big problem with Twine is the node graph.
I loved Twine when I first discovered it, and I’ve published two Twine games, one medium-sized and one massive. The node-graph was its chief selling point. My first Twine game was adapted from a huge pen-and-paper choice-based game I’d been writing since childhood, and it was fun to see what it actually looked like as a branching story. But the node graph is precisely I won’t use it again. Every single piece of content in a game requires a new node, meaning that the map became very unwieldy, and even my fast, VFX-optimised computer lags when I try to scroll around it.
I’m rewriting that game, for the umpteenth time, in ChoiceScript, which is a much better fit. ChoiceScript is a dream to use, especially when using the unofficial IDE CSIDE. But the inability to change the user interface is limiting. Every ChoiceScript game looks exactly the same.
So I’ve been learning Ink, which in my opinion is the Rolls Royce of choice-based systems. @HanonO once described it to me in an email as “ChoiceScript on steroids.” It’s not as easy to use as ChoiceScript, but the possibilities it offers make me giddy. I’m not sure why it isn’t more popular with authors who use this forum, but perhaps it’s because the learning curve is that bit steeper.
Ink’s co-creator, Jon Ingold explains much better than me why a node graph or flow chart isn’t the best way to think about choice-based IF. These quotes come from Jon’s posts on the Ink Discord server:
I don’t see the flow chart as a selling point for writers who are comfortable with interactivity and branching, since it’s over-simplified. I see it as more of a crutch.
So the line I usually use when trying to explain the point is - a flow diagram is a picture, and picture tells a thousand words - but give a writer a thousand words and they can give you a hundred pictures, and that’s what ink is like.
The format we write in matters. The limit on what a interactive writer can do isn’t down to the computer can handle - computers are fine. It’s down to what the writer can express, and manipulate. And any visual representation becomes a big mess super fast - the simplest weave looks like a massive tangle.
14 Likes
Oh, man.
So much has been said here that explains exactly why I’ve spent years as the kid in lunge stance bobbing in time next to the whirling double dutch ropes of “writing interactive fiction” instead of jumping in…
—
Twine (anxiety)
Accessible, as long as you embrace the fact that “vanilla Twine” is actually Neapolitan, and every tutorial stresses the importance of choosing your starting flavor wisely, because there’s no going back. Oh, and each of those flavors has completely separate documentation.
ChoiceScript (ease)
It took landing a contract with Choice of Games to finally shift me from moodling to writing, because “Oh, god, I signed something promising I would!” and also because ChoiceScript was so quick and easy for me to learn. It plays to my strengths as a writer rather than my weaknesses as a coder/programmer. It’s admittedly limited, but it does what it does really, really well, and I’m having a lot of fun with it. (I also have to shout out @Sargent’s mind-blowingly helpful ChoiceScript extension for VS Code. I’m so lucky to have discovered it at the start of my project, because it gives so many leg-ups to the writing process. Thankyouthankyouthankyou.)
Inform (it's complicated)
I first tried learning Inform several years ago. All I remember is that it felt like trying to look at the sun—a lot of squinting.
This week I’ve finally begun to learn Inform in earnest, and I now understand why I bounced off it that first time. I’ll say it’s great for me as a writer, because computery code like TADS, with all its lines of little floating brackets and word fragments, makes it feel like “a lot of typing and wasted space on the page,” whereas Inform’s code is concise, compact, and legible enough for me to gain helpful context without having to scroll through lines upon lines of brackets and blank space. Plus, after just a little reading in the documentation I can easily look at the Inform source code of another game and somewhat get what it’s doing.
It also doesn’t hurt that 99% of the time, Inform code reads like surrealist poetry. That’s irrelevant to its helpfulness and abilities as a programming language, but… bonus points.
Oh, and the fact that Inform generates an in-IDE map of the game, complete with color-coded regions, doors, objects, etc.? Just incredible. So, so, so good.
The IDE itself is well-designed, easy to navigate. Great.
H O W E V E R…
Using the documentation to learn Inform feels like asking a friend to teach you how to play Twilight Imperium, and they proceed by opening the box and reading aloud some of the cards.
The clearest evidence of this is my recent post in this very forum expressing confusion about not being able to “>exit [noun]” in my game. How did I miss this fact in the documentation? Well, because it’s probably buried inside an obtuse example somewhere in the middle. And even more hilarious, the simplest fix to this issue is an extension that’s literally called “Small Kindnesses.” Very telling.
Hey, Inform:
>exit wet paper bag
Whenever I want to do something, the documentation gives me an example that’s one line of code doing kind of what I’m trying to do, but I notice that the first word in the line isn’t capitalized, and I know enough to understand that means it has to come after something else, but nowhere (as far as I can tell) is there a list of the possible starting bits for those rules. They’re just peppered throughout the documentation’s examples and the IDE’s Phrases tab (mixed with other bits, which makes it unclear what goes at the start versus the middle).
Almost every time I add something new to my game, I grind my gears trying to synonym my way into something that Inform will understand—hilariously on-brand, the dev equivalent of “find the verb.” I know this will change with experience, but for something as persnickety as a programming language, learning by trial and error is tiresome, to put it lightly.
The documentation’s lesson on lists is a great example of this. Its explanation uses the low-hanging fruit of demonstrating a “list of numbers.” Okay, but I could’ve guessed that numbers are an easy thing to list. But when I try to make a “list of [literally anything else, even adhering to Inform-specific nomenclature],” I’m zapped right back to my first day learning to drive stick shift.
I have since solved this problem, no thanks to the documentation’s lack of a precise list of things I could make a list of, but thanks to helpful Inform-er (Inform-ant?) Ryan Veeder!
To use another metaphor, Inform’s documentation is like someone teaching you to make a sandwich by telling you, “You could use mustard,” or, “You could use bologna.” OKAY, I’M EXCITED, BUT HOW DO I BUILD A SANDWICH?!
The Index tab is helpful for seeking out possibilities, but it’s basically a cornucopia of “sandwich ingredients” that still doesn’t tell you things like: “A slice of bread goes above and below the rest of the ingredients. Here are the possible breads…”
I think I’m most frustrated by the fact that Inform feels infinite—and it is! In many ways, it’s like the Dwarf Fortress of programming languages—but of course the language itself isn’t infinite, because all its machinery must use certain words and syntax that were carefully chosen to avoid jamming up the works. “Kind” feels like a weirdly vague choice for a label, until I remember that “type” is also a verb, which could stall the engine in certain cases. Maybe that’s not the reason “kind” was chosen, but it’s the one that makes the most sense to me, and it’s the one that helps me ignore other defiantly inconvenient choices like “otherwise” instead of “else.” I now know I can use the two interchangeably (another one Ryan Veeder clarified for me, long before I reached the point buried in the documentation that says, “Oh, by the way, ‘else’ works too”). And I heard Nelson took some arm-twisting to make that possible. Silly.
—
This is way too long, and I don’t know if any of it counts as a “hot take,” but some of what people have said in here has been an ipecac for me, triggering several years of pent-up excitement and frustration about wanting to participate in a community full of inspiring, helpful, and endlessly imaginative people making captivating experiences with tools that feel like medical equipment designed by David Cronenberg.
16 Likes
Absolutely! When I applied to write for Choice of Games, I started learning Ink as a warm-up to ChoiceScript. I definitely didn’t master Ink, but it dipped my to into the markdown style. Another selling point of Ink is literally a “selling point,” since it’s non-proprietary.
I, too, am surprised there isn’t more conversation about Ink and ChoiceScript in these circles. I thought I’d be lost without a node map, but it’s so much faster to write in CS than adding and typing in tons of little separate boxes in Twine (the contents of which you can’t really see unless you open them!).
I do plan to go back to learning Ink after I’ve finished my big CS game.
7 Likes
If I can’t play it on my phone, I’m probably not going to play it.
3 Likes
Well, ChoiceScript has its own forum, so writers from here tend to go over there if they have questions. As a CS author you’ll have been there. Ink has a Discord server, which is much less useful. It took me half an hour to find the quotes from Jon in my post above because the whole thing is one long conversation. There is some Ink discussion here, but not nearly as much as there is discussion about Twine.
5 Likes
Inform’s documentation is its biggest problem. It’s comprehensive and full of great examples, but it can be very hard to find what you’re looking for unless you know what it’s called. In my first game I can remember wanting to change the story headline, the descriptive line of text that appears underneath the title when the game begins. But I didn’t know that it was called the story headline, and there’s no chapter in the documentation that deals with this. I eventually worked it out because some of the examples, including “The Über-complète clavier” and “Y ask Y?” have custom story headlines. So I found the answer whilst looking for something else entirely. And that certainly wasn’t the only time this happened.
5 Likes
(Reposting, because the original didn’t show up as a reply for some reason.)
SAME!
One of my favorite parts of parser games are the “cold opens” and seeing when the “title card” drops!
Of course I wanted to do the same in mine. So yeah, I had to rack my brain for games I remembered having such opening lines, and searched IFDB for “source available” so I could figure it out.
Ridiculous.
It’s funny how in a programming language whose use includes adding synonym after synonym to account for all possible applicable phrasing, searching the documentation is like:
search “if then statement”
irrelevant results.
search “conditional phrase”
no results.
etc.
2 weeks later, accidentally happen upon the answer inside the “‘Flibbertygip rides the bus’ example.”
3 Likes
Can you explain more so what you mean? Prince Quisborne was written entirely on Mac. The only thing I’m aware that Mac lacks compared to Windows is the debugger, but I did not feel the lack of it with various debugging strategies available. Or say that in some cases a debugger would have made certain problems a certain degree easier to troubleshoot… that’s quite a bit different from it being prohibitive to develop TADS3 on Mac!
But I’d be interested to hear your experiences.
4 Likes
It’s a minor gripe really. I’ve had almost twenty years of fun making games with Inform 7, completely for free, so I’ve no right to complain. But it’s a shame if it puts off potential new users. Perhaps a properly trained AI would help?
Man, it undid the “reply” bit of my post again. Weird.
Yeah, it’s just the elusive art of “how to teach a board game.” If the Inform documentation were better organized, I could be playing already.
The actual construction of Inform source code is pretty intuitive and beautiful. But that’s only after you’ve internalized the very specific word choice and syntax it’ll understand.
My goal is learn Inform, not play solitaire Zendo.
2 Likes
Heck, just a couple days ago Jimmy Maher wrote a roundup of the standout IF of 1998, and of half a dozen games, some acknowledged classics, some mostly forgotten, Photopia is the only one that came in for anything other than the mildest criticism.
Interesting, I wasn’t aware of that post. I will admit, however, that I’m hopelessly addicted to Jimmy’s blog and many like it, even the non IF stuff as it fills me in on games I would never be able to play myself. I’ve even considered doing my own IF blog, but these days it seems like damn near everything’s been said, and everyone’s either blogging or writing about IF, so…
As for your own hot take, Mike, I have to say I agree completely. For example, let’s take the classic game Planetfall, and the death of Floyd. If Planetfall was a modern (or renaissance era) piece of short IF, do you honestly think people would cry over the death of a robot non-player character that you’ve only known for a few hours? I doubt it.
1 Like
About Inform 7, I find it to be a “read only” language (like AppleScript) in the sense that programs are very self-explanatory when reading them. When writing, though, there’s an apparent sense of freedom, but once you start building something you find it has very strict rules underneath, and it can be painful. Many times I have fallen into despair after getting a ‘Laurel’ is ‘Hardy’ error message.
Most programming languages are “read-write” (I find Twine the most user-friendly IF dev tool overall), while “write-only” is reserved for the likes of Perl.
7 Likes