Haha, listen, you guys don’t owe me an apology. Realistically speaking, you played my game, which is the most I could hope for, and getting a written review is icing on top of that. I tried to write this Twine in such a way that wouldn’t read as fishing for sympathy or “screw you, critics!!” I’d be lying if I said there was no cathartic element in it, but I just wanted to chronicle the feeling of the experience; juxtapose the hope with the reality, the input with the output. And of course, the dissonance between writing a 300-word Twine and getting high fives, and spending 3 months on a parser game that gets largely panned critically. It’s about expectations both on the part of the author and the players in both formats.
I set out to ask these questions, so I consider that rousing success. I mean, anyone who resolves to stay current with a competition, and write reviews about EACH entry is a rare breed in this day and age, so I feel bad holding the mirror up to you folks toiling away doing that kind of work. But for years, I’d noticed a big discrepancy in the way the community said it was clamoring for more parser IF, and the incredibly high standard any new game is held to. If I might unfairly pick on EmShort once more, from a Brass Lantern interview:
"Short: I’ve seen a few gaming forums with threads that went something like this:
IF-hater 1: Agh! Text adventures! They never understand what you type! You look at stuff and the game just keeps saying YOU CAN’T SEE THAT HERE."
There’s a lot of reviews of parser games by very experienced players that read just like that. And fair enough that things can get frustrating without hinting objects, but these days there really isn’t a lot of allowance for how complex setting up verbs and synonyms and all for parsers is. Or that there are design reasons for not doing so, or that the developer did, but the input still exceeded the included synonyms. Where’s the line between “I felt this noun/verb should have been implemented” and “why didn’t you read my mind?”
I dunno, the conciseness seemed to work in your favor, I thought it had good atmosphere considering its brevity. “The crypt is empty” is great economy of language to make things pretty spooky. [emote]:D[/emote]
Not trying to pick apart your argument – I think the exchange here has been very interesting – but you didn’t include Ms. Short’s response to that criticism, which sort of undermines your point:
In other words, it seems Ms. Short’s priorities are to make the genre more accessible to players first and developers second, and that the “first line of defense” for accessibility lies with the developer. I actually think the natural-language-seeming code that Inform 7 allows sort of tricks me into thinking that I can just write, and that traditional coding practices: syntax, user interface, robustness, unit testing, etc are either less important than with ‘normal’ coding or are taken care of for me. But, as my own so-far abortive attempts attest, it just ain’t so.
Twine actually does abstract these things away so that you can just focus on writing. I read a Porpentine interview where she said she spends only a week or two actually writing her big projects once they’re mapped out. (I think she was specifically talking about With Those We Love Alive in the interview.) No surprise that it’s way way easier to create a compelling 300-word Twine than a large and complex parser game.
…yeeeah, that must have been a fair few years ago now. I wouldn’t phrase it that way these days.
I’d be the first to acknowledge that writing parser IF is hard, and that the dull work of accommodating unreasonable input is a major time-sink for authors; this is one of the things I mention when I talk about why choice-based IF may be a better bet a lot of the time, both for accessibility and for authors who want to get things finished.
I try not to be an unreasonable hardass about this in reviews; but there comes a point where the implementation goes from “there are some missing elements but I can work around that” to “…I can’t figure out how to make the game move forward and I’m frequently uncertain whether I’ve gotten it into a buggy state, ie whether I’m wasting my time by even attempting to continue to play from this point,” which I fear is how I several times felt with A Long Drink. This made it hard for me to even reach other aspects of the game (what is the main storyline? where does this piece go thematically?) that I might have had reason to praise if I’d been able to get at them.
(My comments about “I felt like the author had an ambition that there wasn’t time for” were my attempt to acknowledge that this stuff is hard: not “this person didn’t work hard enough” but “this person asked more than was reasonable of themselves”. Perhaps it didn’t come across that way, but that was the intent.)
Anyway – I come to IF reviewing from a perspective that says critique is good, technical feedback is important, we’re all trying to improve our skills, and while reviews should be written with kindness, nonetheless it’s best to describe issues. That’s very much an old-school parser-IF community background. There are some other possible approaches, though, including the one that says: we’re all struggling to get things done, we should cheerlead and motivate, it’s important to listen and foster new voices, and responding to a first attempt with a barrage of negativity is likely to drive people away before they ever get around to improving their skills (if improvement is even something of interest to them).
A few years ago we did experiment with having a dedicated positive-feedback blog, and various people offered to contribute, and then fairly little was ever written for it. I think it’s safe to say it was an unsuccessful experiment. I’m not sure whether this reveals that (a) we are crotchety and this mode of reviewing does not come naturally; (b) there is not really a market for this, because people each individually want to hear themselves praised but in a context where, in general, negativity is permitted (otherwise it feels too condescending? that’s wholly possible, I don’t know).
Meanwhile, I as a critic am interested in having the conversations about technique and theme and meaning, and I also want to support the community and minimize the amount of distress I cause to individual authors. For some time now I’ve had a policy about reviewing that boils down roughly to:
It’s okay to critically review commercial work by established people (though try not to be a full-on jerk about it even so – there are obviously still humans behind a given project however large the team);
For amateur IF (and some fledgling indie-commercial) releases, unless the review would be net more positive than negative, it’s better not to publish one; no need to gratuitously rain on anyone’s parade;
2a. …except that people who enter comps probably more prefer to get feedback than not, so go ahead and be as thorough as time permits when reviewing a competition, while attempting to calibrate the feedback with where the author seems to be coming from.
But your remarks, and those of a few other people over the years, make me wonder if maybe the (2a) approach is wrong, and I should move towards a ‘nothing ill of the novice’ type policy throughout. From a bluntly selfish point of view, there are advantages to this: critiques of buggy games tend to be more similar than critiques of solid ones, hence less interesting to read or write, and focusing primarily on work I consider definitely strong would let me cover more out-of-comp and non-IF narrative games.
So I suspect that this change would increase the general appeal of my blog. It might also avoid doing the kind of community and emotional damage I do want to avoid.
That said, I’ve sometimes been told by novice authors that they really appreciated the critical feedback they received in this format. There’s clearly a need for – possibly non-public, ideally non-embarrassing – assistance to authors who are still getting started and who do specifically wish to focus on technical skill improvement. To some extent, beta-testers offer a first line on this, but maybe we need more/other institutions; recent experiments in comp format with private feedback or review-equals-positive-vote may be a step in that direction. It may just be that the time for us to do this via public reviews has passed. Or for me, anyhow.
To be honest, coming off a moderately complicated CYOA-style project, I think that for sufficiently long or complex twines this falls apart. If you’re doing a lot of state-tracking (For instance in what maga calls a “Branch and Bottleneck” story) there’s plenty of room to tangle yourself up in your own world model or introduce bugs. For Spring Thing, I’m releasing an 11000-word Undum project that uses that kind of structure, and towards the end I would have paid money for some kind of unit test system so I could ensure that my assumptions about the story were correct (And especially that it wasn’t possible to get stuck, cause a runtime error, etc). I’d be very curious about how the Inkle and Choice of Games authors handle this; was Creatures such as We just painstakingly tested by hand? Does ChoiceScript have some kind of testing harness system they use? I can’t imagine 80 Days was developed without unit testing, for instance - that thing is a quarter of a million words long.
Even then, though - in Undum, I can get away with manual testing and a good proofread or two. In a parser game, you can’t get away with that; the parser is a finicky, delicate machine, and worse, people’s attempts at interacting with the parser are unpredictable. You need extensive user testing to figure out what people expect so you can do it. Ultimately: IF parsers are not true “natural language parsers” (a Hard Problem that corporations have invested literally billions of dollars into solving, with mixed results at best) but rather an approximation that understands a simplistic dialect of English. Usability for those parsers relies heavily on knowing possible player inputs ahead of time and ensuring that those inputs can work, which in turn relies heavily on playtesting.
I can definitely think of a lot of improvements that could be made to I7 (Like an automated test runner more advanced than the Skein and the test command, for instance, would be great). But I can’t think of a way to make it hugely easier to write a good parser.
Ultimately, players have expectations built up over years of playing games that meet those expectations as a baseline. People expect to be able to refer to objects in room descriptions because that holds true often enough that when it doesn’t, it’s grating. Yeah, QA for a parser game is really, really surprisingly hard, but people keep consistently succeeding at it, so the bar is set at that point.
With regards to reviews, I think the best you can do is just try to recognise when a scoping error occurs and be kind about it. Maybe more comps should include a “back garden” for playable demos of unfinished work; there’s no shame in pushing back a release date on something, even if you miss a competition, so you can properly finish it and release it when it’s done.
I wasn’t trying to “save words” exactly. Roasted Misfits is a complicated tangle simply to make the structure more “exploratory” and maybe last for five minutes as opposed to 30 seconds. When I was returning to an-already visited page I consider it more revisiting a geographic room than a literal plot-cycle.
It’s only 111 words. I was using Twine’s word count feature and it was counting the code too, which I didn’t realize until I’d finished the game. Then I didn’t want to fatten back up what I’d been trimming down.
Could someone explain something to me, please? I’m following the submission feed, and I sometimes see that the author has added a .zip file. The game “RPG-ish”, for instance, has been updated in that way. I can’t see any way of downloading that zip file, though…
I guess. So that means that just because someone’s just uploaded a zip, doesn’t mean that zip it’ll be available for download unless the author specifically makes it so.
Had the daft idea of making my own font and then had the less-daft idea of writing a black metal track. Managed to form a marriage between the two ideas, and doing so was fantastically enjoyable (well, mostly).
And I did not realise twine was counting the coding either! Excised more than I needed too, perhaps.
Yeah, it seems to count the code included in passages. Other people might have cut down their text to meet Twine’s false word count too, because a few Twiny Jam entries (like Tomatoes) are noticeably slimmer than the rest.
But I think in my case it might’ve helped. I’m glad that you guys seem to enjoy creak, creak!
Since Porpentine encouraged people to use the word counter, I personally assumed that including code in the word count was the intention, and cut down to 300 with that in mind. (I also lost a whole lot of room because videos take up a whole lot of words.)