Viability of Ascii Art

Hey everyone! I took a little break from learning Inform and working on my game to do tabletop writing and design for a few months. Now that I’m coming back as a break from THAT, though, I realized it might be worth asking everyone a little question I had about Ascii art.

I’ve found this thread while beginning to ask this question (and immediately bookmarked it!), but I had a few semi-unrelated concerns of my own. Namely… how viable is Ascii art in Inform overall? I’m glad to see there are quick and easy settings for monospaced stuff, but I was also wondering about window resizing and such when the game is actually exported. It’s been a good long while since I’ve properly played an Inform game, and never Inform 7 in particular.

If someone makes the window small, is there a horizontal scrollbar or do all of the linebreaks come earlier and destroy the cohesion? I remember being able to force the scroll bar to always be visible even when there was nothing to scroll to stop my text from… jiggling itself out of place every time a clickthrough added more text and caused the scrollbar to appear. I guess there’s probably nothing like that here, though.

Is, say, 126 characters-wide too much to be viable? 145, which I think is the widest of any of the art I’ve already made in my spare time for the upcoming project?

I know you can add actual images. Worst case scenario I have a workaround to this problem. But, as you may have guessed, I’d ideally enjoy getting to actually put the Ascii art as I’ve created it raw into the game (even if an image of Ascii art would still be better than nothing or a regular image). Also, does anyone have any similar advice in mind off the top of their heads?

Anyways, hope this question is alright and it feels great to be coming back to this. In the meantime, enjoy the newest bit I worked on: ASCIIly! I realized I was talking so much about art that was entirely in the theoretical so I figured it might be nice to share something. She was a fun treat to work on for some good friends… but the sheer difficulty I had in finding a place willing to let me see how she looked in dark mode without distorting her did get me kind of worried. Hence this thread, ehe.

Edit: Side note, but I imagine this is a question that may have varying answers based on different interpreter programs. I suppose they’re still worthwhile questions to ask in a general sense, though!!! Especially if it results in learning which ones are particularly decent choices.

1 Like

I made a game (The Lonely Troll) with pretty big ASCII art, and I turned them into images rather than typing them directly into the game. This meant that character and line spacing would not be a problem, but the trade-off is that it’s pretty obvious that they’re images if the interpreter background isn’t white. Another good thing about doing it this way is that you can use colored text in your ASCII.

I did another game with much smaller, simple ASCII images (Of Their Shadows Deep), and had people using all kinds of interpreters test it, and although they did get a little fatter or skinnier, they were still OK in the interpreters tested.

So I’d say that if your art is big and wide, turn them into images, but if they’re narrower and smaller, keep them in-game.

I’m interested to know what you end up doing, so let us know!


The game has no control over how wide of a window it’s given. You can test how much space the interpreter has given you, and alert the player if it’s too little, which is what Labyrinthine Library does. But apart from that you’re at the interpreter’s mercy.

You can also specify how much space should be given to a certain window (the status bar on Z-machine, any window on Glulx), but if the interpreter doesn’t give the game as a whole enough space to accommodate that, again you’re out of luck.

1 Like

Mm, I was worried that was how it might have to go. Not that I didn’t expect the possibility at least, as you can tell. I guess that’s just how it goes when you use the “story file and interpreter” system that Inform does, but I probably shouldn’t be too torn up about it. Since I think Steam and Itch and stuff basically need to be bundled with an interpreter anyways, that might also change things down the road if I decide to toy with those possibilities.

Out of curiosity what would you consider the point when something becomes “big and wide”?

(I’ll also definitely keep that alert bit in mind, Daniel!!! Just like with making the art itself an image, it’s definitely a neat little consolation for making this just that much more viable.)

P.S. thanks for the input! Still interested in knowing if anyone’s managed to catch this elusive beast, but getting to hear the things people did on this front otherwise is definitely extremely helpful as is. I’ll also definitely try to offer an update when the problem becomes fully relevant again later down the line! If I remember at least, RIP…


I don’t remember having a specific character number in mind, but I just went ahead and used the width of the window in my word program, since it was very clear that some of my images would be that wide anyway.

1 Like

For one data point, my ECTOCOMP entry this year is built around an ASCII-art map. To make this work as well as possible:

  • The game can display it in two different sizes, and chooses a size at the beginning of the game based on the screen width the interpreter reports. If the interpreter says it’s too narrow for even the small size, it disables the map altogether.
  • The player can override the game’s defaults on this, choosing between a large map, a small map, and no map during play.
  • I added a toggle to the web interpreter that makes it fill the entire window horizontally; since most people will play the game in the interpreter I provided, this hopefully means everyone can make it wide enough to see the map.
1 Like

Parchment on mobile will only fit 44 monospaced characters on a line. Anything that fits that is likely to fit on all interpreters.


I did a bunch of experimentation when working on Folly, trying out a bunch of classic games, and the smallest width that didn’t render any of them unplayable was 64 chars. (And nearly all games were much smaller than that.) I remember Christminster in particular having a pretty wide ASCII-art map.

Obviously nobody is targeting my little interpreter, but it does imply that you’re wandering into uncharted territory if you go much wider than 64 chars or so.

Not sure about IF in particular, but generally speaking: once you’re on mobile there’s no “safe” screen size; all bets are off. Even on desktop, ASCII art poses a problem of accessibility. You simply must provide some way for players to turn it off, or skip it. Failing that, include it as an image as mentioned above. It’s for the best anyway, that will keep your art looking as intended on any display.


Yeah, for what its worth the historical standard for Infocom’s Version 4+ games was the ability to display 64 monospaced characters on a line, which may not mean too much nowadays except that interpreter/environment combinations may well have been set up to work with the Infocom canon, and therefore can be expected in most instances to display a minimum of 64 characters a line.

@Draconis probably describes the best approach: assume nothing, provide for automated means of adapting the story to cope with the interpreter-reported window size and provide the reader with means to override those automated settings.