I hear you, but i think there definitely is a viable commercial market for iF.
The fundamental problem is what i call the “paradox of apps”;
The solution to this is to reduce the cost of making IF. Including time, of course. What you need is IF rapid development. Then you’re in business.
I’m sorry if I implied this. I’m just saying if someone threw out the equivalent of ZORK and charged $20 for it (without being a known writer somehow, like @zarf - or if Stephen King wanted to dabble in IF) they probably wouldn’t get much traffic based on screenshots.
The best example of how to feature text IF today in a monetizable form is something like THE HOUSE ABANDON where it’s very meta that you’re playing a text adventure on a screen in a haunted environment. (If you play that game, that parser is frankly awful - and I suspect is text-matching instead of doing advanced parser things. But it works in context of the story it’s telling.)
For reference, THE HOUSE ABANDON was the free demo for STORIES UNTOLD - part one of a four-part game which features graphical environments with text-adventure-ish puzzles.
I agree in principle, too. What can’t happen is commercializing IF as it currently goes into IFComp. We need to meet average gamers somewhere in the middle, which does mean more graphical effects and more intuitive interfaces. I even think modified parser games could be viable, provided there’s some attempt to make it more penetrable. What we don’t need to do is go all-out with graphics. Text effects and simple screen effects would do a lot. I think our role model here should be games like Device 6, which if you have not played, you should play. It’s commercial, it won an Apple Design award, and it was an amazing hybrid. I don’t know how well it did, but I think that’s the direction we should go, along with, as @pinkunz says, voice interface.
I’ve said it many times, but we should pick a game (my vote is DiBianca’s The Wand, for many reasons) and all throw our support (financial, technical, promotion) behind commercializing it, trying to find a balance between retaining the spirit of parser IF and making its interface accessible. Try a community experiment at commercializing something and see what happens.
I think the reason The Wand is potentially commercially viable is it could very well be translated to an app version with graphics. It has limited parser commands that reduce to move/look/wait/examine/use, which is about as complicated as you want to get for an exploratory adventure on a phone. What DiBianca is really good at is creating what would be a graphical puzzle or “Metroidvania-like” and expressing it in parser format using only what is necessary to comprehend the gameplay.
Genres declared dead live on.
Think of these examples:
Some years ago Fantasy was declared dead. But then there were the LotR movies, Harry Potter, game of Thrones.
Point and click adventures were declared dead. Then there was Harvey’s eyes (by Daedalic) and in the following lots of others.
IF was declared dead but never was. And there was the comeback in the 1990s.
So why should it be totally impossible to revive (and even excel) the commercial Infocom phase?
I agree with Amanda that occasional graphics help enormously. Or perhaps choice games for the smartphone would be a success?
My personal opinion on commerce or gratis: I would not try to forbid selling games; but I want to produce “libre” games. I don’t want to become a billionaire, though because of this some people think I’m an idiot.
Kindle has IF. I have Fabled Lands on Kindle. Good stuff.
I also have a StarWars Choice IF. Too many ads in it for me to recommend it.
CYOA Cave of Time is also on Kindle, but stay away! Links don’t works and paragraphs aren’t numbered!
The point is, if you can put it in epub/pdf format, Kindle will do it. If you need Javascript, then forget it. I don’t know any epub reader that can handle Javascript.
Right, you can certainly publish a book-formatted CYOA no problem as “interactive fiction” or potentially a gamebook, but if it’s not just “turn to page” or straight hypertext it’s not gonna work. (No state tracking, variables, etc.)
The original Inklewriter website had a process where they could make a story into an EPUB for Kindle, but had major restrictions. It couldn’t do loops or hubs because it would endlessly cycle trying to create pages for every possible choice and if the story looped in any way, it could never complete it as a straightforward hypertext.
Yes, i totally agree and thanks for the Device6 info, I’ll check it out.
Some things I’ve learnt along these lines;
When you offer choices and parser input, people (mostly) stop using the parser input. So what i do now is relegate text input for things that would otherwise become spoilers;
For example, to get into the secret club you must tell a password to the doorman. Or you might have to know a phone number to dial. People are ok with typing a bit now and again, but not all the time.
So there are good reasons to retain a bit of text input.
You can minimise choices by having words in the main text clickable. These clicks mostly perform x whatever, but sometimes they can do other things (not often).
Character dialogue is all via choices. This choice tree can be context sensitive in order to reduce the number of choices at any time. Some dialogue I mark as “background”, these act as “fillers”. Whenever the number of choices falls below 3 in conversation, a “filler” is padded (when available). This also gives the illusion of new things to talk about.
if you have pictures, then you should be able to click on items in the picture. Usually, this is in addition to clickable text.
Graphics can be made of layers. The simplest being background and foreground. In any case, you also need things to “disappear” from the pictures when you take things.
Also, things not very much needed in “New IF”;
Things you still need for basic world model;
Edit:
Also, might be relevant to post this chart;
Ten years ago I was hanging out online with a mid-list author who worked with a small publisher, pushing e-books on all the major distribution platforms at once. Giving away your first book while selling the rest of the series was earnestly recommended by marketing experts at the time. Writers didn’t make it up. And frankly? Seeing how my friend made good money for a while, maybe they knew something we don’t. Meanwhile, my one novel sold exactly ten copies since 2016, across two online stores (a third sold zero, and I had to pull it). My short story collection never sold one copy anywhere. Good thing I also keep them online for free by themselves, or no-one would read them.
As for games? My experience on itch.io, confirmed by other developers, is that you make more money with a pay-what-you-want scheme than if you have a set price. Ask yourself who wants to convince you that you’re somehow supposed to sell your work, and for a high price at that, to make it “valuable”.
I don’t understand why these aren’t needed. Doors and locks are rather fundamental in incremental exploration. Oh, you don’t call them doors and locks. You call them chasm, steep hill, tall wall, iron cast pan waving MIL, and so on.
Dropping things is associated with markers in a maze, but they also act as distractions, traps, and the likes. Maybe dropping some 
next to a weathered fence will cause a nocturnal 
to create a new opening? The door is weakened fence. The timed lock is + !
Darkness is overused, and used poorly, but what about fog, poisoned gas room, extreme cold, or underwater? Environmental hazard is still a thing, in addition to being indirect “doors” and “locks”.
I agree, although I will admit to rarely implementing doors anymore. I’ll mention a doorway “to the north,” and going north will include a text mention of the door being opened and then closed behind you, but, as far as the actual game is concerned, the door doesn’t really exist as a door per se. The rooms are simply adjacent and connected.
As for locks, I agree they’re overdone as a trope in and of themselves, but they’re fantastic for gating different sections of the game, which can help with creating a narrative pacing.
Yes. With ScottKit, I put locked door in the room, but once the door was unlocked and opened, I simply remove it. No need to close door any more than you need Bridge Troll to hang around after you pay the toll.
Really? I definitely see uses for doors…
Okay, THIS type of door we can do without…
You can see a stone door here.
>west
The stone door seems to be closed.
>open stone door
The stone door seems to be locked.
>unlock door with key
You unlock the stone door.
>west
The stone door seems to be closed.
>open stone door
You open the stone door.
>west
Include Locksmith by Emily Short and doors become easy to handle (when the player carries the corresponding key.)
You can see a stone door here.
>west
(first opening the stone door)
(first unlocking the stone door)
(with the key)
I love this game by Andrew Plotkin! A very creative use of “doors”.
>drop door
You place the west oak door on the west wall.
>west
(first opening the west oak door)
You walk through the west oak door.
I used doors in my game to simulate portals and other things; used creatively, doors certainly have their uses.
Near the west wall, a magical portal shimmers with eerie energy.
It stands as a rift between worlds, a shimmering tear in reality.
Its edges waver like heat rising from desert sands.
>west
You step confidently through the swirling portal,
feeling its energies wrap around you.
The magical portal that stood to the east gradually fades
from existence. Its vibrant hues of eerie light begin to wane,
like the dying embers of a fire.
You can see a stone door here.
>west
(first setting your phaser to maximum)
(first vaporizing the stone door)
Almost forgot about this one…
You can see a Self-Satisfied Door here.
>west
(the door automatically opens)
(the door automatically closes. “Hummmmmmmyummmmmmm ah!” it says)
Good point! This is one simple way to devise puzzles in choice. I’ve done this in RSPM where there were conversational menus that included a text input box, and certain keywords the player learns elsewhere can be typed in to create essentially an “invisible” wildcard choice.
TL;DR: in choice narratives, it’s often easier to narrate world-modeling mechanics than to actually build them.
In parser takeable and droppable objects are easy to do. In a choice narrative they require some wrangling. Taking an object sets a flag which isn’t hard, but unless you can use an inventory plugin, it’s quite difficult to set it up so objects are droppable anywhere and keep track of where they are. This is complicated by the fact that choice games use passages which might represent a room, but there are often transitional texts and you have to figure out how to manage when and where an object can be dropped and how to handle that. I’ve tried it in Alice Aforethought - there’s actually a mirror on wheels you can move between different rooms and a couple of objects you can move around. It involves remembering what passages are considered “rooms” and either disallowing inventory access or dropping anything during interstitial text, or allowing it and just knowing what room the player is in. Then each room must be set up to hold and display availability of however many moveable inventory objects there are. So a lot of times it’s just easier narratively to say “you have the key” and then not mention it again till the player gets to the door instead of simulating it extensively as an object. For the rare case of a choice narrative “twisty maze of passages all alike” - If someone makes a decent maze in choice, it’s easy enough to fudge trail marking by setting a $hasBread variable and narrating that the player is dropping pieces, so when the player solves the maze you set another flag and just skip “You follow your breadcrumb trail back through the maze, saving a lot of time and clicking…” Often mazes in choice can be metaphorical and not modeled physically.
Physical doors are rarely necessary in most narratives and they’re often eschewed in parser as well. You can easily narrate them and imply them to the player, but whether they’re physically open or closed rarely affects the plot unless it’s a locked door, which is easy enough to do in choice setting flags and offering a choice to “open” a door only if the player has accessed a key.
Light and dark modeling is similar; again this is somewhat rare in parser now. Without the world model if you want to simulate a dark room you just check a flag - if the player $hasMatch or $hasLantern or $hasCandle they can read the passage text, otherwise it’s varied to say ‘Too dark to see!’
Locks: See above. You set a an inventory flag $hasKey and the player has different options when they examine the chest to unlock it if they have the key or not if they don’t.
Of course these can be more complicated. If your game has a major puzzle mechanic about trying multiple keys, it’s easy enough to set flags $hasSilverKey $hasGoldKey $hasIronKey and say for a locked chest that might cause a trap if the wrong key is used offer choices based on what the player is holding, or potentially there could be a text-type in “Type the color/material name of the key you wish to try:”
Yaay!
Choice games for the smartphone are already a success. Several companies (notably Episode) make tens of millions apiece per year from their choice IF, accessible through the respective companies’ interface. However, these are a very specific format.
(I briefly considered going that route for Budacanta, at as an alternative route for mobile users who didn’t want to download a whole app - this was before Ren’Py had a released Web candidate - but chafed on a number of the limitations).
It seems i’ve opened a can of worms with the doors question;
the concept of a portal or doorway as a connection is fine, but traditionally “doors” are things that open and close. There is no point having these in general between locations. Sure, there are some reasons to have them, when it makes especially good sense to the story.
But really, there aren’t many stories where doors feature heavily as a component. Mostly doors are are just a game annoyance. Not only that, it takes effort to implement them, so why bother.
Ask yourself, when are doors interesting and entertaining? When they’re not, dump them from your game. Once you go increasingly choice-based, then doors, per se, aren’t needed except as extras in the text.
You don’t need to drop things, because you don’t have annoying inventory management any more. you might use things to do something, consume a thing or mix or apply it somewhere.
But drop it. on the floor. No need to any more and waste of time.
Dropping is one of those features that in practice is rarely used and thus fairly benevolent. It simply isn’t functionally used in most parser games that involve you vacuuming up anything not nailed down into your blackhole bag. With that said, it’s a bit of built in functionality that is mostly harmless. I’d have to look up how to disallow dropping things because it never struck me as pressing either way.
Indeed. I’m not advocating going to the trouble of disabling it. Lets say you were building a twine based world model. Just don’t bother with drop.
If it’s there already, leave it.