Bad stuff. Unpopular choices. Terrible games. (In your opinions)

Ooh, drat, I missed a chance here.

You-the-programmer ask the player if they prefer light or dark mode, then you say “Well maybe you just haven’t tried the right light/dark mode scheme yet! Be open-minded!!!” and give the reverse.

(They CAN just go back and fix it by fibbing.)


This is truly awful and I hate it so much :joy:

Hey! there’s always next time! (maybe probably, it was so fun I want to do it again)


Oh yes, the meta-snarky “too clever for its own good” attitude.

(Yes, I know that’s kind of my brand…)

I’ve seen this work and be funny in certain games (like Temple of NO) but if it’s sincere and not tongue in cheek it’s just bad.

I’ve seen this in a game that gives a choice like “go to the castle” “go to the mountain” and since the mountain content isn’t written yet you get these annoying “Are you sure you don’t want to go to the castle?” Yes/No" and then if you resist it just says “You change your mind and go to the castle.”

Best practice: if you’re releasing a demo with missing content, either temporarily remove choices to unbuilt content, or clearly signpost the missing route out-of-world for the player instead of pretending the content is there and having your parser/author voice snark and make fun of the player for not making the “right” choice.

(This would have worked very well in my bad game; I also missed a trick!)


Bookmarked! Thank you! I’m colorblind and it sometimes causes me trouble in Twine games and I worry about doing the same to others as I know not all visual issues are the same as mine. This is a really useful resource I didn’t know existed. :heart:


Would an option to turn audio and images on/off at the beginning be adequate? Assuming, of course, that the game was written in a way to make the text standalone?


What’s funnier than it being only seconds long is the delayed realization that you’re also implying it to be a game. Which… fair enough.


That reminds me: I have a barely rational dislike for when large areas are modelled as multiple rooms. I feel like I’m going to miss out on some corner.
Clearly I can handle it as Counterfeit Monkey practically starts out with such an area (after the tutorial alley).


This is one thing I miss from AXMA 6 - the UI always contained sound controls. It didn’t adjust volume, but you could shut off sound for the entire game, and there was also a “mute” button which stopped any currently playing sounds if you needed to answer the telephone, but it resumed at the next sound cue in the game.

Unfortunately no built-in way to not display images. In almost all systems, including inline images in parser, it requires an authorial choice presented at the beginning “Do you want images?” and a variable that gets checked before the image to display or not display.

One other possible way to do this in choice is not have images display in the main prose-stream but ask the user if they want to see the picture in a choice that links to a separate passage with a “back” button.


Actually these things are supported at the interpreter level. Spatterlight has graphics and sound toggles in its prefs. Gargoyle has them, too, they’re in that horrible preference text file. I’m on a Mac so can’t check Glulxe/Wingit right now but I’m guessing they probably do, as the spec supports it.

It is excellent for each game to have its own options for AV media, but for games that don’t, or players who never want to see or hear yada, check your interpreter preferences/settings. There may be checkboxes.

…Of course, a game has to be able to tolerate not being able to support its own sound or graphics if they’re deactivated, or it could error or crash. The easiest ways of making sounds or graphics in Inform all have their own guardrails anyway, but we’re an amateur community, so any additional programming sanity/safety checks on this kind of thing aren’t second nature to most here.



Hey, I like that preferences text file. I wish Spatterlight has it too, I am never sure with GUI preference settings if something will work the way I intended it. :person_fencing:

1 Like

Good point. If you don’t want sound in a parser game, you can choose an interpreter that doesn’t support it! This has always been a push and pull for media and styling in parser games; part of the utility of a standalone interpreter is the player gets to set defaults and preferences that usually cannot be overridden by the author. @mathbrush brilliantly managed to work sound support into Bisquixe browser-based games. So it might be an audiophile situation: someone who just wants to play the game as presented can play instantly online and someone who wants full control and the ‘analog hiss’ of pure text will do the work to secure technology that gives them that control of the experience.


Also rule of thumb: Avoid using pure white or pure black for text. Even if you intend black on white or white on black, nudge them both toward gray just a bit.

Please do not support the war on contrast.

The most expensive and collectible books use the blackest inks on the whitest paper. E-Ink displays languages before the tech evolved enough to produce strong contrast (and higher resolutions). Paperbacks and newspapers are made to be disposable.

The WCAG 2.0 guidelines on the minimum contrast ratios well intentioned but entirely insufficient, and many designs apply them in contexts where even the guidelines say they don’t apply (like thin-stroked typefaces). (And many designers treat the minimum contrast ratios as targets.)

The rationale behind the contrast guidelines leans heavily on (1) older standards that were made for CRTs (often monochrome) and (2) research into minimal perceptual differences rather than readability.

The tools that check for compliance with WCAG do not measure the contrast ratios per the guidelines. (It’s complicated because the guidelines allude to a simpler scheme, and that’s what the compliance checking tools perform.) The result is that the tools often grossly overestimate the contrast ratios, making it seem like a design surpasses the requirements by a large margin when, in reality, they fail. The same goes with pre-made palettes of colors. The colors might meet or exceed the contrast guidelines, but there are more requirements to ensure that text rendered with those colors will do so.

We don’t have a good model for quantifying contrast that matches how people perceive it, especially with colors rather than shades of gray. (To the credit of the group that assembles the guidelines, they have an understanding of these limitations, and there’s a lot of work being done to improve subsequent versions of the guidelines.)

Even on “retina” displays, some form of antialiasing or subpixel rendering is still essential to approach the resolutions offered by consumer laser printers. When the contrast is reduced, there are fewer in-between shades available for antialiasing. As a result, even very dark gray text on a bright background often looks fuzzy, which increases the strain of certain muscles, slows reading speeds, and lowers comprehension. (But designers like it because it “looks better.”)

Lawyers also like to lower the contrast because fewer people will read the contract.

How much contrast someone needs depends a lot on the environment and the quality and calibration of their screen.

It’s true that there is a set of people with a very rare condition that makes full contrast text very hard to read. But nudging a bit toward gray isn’t enough for them. In most cases, those users need the contrast reduced below the minimum threshold that the majority requires. To accommodate everyone, you have to let the user choose what works for them.

Most people with standard vision who feel the text in a design has too much contrast are usually facing a different design problem, such as a poor choice of typeface, bad kerning and leading, insufficient negative space, overly long lines of text, etc.


Spot on!