Is there any good in-depth do's and dont's guide for IF?

[spankminister]

@Matt_W

but you didn’t include Ms. Short’s response to that criticism, which sort of undermines your point:

Sorry, I was unclear. My point was that while it is a fair criticism, phrasing it in terms of “IF-hater” or “accessible to new players” glosses over the fact that these same criticisms appear (albeit with different terminology like “world model” or “hinting”) from players who are not at all newcomers to the medium, but rather the exact opposite. In this case, the theoretical IF novice’s review is making the exact same observations as the most diligent and IF reviewer on the internet. Again, I don’t want to be a scold about “review quality,” considering the number of released games out there. Just wanted to point out that we as a community, fixate on relatively shallow implementation details, often to the exclusion of all else. We review point and click adventure without getting hung up on “this object looked kinda important in the art but had no custom description,” or an exploration game getting dinged on “I was able to run REALLY far, but eventually I hit an invisible wall.”

@emshort

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.

First off, there are certainly bugs in A Long Drink, and every single reviewer, yourself included, who said that it was scoped too big for the time allotted was 100% right, and I will never argue with that. It’s also very true that it’s really hard in IF to differentiate a bug from intentional behavior from a narrow implementation.

@Sequitur

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.

This is absolutely something I want to bring up, especially about parser IF. I’ve seen reviews for years where new IF entries are reflexively compared to the best in breed from decades of work. “Good atmosphere, but not Anchorhead. Good puzzle, but not Threediopolis. Good NPC, but not Galatea. Good prose, but not Coloratura.” What message do we send for parser IF if it is essentially not enough to tell a good story, but you must literally push the medium out of what it’s capable of, but also follow all the conventions of the established orthodoxy?

Authors now have a choice between Twine, where even short and sweet games get positive attention and buzz, and Parsers, where for your trouble, you can expect a list of verbs and nouns you forgot after months of work. I don’t want to place blame at the feet of reviewers here, just that “try and think of everything a player would” and “let some friends mess with it” is not a regimented approach to writing prose OR software, and if it works out for you, you’re pretty lucky.

@Sequitur

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.

This is at the core of the problem with the way IF is currently “sold” to authors, especially Inform 7. This has been brought up before, but “don’t be scared if you can’t program, just write!” is incredibly misleading around the fact that you are writing software, and you need ways to test software that are rigorous and systematic. Setting 20 people loose to play around in a game unstructured isn’t QA or unit testing, it’s a tiny closed beta. The best you’ll get is the few IF old hands who’ll try to break things, and that’s an adversarial test that might produce slightly more data.

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.

This is exactly what I’m talking about.

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.

I take issue with this mainly due to the stuff written above. DOOM wasn’t written with unit tests, but the field of game testing can’t be built assuming everyone codes as well as John Carmack. Put another way, as a rule, people don’t write good software, good systems produce good software.