New Interactive Fiction web player

Hello! Today I want to show you my humble project.


New modern and colorfull Interactive Fiction web player powered by new cheap GlkOte implementation.

Full story:

Some time ago, I finished my first TADS3 game and was discouraged by the unability to host it online.

Yes, TADS3 provides webhost, but the need to maintain a separate server on the network was frustrating and feels overingenering.

If something does not exist, then you need to create it!

After a short research, I found Emglken, which is declarated as a solution compatible with implementations of the GlkOte standard and even provides an example of an implementation of this standard for creating a console NodeJS application.

The de-facto standard for creating browser-based interpreters is now GlkOte from @zarf.
A great and very glorious project!

The main disadvantage of this great project is the deep integration of old-school web technologies (mainly jQuery), which prevents the integration of GlkOte and modern reactive frameworks for building interfaces.

I think that it would be cool to separate the implementation of the GlkOte standard and the implementation of the player interface.
So on the model of the cheapglk I created the cheap-glkote. This library provides abstract interfaces that can be used to interact with the Glk API in both the browser and NodeJS.

This library made it easy to create a new web player for text-only games with beautiful typography and support for different UI color schemes, which is equally usable on desktop computers and mobile devices.

The new player supports running both local games and games hosted in the web (on, for example).
All formats that are available to run through Emglken are supported.
The tutorial and several popular games are available directly from the player interface.
In addition, you can save the game state in the browser LocalStorage.

I’d appreciate any feedback =)
You can play your favorite games, read the code in the repository, or create an issue if you encounter any difficulties. Also PR are welcome!


Wow, this is really nice. Well done!

1 Like

Nice work! And I’m really happy to see that you could just drop in the Emglken interpreters.


@Dannii Thank you for this great project!
I had almost flawless developer experience =)


I like the straight clean look.

1 Like

Wow, that’s really nice! I appreciate the inclusion of solarized themes. :grinning:

1 Like

Looks great! And the interface is clear and easy to use.

For a layperson like me who’s lost in a sea of Nodes and Glks, would you mind explaining in simple terms how your player is different from previous web IF players? What can yours do that the others can’t?

1 Like

@ahope1 It would be wrong to say that my version is better than all the previous ones =)
This player only supports pure text games and does not support images, timers, or other interesting features.

Roughly speaking, this version is a technical demonstration of using a different approach to developing an interface for IF VMs.

I split communications with the IF engine and UI creation into independent parts and extracted the complex stuff into a new external library. IMHO this separation significantly reduced the complexity and increased the flexibility of development compared to the ancestors.

Of course, I re-use some parts of the great GlkOte library from @zarf, but I tried to build a simpler and more extensible version of the standard implementation that can be conveniently used with modern frontend frameworks like React of Vue.JS

I filed a bug that the status bar is missing.

IMO the core features you could offer in this context (without just playing catchup on features like images, timers, sound effects, etc.) would be top-notch mobile support and screen reader support.

On iPhone, the experience of playing Counterfeit Monkey in your player is pretty rough. There’s no blinking cursor or on-screen keyboard by default. You kinda just have to know that you need to tap on the line at the bottom of the screen (which doesn’t even have a border on mobile, unlike the desktop version, and I’m not sure why); when you do click there, the “visual viewport” of the screen gets smaller, but the game itself doesn’t seem to realize that.

So, for example, when you try to play Counterfeit Monkey, you have to click on the > at the bottom of the screen (and not on the >>) and when you do, you can’t read the question. When you type yes, the game asks another question, but you can’t see that question, either.

The next problem is screen reader support. I’ve ranted about this before, but the traditional IF UI is extremely unusual on the web; it’s a commonplace stdio application, but stdio is totally unheard of on the web.

Consider this bog standard IF transcript:

At End Of Road
You are standing at the end of a road before a small brick building.
Around you is a forest. A small stream flows out of the building
and down a gully.

# east

Inside Building
You are inside a building, a well house for a large spring.

There are some keys on the ground here.

There is tasty food here.

There is a shiny brass lamp nearby.

There is an empty bottle here.

> examine lamp
It is a shiny brass lamp. It is not currently lit.

> get lamp

The feeling of play is conversational. You might imagine that the game is playing the role of a Dungeon Master in Dungeons and Dragons, where the player and game are taking turns speaking.

If I were coding a “conversational” game today, I’d probably take examples from chat-based apps like Slack, where there’s a fixed input box at the bottom of the screen, and a transcript of messages in the main part of the window.

But that is not at all how IF games work (not how they have ever worked historically). Instead of having a separate “input box” into which you type commands, there’s just one main window area, the “transcript.” The game prints messages into the transcript, then prints a prompt symbol (the > symbol) and lets the user type directly into the transcript.

To extend my D&D metaphor, you might imagine the Dungeon Master writing something on a piece of paper, then handing that same piece of paper over to the player, who would write something at the bottom and then hand the paper back to the Dungeon Master, taking turns writing on the page.

This can be confusing to screen readers. One single rectangle is acting as both output and input. This is totally busted in Parchment today; it constantly reads and re-reads the transcript from the top of the screen. :frowning:

But the bigger problem has to do with the “focus” of the screen reader.

When it’s time for the user to type in Parchment, the last line is an invisible input box, where the user types. When the user hits enter, the input box is removed and replaced with text that the user typed. Then the game says some response message, and finally a new invisible input box appears at the bottom of the screen.

Removing the currently focused UI element is very bad for screen readers. The screen reader software tries to guess where to focus next. It might try to focus the user on the top of the document (the very first line at the very beginning of the game), or it might focus on the top of the screen (probably a random moment a few turns back).

We can try to focus on the new input box, but focusing that box may interrupt the live ARIA reading of the game’s message.

An obvious thing to do here would be to abandon the idea that the user should type directly into the transcript, and instead offer the user a fixed box to type in, at the bottom of the screen. That would probably work, but it would break some existing games.

For example, a number of games like to provide the user with a custom prompt inline with the text. "Please enter the secret code: " That may not make sense when the input box appears at the bottom of the screen.

A few games even rely on the fact that the prompt is in the transcript to play games with the player. For example, “Taco Fiction” prints a fake prompt “>” into the transcript and then waits for the player to type any key. No matter what the user types, the game inserts a character of the author’s choosing, “forcing” players to type what the author wants them to type, letter by letter. I guess it’s more of a practical joke than a serious UI consideration, but needless to say that joke would not work with a fully separate input box.

(And what about menus? Try typing help in Counterfeit Monkey or Lost Pig. On desktop, it’s acceptable but burdensome to select menu items with N and P, and press Q to exit the menu. On mobile, it’s basically unusable.)


The absence of the status bar is a conscious and fundamental design choice here: it’s a web version of a cheapglk interface where an input stream and an output stream are the only i/o and there’s no ability to put text in a particular place.

Sounds to me like @He4eT is playing a longer game where stripping running games in the browser with an emglken/remglk back-end down to its minimum was an initial step toward building the foundation on which something more like glkote could be rebuilt. The working demo was so slick, though, that it makes it easy to take it as an end unto itself!

1 Like

It’d be worth considering changing the recommended games from the top 50 to a curated list that is fine to not have a status window.


Thank you! I couldn’t have said it better myself.

Looks like I’ll have to play a lot of games =)

Yes, a curated list is a decent solution here, but I haven’t played all of the Top 50 games =)
I have not yet found a good list on the internet or suitable criteria for filtering IMDB. Can you or someone else point me?

If you are looking for “Good parser games that do not need a status bar”, you could create an IFDB poll for it. I don’t think there is a way to filter IFDB for status bar requirements at the moment.


Thank you for this detailed reply and yours github-issues!

The status bar and menus

Personaly I like an abstract idea of Interactive Fiction. I like the simplicity and CLI-like nature of parser games. So the status bar and modal windows seem like an unnecessary complication to me.

The lack of the status bar and some menus have a common cause. The reason is the support of a single window for text output. The status bar and the menus with a selection of options are separate windows. Separated windows are supported by my gheap-glkote library, but they are not yet implemented in the player interface, as @zed correctly guessed. I will try to fix menu problems soon.

My bigest mistake here is an automaticaly generated list, thats looks like curated and tested =) I will remove unsupported titles and try to add another examples of pure parser games, as @Dannii recommend.

Mobile devices

I apologize for your terrible experience, but only iOS devices are affected by these problems (I mean the lack of autofocus, the inability to switch to full-screen mode, and the incorrect calculation of the size of the viewport).
Unfortunately, Apple Inc. has its own point of view on some web standards =)
I will try to unify the UX for both major mobile platforms, but I definitely need some other developer’s help.

which doesn’t even have a border on mobile, unlike the desktop version, and I’m not sure why

IMO borders look redundant on small screens when you don’t need to visually enclose and restrict the text block on the page.

Screen readers

I don’t have any notable experience with screen readers, but I thought the slack-like layout should work well here:

  • the input field is always focused;
  • screen readers works good with extracting of updates from text blocks like the main output box in my player (please correct me if I wrong);

So this layout looks fresh and provides a nice CLI-like experience. Yes, unfortunately, this approach spoils some games, but I think we need a more flexible approach for the interfaces, and IMHO games should rely less on a paper-like experience =)
Please, point me if I wrong.

Thank you again for such a detailed reply, which turned out to be a good workout for my non-native English =)

What about HELP menus for IF newbies? I suppose some people don’t need them, anyone who does need them presumably also needs the status bar so they can figure out how to operate the menus.

I skimmed the IFDB Top 20 and thought about it; I can only think of two games in the top 20 that don’t use HELP menus and don’t convey essential information in the status bar: Spider and Web, and Eat Me.

I think it’s “wishful thinking” to say that the status bar is unnecessary. It wasn’t necessary for authors to rely on the status bar—we could have all designed games without using the status bar for the last 25 years—but given that the top-rated games usually do rely on the status bar, it seems odd to say that your IF Player doesn’t need to support it.

Similarly, we can say “oh, I wish IF games didn’t rely on combining input and output in a single rectangle,” but the fact is, they do.

I’m definitely not trying to argue with you =)
Of course, I will have to implement support for the status bar and multi-window mode.

Now I have the lightweight player of my dreams, which is good enough to use with some games. I just wanted to share the joy and show the community the first significant step on a big path.

Thank you for your concern, I will do everything possible to fully support as many games as possible.