An apologia for terminal games

Yes, to a certain segment of the population I suppose I define myself as a relic of ancient times when I insist that one can write good and absorbing computer games that don’t have a GUI – that throw down old-school in a terminal emulator.

Today I’m shipping a new release of the game greed – which is, I think, one of the better arguments for this proposition. Others include roguelike dungeon crawlers (nethack, angband, moria, larn), VMS Empire, the whole universe of text adventure games that began with ADVENT and Zork, and Super Star Trek.

I maintain a bunch of these old games, including an improved version of the BSD Battleships game and even a faithful port of the oldest of them all: wumpus, which I let you play (if you want) in a mode that emulates the awful original BASIC interface, all-caps as far as the eye can see.

Some of these I keep alive only because somebody ought to; they’re the heritage grain of computer gaming, even if they look unimpressive to the modern eye. But others couldn’t really be much improved by a GUI; greed, in particular, is like that. In fact, if you ranked heritage terminal games by how little GUIfication would improve then, I think greed would probably be right at the top (perhaps sharing that honor with ski). That in itself makes greed a bit interesting.

Much has been gained by GUIfying games; I have my own favorites in that style, notably Civilization II and Spaceward Ho! and Battle For Wesnoth (on which I was a developer for years). But the very best terminal games retain, I think, a distinct charm of their own.

Some of them (text adventures, roguelikes) work, I think, the way a novel does, or Scott McCloud taught us minimalist cartooning does; they engage the user’s own imagination as a peripheral, setting up a surprisingly strong interaction between the user’s private imagery and the bare elements of the game. At their best, such games (like novels) can have a subtle imaginative richness that goes well beyond anything this week’s graphical splatterfest offers.

More abstract puzzle games like greed don’t quite do that. What they offer instead is some of the same appeal as tiling window managers. In these games there is no waste, no excess, no bloat, no distraction; it’s all puzzle value all the way down. There’s a bracing quality about that.

Ski is kind of hermaphroditic that way. You can approach it as a cartoon (Aieee! Here comes the Yeti! Flee for your life!) or as a pure puzzle game. It works either way.

Finally, maybe it’s just me, but one thing I think these old-school terminal games consistently do better than their modern competition is humor. This is probably the McCloud effect again. I’ve laughed harder at, and retained longer, the wry turns of phrase from classic text adventures than any sight gag I’ve ever seen in a GUI game.

So, enjoy. It’s an odd and perhaps half-forgotten corner of our culture, but no less valuable for that.

UPDATE: I probably shouldn’t have described wumpus (1972) as “the oldest of them all”, because there were a few older games for teletypes like Hammurabi, aka Hamurabi (with a single ‘m’) aka The Sumer game from 1968. But wumpus is the oldest one that seems to be live in the memory of the hacker culture; only SPACEWAR (1961) has a longer pedigree, and it’s a different (vector graphics) kind of thing.

83 thoughts on “An apologia for terminal games

  1. Finally, maybe it’s just me, but one thing I think these old-school terminal games consistently do better than their modern competition is humor.

    You’ve… never actually played Portal, have you?

    Even well before Portal, the Sierra adventures kept the humor of the text adventures that inspired them while going fully graphical. And the narration to the later Space Quest games only gets funnier when read in the manic-radio-announcer voice of Gary Owens. (Yes, Laugh-In’s Gary Owens.)

  2. >And the narration to the later Space Quest games only gets funnier when read in the manic-radio-announcer voice of Gary Owens

    Anything at all, including a recitation of the phone book, would be funny in Gary Owens’s manic-radio-announcer voice. So you’re not really helping your case here.

  3. > …all-caps as far as they eye can see.

    “They eye”?

    I admit I haven’t played any of the text-only games you mention. I tried to play NetHack and the text adventure, A Mind Forever Voyaging, but in both cases I got stuck almost immediately. Guess I just wasn’t made for them. :$ As for ski, I’ve played the graphical SkiFree on Windows 3.1 instead.

    In principle, though, I’m not against text-only games; in fact, at least four of the DOS games I played in my childhood were like that (including two simple ones written by my father). Say, how would you classify Funnels & Buckets: as a GUI-less game or one with a GUI that simply happens to be made of text? (I still play that one from time to time, thanks to DOSBox.)

  4. Yes, if you’re after humor, you really, really, really need to check out Portal.

  5. Anyways, as for text games, I played Moria as a kid, plus the encounter with Apple Trek I had in 5th grade or so. In my teens I played various *bands, and more recently have played Dwarf Fortress. Have you ever encountered Dwarf Fortress? I’d be interested to hear your take on it, you’ll probably either love it or recoil in horror at the only text game I’ve ever seen that (depending on what size of site you start on and whether you keep your fortress’s cat population under control) can significantly challenge the performance of a modern computer.

  6. Jon Brase:
    Actually, he once said: “Never played either Dwarf Fortress or Minecraft. Last thing I need in my life is yet another time sink…”

  7. @Eric: Your classification of roguelikes as not-GUI makes me wonder how your criterion is constructed. They strike me as eminently GUI – there’s a map of the floor, right there, a live 2D display, and the player needs the whole thing in order to play effectively.

    I would’ve drawn the GUI / not-GUI line between roguelikes and text adventures. From your post, you seem to emphasize how much is left to the imagination – meaning you’d probably draw that line between roguelikes on a pure ASCII display and roguelikes using a graphical tileset (I used to play one during the 1990s on a VGA card). My line feels sharper to me, and I kinda wonder why that is. I guess that 2D layout of [ -~]* is enough for me to feel the heat from the torches and the menace of that cockatrice or rust monster stalking toward me.

    But I can see how modern AAA games push a lot of that away with their pursuit of realism. And I’ll be honest: I love that stuff. I adored seeing the central valley in Skyrim for the first time, with its rolling brooks and alpine meadows, or the vast rolling hills of Witcher 3, where you could gaze longingly at far-off peaks or castles (beyond the official game map’s borders), or stare at the detail of nearby flowers or fur on that griffin you’d just slain, watching them wave in the breeze.

    Mostly, I find exploration lust to be my greatest appeal. Something about seeing a hill and wondering what’s beyond it; what’s outside a window. Even 1992’s DOOM had such moments (looking out from Phobos Lab, for example).

    It’s not purely spatial exploration; I enjoy exploring every nook in a game’s conceptual space, trying every command, mixing every combination of potions, casting every spell on every creature, every option in a dialogue, every path in a plot tree. I used to draw maps of Choose Your Own Adventure books where each node was a series of pages between decisions. (If anything ever exemplified the hacker spirit in a pre-teen…)

    Roguelikes scratched a lot of that itch. Spatial exploration often wasn’t worth it – the dungeons were randomly generated, after all, so no room you visited was actually that special – but there were points of interest such as the castle or the Wizard’s keep that were a huge treat to finally reach. Meanwhile, you were searching in other “dimensions” for the highly sought potion of gain level, the intrinsic space, the magic marker / wand of charging combo, etc…

    Nowadays, that charm of things left to the imagination still exists, but it’s scattered among several thousand developers putting together little games in Flash or HTML5 and hosting them on sites like Newgrounds or Kongregate. Most of them are fluff, but every once in a while you find gold, and their rating systems often help with that.

    That market is big enough to range from single developers to professional workshops and even a gray market of knockoffs and pay-to-play scams. In fact, between host sites, game stores, online distro sites like Steam and github, international markets from Japan to Brazil to Finland, and all the myriad underground channels and scenes, finding a worthwhile game is its own meta-game. There might be a formal artifact one could build out of all of that, some day.

  8. As far as the meld of text adventure and humor goes, I feel as if a plurality of credit there goes to Steve Meretsky. I feel as if the Spellcasting series was his last hurrah, though, and that ended in the 1990s. He’s helped with games since, but nothing seems to have had that distinct charm since then, so far. If I see his name on a game now, though, it’ll be a definite plus.

  9. It is a good argument that adding features to the game requires far less work without graphical representation and that makes them feature-rich. You can use a basilisk head in Rogue to turn opponents to stone? Awesome, but consider how it does not mean having to model 3D stone statues of every monster! It is mostly just a text message and changing stats to dead.

    I actually plan to create a MUD as an experiment for testing social and political theories.

    My idea is that we start at a point of history, a medieval kingdom or modern democracy, with laws and such things, but those are not encoded in the engine. Those are, like in the real world, only text and communication. The engine never enforces a law or gives you actual political powers or anything like that. All that is human interaction.

    The engine only simulates biology and physics i.e. things, goods, objects. If you die, you are locked out for a month unless you have offspring in which case you can play on after a week of timeout. If you are wounded or starving, you move slower and your text-speech is garbled and people find it hard to understand you, but easy to kill you. If you are rich you can buy things like weapons or a printing press which reduce the chance of dying or wounding and unlock obviously interesting options. All this is simulated biology and physics. Nothing in the engine simulates politics or society.

    My hope is what if we get the biology right politics and society is automatically generated by human interaction. Maybe people start fighting but realize getting locked out is no fun. They realize elections are a better idea as it is like showing up and counting soldiers without fighting. Suppose you lose an election but refuse to abdicate. Maybe your own policemen arrest you because they want to avoid dying in a civil war. Arresting means telling you to follow them and attacking you if you don’t and then we are back to the biology, combat engine. Then putting you in a cell – simply a place where you don’t own a key object to the door, to the only exist – that is object simulation. So society should unfold from biological and physical simulation. The experiment can be ran starting with nothing, a Hobbesian world and see how laws evolve, or from a historic standpoint like Middle Ages or today.

  10. I actually plan to create a MUD as an experiment for testing social and political theories.

    How do you plan to make the MUD fun enough that people will stay and play?

    Another angle: a great deal of these social mechanics are already available in many games, typically in the form of guilds. You seem to imply that a big draw here is how visible such mechanics are. Thing is, most social mechanics are private – most people are not allowed to see what everyone else is planning, scheming, enforcing, threatening, including in their business model, etc. That secrecy is a huge part of what shapes social structures. How do you intend to make a rich, visible social landscape when most of it is intrinsically hidden?

  11. There’s probably no better endorsement for Eric’s idea of character-terminal games providing a unique visual and gaming aesthetic than the fact that by default, Dwarf Fortress uses OpenGL to provide a simulated terminal interface.

  12. >Your classification of roguelikes as not-GUI makes me wonder how your criterion is constructed. They strike me as eminently GUI – there’s a map of the floor, right there, a live 2D display, and the player needs the whole thing in order to play effectively.

    Whereas in my mind the big difference that matters in GUI games is the use of bit-mapped graphics to create a “realistic” environment, committing the designer to a lot of investment in pretty surfaces. While this is not a bad thing in itself, it has the effect of drawing developer time way from puzzles, game logic, multi-path plots, and sandboxing.

    Jeff Read has pointed out that Dwarf Fortress uses OpenGL to simulate a terminal interface. This is a designer deliberately walling himself off from the temptation to concentrate on surfaces, and is in itself direct evidence for both my thesis and the notion that the really important divide lies on the far side of rogue, away from the direction that it faces ADVENT.

  13. Paul Brinkley:

    How do you intend to make a rich, visible social landscape when most of it is intrinsically hidden?

    Nevertheless, if TheDividualist manages to create the game, I’ll try it (provided it’s easy to install; availability on the Debian/Ubuntu/Mint repos would certainly help).

    TheDividualist:

    Your idea reminded me of an online community around a fictional country, which they seem to have imagined in a lot of detail – especially its politics. At first, I didn’t remember its name, so I searched for it in vain; but I serendipitously found this article about an effort that’s similar, but individual and seemingly apolitical.

    I eventually remembered that Scott Alexander had something to do with the former project, which allowed me to finally find it: it’s Shireroth. Had you seen it?

    esr:

    Whereas in my mind the big difference that matters in GUI games is the use of bit-mapped graphics to create a “realistic” environment…

    So Paul would say that Funnels & Buckets does have a GUI – which just happens to be made of text – and you’d firmly deny it. I don’t know who to agree with. :-( (In Spain, they have – or used to have – a nice idiom for that: “No sé a qué carta quedarme“; literally, “I don’t know which card to keep”.)

  14. >So Paul would say that Funnels & Buckets does have a GUI – which just happens to be made of text – and you’d firmly deny it.

    That is correct, about my evaluation at least.

  15. @Jorge Dujan:

    I tried to play NetHack and the text adventure, A Mind Forever Voyaging, but in both cases I got stuck almost immediately.

    AMFV is perhaps one of the most impressive pieces of interactive fiction for its’ storytelling ambition, but those same qualities make it a terrible introduction to the medium. For beginners, I would recommend either Emily Short’s Glass or Bronze pieces. [Glass is rather non-traditional and could be completed in 5-10 minutes, while Bronze is a standard adventure with extensive help features.]

  16. So Paul would say that Funnels & Buckets does have a GUI – which just happens to be made of text – and you’d firmly deny it. I don’t know who to agree with. :-(

    Shrug. Agree with both. We’re just using different criteria, is all. Eric’s seems to revolve around bitmapped textures, or any conceptual equivalent; mine is more austere and implies it’s a GUI iff a human gets anything extra if the entire game content were delivered in 2D as opposed to coming in serially (think 1200 baud modem). Each carves at a different joint in how much is left to the player’s imagination. Both joints exist, in my considered opinion.

    (Incidentally, this site appears to be eating a post of mine outright, with no warning. Not sure why.)

  17. >mine is more austere and implies it’s a GUI iff a human gets anything extra if the entire game content were delivered in 2D

    How would you classify Super Star Trek? Does your classification change if you play it in -t (teletype) mode?

  18. [Trying smaller posts.]

    While this is not a bad thing in itself, [investment in pretty surfaces] has the effect of drawing developer time way from puzzles, game logic, multi-path plots, and sandboxing.

    Right – the Great Texture Hunt, which I swear is responsible for 90% of the size of AAA games. Or perhaps the more accurate way of describing it is that the pretty surfaces themselves aren’t hogging the dev effort, so much as thinking of all the hacks to make them work in the world on desktop hardware without bringing the graphics card to its knees. (Which is still consistent with “investment in pretty surfaces”.)

    Puzzles are kinda stagnant, it seems. There are a few classic modes (sokoban, burr puzzles, tetris, word games, concentration, color matches, et al.), and everything is a variation on them. Valve played with physics puzzles a bit, but only a bit. (I’ve heard Breath of the Wild breaks some new ground here, but I don’t have a Nintendo to try it on.)

  19. My holy grail / pie-in-the-sky wish is sandboxing with the plot itself. BioWare gets praise for making games with very complex plot trees, but the devs are obviously aware of every possible scenario, and have shot every conceivable scene, and sewn up every potential loose end so that the plot tree looks more like a string of beads of local complexity, all wrapped up and railroaded into at most 2-3 plot threads heading into the next bead.

    Even if you didn’t have to direct a scene complete with facial expressions and scripted voice acting, sandboxing the plot is so hard that I don’t expect it to happen for another 20 years. Imagine playing NetHack, and instead of doing your thing in GnomeTown and moving on, you buttonhole the shopkeepers about why they’re sitting in these isolated rooms where no one visits but the protagonist, and convince them to come with you and get even more wealth, since they’re obviously tough enough to handle anything on those levels.

  20. Then you corner as many kobolds as you can find and offer to train them in blacksmithing, giving them successively more complex weapons to craft, feeding them with bat meat and floating eyes or whatever, until they’re talented enough to work with magical weapons. Then you and the shopkeepers mount an expedition, acquire Mjollnir, and have the kobolds reverse-engineer it and make one for each shopkeeper, plus several more for a power plant.

    [I’d post more, but again, the site keeps eating it, and I don’t know why, and I’m afraid I’m spamming Eric somehow. Suffice to say: if devs can’t predict how players will steer the plot, then we have plot sandboxing, by jove.]

  21. Well this certainly popped at an interesting time… As I am working of a python port (? not sure of what the correct term would be) of VMS Empire using a graphical interface.

    @ESR

    Relevant question: what are the cultural norms for reimplementing a pre-existing project in a new language / interface / whatever?

  22. How would you classify Super Star Trek? Does your classification change if you play it in -t (teletype) mode?

    It’s GUI, pretty much because of that NxN grid.

    Admittedly, this is close to abuse of the semantics – if the contents of a sector were delivered in a manner akin to a sparse matrix (e.g. “Cruiser at (2,4); black hole at (8,1); sector otherwise empty”), then it satisfies the “serialized” criterion, and since delivering that matrix in grid form is arguably even smaller, it’s at least as efficient data-throughput-wise as a text-mode game.

    However, sparse matrix output still means the player is encouraged, if not required, to visualize the sector, for the purpose of actions such as launching torpedoes. Which really just means that “serialized” by itself is not a great way of describing my criterion. (I haven’t played Star Trek in probably decades, and never in teletype mode, so I can’t speak to it except by speculation.)

    Imagine a text adventure game where, instead of being told you’re in a room with a door barred by an ogre and two orcs sit at a table playing cards, you’re told that the door is 10′ W of the SE corner, the ogre is about one pace in front of that, the orc table is against the N wall in the center and the orcs are facing E-W at each other, and that this matters to the gameplay because instead of just typing “shoot wand of fireball at ogre”, you have to “aim wand 30 degrees south of due east and fire”. The result is a game that’s effectively a GUI, trying to stuff itself into a serialized interface.

    By your standard, I’d rule both SST and the hypothetical here as non-GUI, as they’re encouraging the player to imagine the scene.

    (This isn’t perfect. Most text adventures encourage a map in the player’s mind. All I can offer there is that that map can be forgotten a bit more readily. I remember where the Xyzzy room is relative to Y2, but in game, I remember the string “s e u e”.)

  23. Whereas in my mind the big difference that matters in GUI games is the use of bit-mapped graphics to create a “realistic” environment, committing the designer to a lot of investment in pretty surfaces. While this is not a bad thing in itself, it has the effect of drawing developer time way from puzzles, game logic, multi-path plots, and sandboxing.

    What would you call a game that uses bitmapped or 3D graphics to create a less-than-realistic environment? Minecraft is fine on the sandboxing aspect (not so much the others, but I think you’re smuggling in genre distinctions).

    Actually, to elaborate on the genre thing, your whole list only really makes sense for an adventure game – puzzle games, for example, have puzzles, obviously (and can’t do without), but any “plot” is just superfluous window-dressing. Platformers live and die on physics simulation (i.e. whether you can make some jump, whether you need a running start), and obviously therefore can’t be implemented in text mode, but you can certainly go minimalistic on graphics, and level design can even be tile-based – it’s just the player sprite that needs to be pixel-positioned.

    Do you consider any game that can be implemented in text mode to be non-GUI, even if they haven’t? I mainly have puzzle games in mind – Tetris (which has, but typically is bitmapped), Bejeweled*, Pipe Dream, etc.

    *I’ll note that the game mode of Bejeweled I personally most often play has a time component which would make it unplayable without a mouse or touch screen, but other modes do not.

  24. >Relevant question: what are the cultural norms for reimplementing a pre-existing project in a new language / interface / whatever?

    Not sure there are any.

  25. >Admittedly, this is close to abuse of the semantics

    Which means you’re reaching some of the conceptual problems with your way of making the distinction.

  26. AlexK:

    For beginners, I would recommend either Emily Short’s Glass or Bronze pieces.

    Thanks. I completed Glass twice, but still haven’t gotten the optimal outcome; the second time, I got this: “*** Cinderella and the Prince are (eventually) wed ***”. And I’ve yet to play Bronze.

    If I succeed at either, I’ll let y’all know. :-)

    Paul Brinkley:

    You might find this Wikipedia article interesting.

    Random832:

    Platformers live and die on physics simulation … and obviously therefore can’t be implemented in text mode…

    Whoa, back it up, back it up. Beep, beep, beep. What about Moon Buggy, available in the Debian/Ubuntu/Mint repos – and the AUR – as moon-buggy?

  27. Speaking of portal, one thing that text games, with the exception of Dwarf Fortress, tend to be missing, is *music* (the song in the ending credits for Portal is well renowned in modern geek culture). This is probably less the case on games that originated on micros than those that originated on minis, as the only sound capability on serial terminals was ^G, but I can’t think of a lot of text mode PC programs that had music. (One shareware vendor had a text mode installer that they used for most of their graphical games that had very catchy music that ran throughout the install, and a fair number of installers for graphical games would play snatches of music in the sound card config dialog so you could verify everything was set up correctly, but I can’t think of any games that actually ran in text mode and played music).

  28. > Whoa, back it up, back it up. Beep, beep, beep. What about Moon Buggy, available in the Debian/Ubuntu/Mint repos – and the AUR – as moon-buggy?

    Doesn’t fit my definition of a platformer (player moves at a constant speed and horizontal movement cannot be controlled). Actually it seems to play more like a rhythm game, though a particularly unforgiving one.

  29. Which means you’re reaching some of the conceptual problems with your way of making the distinction.

    Am I, though? Star Trek and roguelikes have to worry about the width of the terminal, or how to control the cursor that draws the game display, in a way that text adventure games do not.

    In fact, the more I think about it, the more convinced I am that most people would probably classify games as GUI / not-GUI the same way I would. My GUI / not-GUI distinction is mainly just a mundane one about presentation.

    The essence you’re getting at – leaving things to the imagination – tends to be captured in other concepts, such as “minimalist”, or is strongly implied by “text-only” without text-only being a necessary condition. There are games which work in pixels, but are still resting on puzzles or gameplay depth, Tetris probably being the most well-known example. You could implement Tetris on a terminal emulator, and it’d still play like Tetris.

    That’s one interesting way to evaluate a game’s depth, then – imagine how much of the pretty surfaces one could remove and still have the game be identifiable. Civ 2, for instance, survives in some ways but not in others – the sweep of history would still be there, along with the web of trade and the grid of military units. A lot of the fun would still be there, but a lot is also missing, since you don’t get to see gray jets soaring over infantry in green camo marching toward a mounted knight. (It’d remind me of Anacreon: Reconstruction 4021.)

    Another way to evaluate is in how that gameplay is actually presented. NetHack can be presented with tilesets. But the base game is letters and punctuation marks. I’d still call it a GUI of a game, but more importantly, it’s minimalist in graphics, because it can be. Add a lot of pretty surfaces and it looks like Blizzard’s Diablo – except that the latter also strips out a lot of the alchemy set and hacker’s physics and other gameplay elements, and then adds a lot of 3D-rendered cinematics and story that’s epic because you’re seeing epic graphics. So Diablo can’t be minimalist.

  30. >What would you call a game that uses bitmapped or 3D graphics to create a less-than-realistic environment?

    I thought Minecaft would probably come up. :-)

    I’m not actually that interested in chasing down definitional edge cases. The GUI vs. non-GUI distinction is not an end in itself for me, it’s a way to get at the underlying reasons that games like SST or NetHack retain as much play value as they do. Or to put it a different way, I think it’s worth trying to understand what GUIs are often a distraction from.

    Here is a relevant thing, though: I’ve played versions of Tetris with both bitmap and character-cell graphics and…it really doesn’t make much difference to the game experience. The problem doesn’t change, the difficulty curve is not noticeably affected. I recognize it as a good, engaging game regardless of whether it has graphics or not.

  31. >My GUI / not-GUI distinction is mainly just a mundane one about presentation.

    Mine is more about relative investment in surface vs. game depth. I think you’re over-focusing on the “imagination as peripheral” part of what I was saying.

    My claim is not quite that the best old-school games were good because they left a lot to the imagination, though that is an important trait in their appeal. It’s more like: they’re good because, given the primitive UIs of the time, game depth and story/puzzle/humor value were the only places a designer could put his/her time and creative energy.

  32. @Paul Brinkley: @Eric: Your classification of roguelikes as not-GUI makes me wonder how your criterion is constructed. They strike me as eminently GUI – there’s a map of the floor, right there, a live 2D display, and the player needs the whole thing in order to play effectively.

    The usual distinction is that non-GUI games can be displayed and played in character mode on a terminal, and do not require a graphics adapter or a GUI. The boundaries do blur. I have Nethack here, and play it in character mode, but there’s a variant that uses graphical tiles to construct the dungeon and represent creatures in the dungeon.

    I still play old DOS ports of VMS Empire and Larn courtesy of vDOS, a Windows specific port of DOSBox intended for support of DOS character mode business apps, that drops the specialized graphics and sound support for old DOS games. For that matter, I have both on my Android tablet playable via an Android port of DOSBox. (Eric’s Linux version of VMS Empire has performance issues here that make playing it problematic, so DOSBox gets the nod under Linux, too.)
    ______
    Dennis

  33. ” I would recommend either Emily Short’s Glass or Bronze pieces.”

    Endorsed. Or Galatia.

    Ms Short is an artist of highest degree, co-author of the high-level language Inform 7, and vastly under-known as far as I’m aware among techie and or fan sub-cultures.

  34. The GUI vs. non-GUI distinction is not an end in itself for me, it’s a way to get at the underlying reasons that games like SST or NetHack retain as much play value as they do.

    Agreed, actually. I even regretted harping on the GUI / non-GUI distinction, precisely for fear of appearing to overfocus; the only reason I felt compelled to do so is to the extent it was brought up in the OP.

    Also agreed that the pre-2000 sensory deprivation produced a lot of deep game art. If I read the OP that way, then yeah, it’s a lot more agreeable.

    Here’s a thought: consider tabletop games pre- and post-Settlers of Cataan, say, and the parallels between that market and the market for computer games. Both markets are booming; both have plenty of innovation and plenty of dross. (Although, honestly, high profile tabletop flops don’t seem nearly as common AFAICT. Not sure why. Something something high barrier to the AAA videogame market, I guess.) Pre-Cataan, there are plenty of shallow tabletops (Monopoly, Sorry!, et al.), the classic pure games (chess, Go, Nine-Men’s Morris, scores of card games), and a few in between (Boggle, Scrabble).

    Did graphic deprivation make for deeper tabletop games? Or is the difference in tabletop tech between chess and the Kickstarter era not big enough to overcome the boost from having a lot of creative people enter the market?

  35. My favorite Tetris implementation – apart from the original, which I no longer have – is Blocks from Hell.

    I knew Toren “Tbone” Smith back when he was showing off BfH on a ratty IBM (80286, probably, since this was in the early 1990s at UT Austin). IIRC, he wrote it in 100% IBM 8080 architecture in assembler, by himself, and demonstrated how it ran smoothly and equally fast on any IBM in the lab, regardless even of the graphics adapter. This was a very nontrivial feat at the time.

    I later ran into him again at Balticon 49, along with his young child and his wife – the sister of Steve Matuszek – a friend of mine and Eric’s.

    Small world.

  36. @Paul:
    > In fact, the more I think about it, the more convinced I am that most people would probably classify games as GUI / not-GUI the same way I would. My GUI / not-GUI distinction is mainly just a mundane one about presentation.

    I think there’s a pretty important three way distinction here. The middle ground can be called, in an abuse of terminology, “curses” (even if not technically implemented with curses). “Curses” games are distinct from tiled GUI games in that the set of available tiles is not determined by the programmer (being fixed in the early days by terminal limitations and in the modern day more often by tradition, unless they’re actually using curses proper on a terminal window), and, in cases with minicomputer ancestry, generally a complete lack of sound, even if the platform now supports it.

    They are distinguished from text games in a geometrical and intuitive display of information, and in being constrained by terminal/window geometry.

    The distinction between “curses” and tile GUI gets a bit murky in that a lot of “curses” games are implemented these days as SDL or OpenGL tile programs with text characters for tiles, and some old tile graphical titles on micros used text display modes, but loaded a custom font that was mostly graphical tiles, or even implemented a kludged-together low-res pixel display mode.

  37. > Jeff Read has pointed out that Dwarf Fortress uses OpenGL to simulate a terminal interface. This is a designer deliberately walling himself off from the temptation to concentrate on surfaces, and is in itself direct evidence for both my thesis and the notion that the really important divide lies on the far side of rogue, away from the direction that it faces ADVENT.

    You called it. Dwarf Fortress is actually “Slaves To Armok II: Dwarf Fortress”; The first entry “Slaves To Armok God of Blood” was never finished due to the immense time sink of creating the 3D stuff (Tarn Adams, the programmer, says this somewhere I can’t quickly locate) and dropped rather unceremoniously six years in when DF got an adventure mode.

  38. One important thing about text mode games is that hackers/geeks, I think, tend to have low I/O bandwidth and/or be easily distracted, and so tend to be less appreciative of pretty graphics for the sake of pretty graphics. If the graphics doesn’t add information, or if signal-to-noise ratio isn’t part of the game (as in, for example, a WWII combat flight sim, where, at high realism, spotting the enemy is part of the challenge before you and there’s no fancy HUD or MFD with radar data to help you distinguish targets), I rather prefer to have the most minimalistic graphics possible for the purpose of minimizing signal to noise. Unnecessary isometric 3D in a game that is tile based at its core always leaves me with the nagging feeling that something is hiding behind a wall, visible to my character(s), but not visible, or nearly invisible, to me. For the same signal to noise reasons, I like to have color in text based games to make things jump out.

  39. >Did graphic deprivation make for deeper tabletop games? Or is the difference in tabletop tech between chess and the Kickstarter era not big enough to overcome the boost from having a lot of creative people enter the market?

    I don’t think the pre- and post-Catan eras are readily comparable, for several different reasons.

    One is that two trends with different origins and timing converged around 2000 and had confounding effects on each other, making it difficult to tease out causality around them. One trend was the development (especially in Germany) of the style of multiplayer social game now called a “Eurogame”. The other was falling costs for cold-press full-color printing.

    Yes, there were Eurogames before the present age of bright colors, heavy cardstock, legible fonts, and relatively large wooden meeples. It’s eye-opening to play the 1990 edition of Adel Verplicht (several names in English, perhaps best known as “Hoity Toity”) from just before the typical production values in these games from went from muddy to (at the time) spectacular. No coincidence that the opening of a successful export market in the U.S. followed shortly thereafter.

    There was a boardgaming hobby in the U.S. before the Eurogame invasion, yes, but (aside from a relatively small number of wargamer grognards like me) it ran much more heavily to shallow games designed for family and light social play. Until Catan nobody knew there was a mass market for anything more substantial. (Actually, a lot of American Eurogame fans, including me, consider Catan a prelude, with the actual breakthrough being the success of Puerto Rico in 2002-2003.)

    Through all this, the relatively small number of more serious games produced by American designers like Sid Sackson didn’t change much. Wargamers didn’t generally play them (they tended to be abstract, or with much less theme and historical grounding than wargames had then or later became common in Euros), and the relatively few people who played these games were not also wargamers. Chess was off in its corner doing its own thing (and still is).

    It’s hard to say whether the rise in production values promoted depth in games, encouraged the publication of more shallow junk, or had no effect on that axis at all, because the hobby was changing radically in an almost orthogonal way as well. The Eurogame style was becoming the dominant form of gaming. pulling in both old wargamers like me and a lot of newbies.

  40. >The middle ground can be called, in an abuse of terminology, “curses” (even if not technically implemented with curses).

    There is a term of art for this, not yet common but I’m trying to propagate it because it’s useful: TUI = Terminal User Interface, in both similarity and contrast with GUI.

  41. Various random comments:

    Yes everyone should play Portal.

    I love exploration, but I’ve decided I prefer game worlds designed for discoverability over ones that are truly open ended. Perhaps shaped by one historical example.

    First game I ever played with a *large* game world you needed to explore was Ultima IV. I spent a very great deal of time on that game. There was at least one extremely useful place you could only get to by massaging a bug. At a certain world load point, if you loaded a specific disk that *wasn’t* the one you were supposed to load, you had access (if you were prepared to walk across a small amount of lava) to an infinite treasure chest. Seems *everyone* I knew who played that game knew about that secret before I did. Sure it was a bug, but it led me firmly to believe that things in unfamiliar environments should be discoverable. Well unless the goal is deliberate sadism.

    >>The middle ground can be called, in an abuse of terminology, “curses” (even if not technically implemented with curses).

    I’ve used the same terminoligy.

    >There is a term of art for this, not yet common but I’m trying to propagate it because it’s useful: TUI = Terminal User Interface, in both similarity and contrast with GUI.

    I remember coming across the term TUI recently. Liked it, it makes sense. Is it your invention?

  42. >I remember coming across the term TUI recently. Liked it, it makes sense. Is it your invention?

    No. I tripped over it a few years back and liked it.

  43. In tabletop gaming, there were two seminal events in game design in the 1990s.

    In 1993, there was Magic: the Gathering, which (from a design perspective) implemented “exception-driven game design.” While Cosmic Encounter actually did exception-driven game design earlier, M:tG was its first widespread breakout success.

    In exception-driven game design, you’re presented with a framework of rules; everything that gives the game nuance is an _exception_ to this core framework. This also opens up your design and complexity space immensely; the Auld Gigantic Rulebooks of Yore for wargames were Auld and Gigantic because enterprising designers kept adding rules to cover corner cases and “X and Y and Z interact…” combinatorics. M:tG gave you the combinatorics while keeping the wetware data load minimal.

    The second major change came with Catan, which emphasized “no player elimination.” One of the goals with Catan and Puerto Rico and Race for the Galaxy is that you never eliminate a player, and you want a game done in an hour or less (or 30 minutes or less…)

    Because of those design constraints, you had to be ruthless about removing rules from games; in a programming context, it’s “removing lines of code” and “building from unit tests.”

    Combine those two design trends, and you get things like Dominion, which have no player elimination, and have mechanics built on exceptions rather than compliance.

    These two design trends, plus a sudden reduction in the cost of high production values, created the Eurogames Boom of the 2000s.

    American-designed games tend to have more of a simulationist bent to them, and tighter integration of “theme and mechanics.” This also leads to more ‘player elimination’.

    “Only an American would’ve designed Diplomacy” is a fairly common Eurogame indictment, and Diplomacy is a case study for why game theorists make awful games.

  44. Whereas in my mind the big difference that matters in GUI games is the use of bit-mapped graphics to create a “realistic” environment, committing the designer to a lot of investment in pretty surfaces. While this is not a bad thing in itself, it has the effect of drawing developer time way from puzzles, game logic, multi-path plots, and sandboxing.

    I call this “Amiga Game Disease” because — while the Amiga had some fantastic games — often the most visually impressive ones, such as Shadow of the Beast, were shallow gameplay-wise to the point of being little more than showcases of the Amiga’s graphical capability. Everybody remembers how cool it was to boot up Shadow of the Beast and see all those parallax layers and huge sprites. Less memorable — because we’d rather block out those unpleasant memories — is what an unrepentant, often confusing slog the game was to play through. Later games in the series offered more depth, but the cost was, the graphics weren’t as good!

    But bit-mapped graphics can be used to create an abstract, representational game environment also — and if you commit to this art direction, that frees up developer resources to put more effort into game mechanics. This is perhaps most obvious in the embrace of retro graphics characteristic of 8- and 16-bit game consoles (third and fourth console generations) by “indie” game studios.

    The graphics to my favorite game of all time — Rez — are extremely abstract and representational to the point of being geometric (it is, after all, set in a Gibsonesque cyberspace), yet they are meticulously crafted to develop and reinforce the game’s central conceit: generative music and visuals arising from in-game events of a shooter game. As a side effect, Rez translates smoothly enough to VR environments that it can be played with a VR headset without inducing sim sickness in most players.

    Then there’s id Software — notorious for pushing the graphical envelope while still keeping the gameplay deep and fun. Unfortunately since the ZeniMax acquisition they seem to have abandoned both open-sourcing their old engines and rolling Linux binary releases of their flagship games. But if you have a chance to play the 2016 reboot of Doom I recommend it. There are multitudes of interlocking mechanics in there that make even the single-player campaign a vehicle to exercise skill and creativity.

  45. @Jorge

    >Your idea reminded me of an online community around a fictional country, which they seem to have imagined in a lot of detail – especially its politics.

    I cannot find it anymore, seems the Internet forgot it, but there was an online country simulation started around 1999 or so which I think was called Supremacy. I think it was a Cold War simulation, US vs. Soviet and people were drawing complicated leadership structures on mailing lists then somehow it fizzled out. I feel nostalgic about it, any chance anyone found any trace of it?

    Apparently it was inspired by Star Wars Combine which is nearly 20 years old now!

  46. Jeff Read,

    >“Amiga Game Disease”

    See the big picture please, while the Amiga had a keyboard culturally it belonged to the keyboardless coin-op arcade and maybe early console world. I played Golden Axe first on a coin-op then on Amiga. SotB was IMHO not released to coin-op but looked and felt similar. The Amiga tried to be so much a console-like that while it had a keyboard, a neat windowing GUI and in fact it introduced the mouse for us clueless C= 64 guys who wonder what is this new kind of joystick, the common way to run a game was to turn it off, insert the disk, turn it on and the it would launch it automatically.

    Decades later, the games on PlayStation are pretty but shallow. It all boils down the same logic. Except racing simulators, they are great, Shift 2, GT5.

    I know the general attitude of old time gamers who want depth and scoff at optimizing for eye candy, but I find that simulators make a graphics quality orientation excusable: it is not pretty eye candy what we are looking for but simply realistic looks. I am pretty excited that 7 years old Shift 2 is already kind of photorealistic if you kinda look squinty at it. Lead designer: “you’re drafting a guy now you’ll get all the little bits of crap from his car, all the gravel and rubber hit the car and they can hit your windscreen” Sadly VR resolution is a step back, but once we get about that photorealistic, retina-resolution VR racing sims I will be a happy man. Quite literally, I like it a lot but I cannot afford an actual racecar.

    Sadly TORCS and the open source racing sim world is pretty behind in the quest for photorealism.

  47. Dwarf Fortress type stuff would be IMHO an excellent case for what non-Unix-Hackers call Service Oriented Architecture and I suppose ESR will tell us Unix hackers knew that concept and had a different name for it 30 years ago: the core application should not have any tightly integrated UI output but emit machine-readable, say, XML output, and then various clients should render that, one could be terminal, the other graphical 2D, a third one 3D. Not simply a client-server architecture but also a fairly loose coupling between the two, the server developer not optimizing for one particular kind of client. SOA is achieved if you don’t even know screen readers for blind people exist and someone could still make a client for your server that way.

  48. >In tabletop gaming, there were two seminal events in game design in the 1990s.

    Your game-designer perspective complements my player-centric account of the transition nicely. And you are more of a domain expert than me. So, I have two questions:

    1. Do you happen to know what specific technology change was behind the sudden drop in printing and component costs 1990-1995? Or was it not a technology change it all? (Hm. Now I wonder if the beginning of large-scale availability of hi-res color displays in ’92 might have been e breakpoint – was it just inexpensive CAD/layout systems?)

    2. No-player-elimination as a deliberate design trope predates Catan by at least five years; I’ve already cited Adel Verplicht (1990), which had almost every trait of the post-2000 Eurogame except the visual style. It did not have an exception-centric design; nor did Puerto Rico. Can you identify anything else that was groundbreaking about Catan?

    I think you are quite right to identify Dominion as a milestone; I remember helping playtest a late pre-publication version and hearing it described (by another tester) as “the next Puerto Rico“. This was against the background of Caylus which was a pretty obvious attempt at being the next Puerto Rico that failed. We didn’t have the label “Eurogame” yet; I think people were just beginning to call them “German-style” games, a term that later fell out of favor.

  49. >ESR will tell us Unix hackers knew that concept and had a different name for it 30 years ago

    30 years ago is about right – we first started seeing architectures like that as the Berkeley sockets API stabilized in the early ’80s. We didn’t have a name for it, though – it was just part of the Unix thing about coupling as loosely as possible and separating mechanism from policy.

    SOA is still not a common term in Unixland, because it’s just the water we swim in.

  50. >I cannot find it anymore, seems the Internet forgot it, but there was an online country simulation started around 1999 or so which I think was called Supremacy. I think it was a Cold War simulation, US vs. Soviet and people were drawing complicated leadership structures on mailing lists then somehow it fizzled out. I feel nostalgic about it, any chance anyone found any trace of it?

    Never knew about an online version, but that sounds familiar.

    If my memory can be trusted, that started as a PBM game. Yes, postage. Some poli sci professor in New England somewhere, iirc, devised the rules. It was vaguely like Diplomacy with 7 reasonably balanced ‘sides’, though they were far from exactly equal. There was US and USSR as most powerful, and other factions were conglomerations of lesser powers, like there was a ‘Marxist 3rd World’ and an ‘ Unaligned 3rd World’.

    If you wanted to play you bought a rulebook from him and joined the queue for the next game. Not sure how many games he had running at once but it was at least 2, because a friend of mine in college was in one and I thought it looked interesting so I bought the rulebook and joined the queue for the next startup. Our games were running simultaneously. This was 1990 or so.

    The game was fascinating but posed a major time burden (and a surprisingly stiff financial burden in postage, as there were lots of required mailings to all other players). The time requirements were just too steep for where I was at the time, so I handed my country off to someone in the join queue. For all I know that game is still running.

  51. I may be mixing up ‘Supremacy’ and ‘Sovereignty’.

    Upon reflection, Sovereignty was the PBM Diplomacy-like military/political game.

    There was a board game called Supremacy that was also a Cold War style simulation that came out in the mid 80’s. I had a copy. The thing I remember about it most was it had a unique graphical production style, with very oddly shaped pieces. :)

  52. @esr: 1. Do you happen to know what specific technology change was behind the sudden drop in printing and component costs 1990-1995? Or was it not a technology change it all? (Hm. Now I wonder if the beginning of large-scale availability of hi-res color displays in ’92 might have been e breakpoint – was it just inexpensive CAD/layout systems?)

    Referring to color printing, I don’t think it was a technology change. Four color process printing is four color process printing. But as any technology progresses, costs drop.

    One question about the suddenly higher quality color board games you recall is precisely where they were printed. I recall a lot of expensive color printing migrating overseas to get lower costs, and you would see “coffee table” books that were actually printed in China to take advantage of dramatically lower labor costs and overhead. Much cheaper all told to print there and ship here.

    This is especially true for shorter press runs. The biggest upfront cost in color printing is setup and makeready – getting the plates mounted on the press and printing test sheets to insure color values are correct and registration is perfect. The costs of printing additional hundreds or thousands of whatever it is once the press is set up is a fraction of the total, and the variables are paper costs and press time. Really large volume printing might still get done here, for things like mass market magazines with timing constraints on when the product had to be ready and ship. When you are printing hundreds of thousands of copies, the economics are quite different than when you are printing a few thousand. Economies of scale kick in.
    ______
    Dennis

  53. >Much cheaper all told to print there and ship here.

    That’s interesting. The change driver, then, might be lower costs for contracting and shipping outsourced printing jobs.

    This would go with the fact that a lot of U.S. Eurogames outfits are very light on staff. IIRC, Rio Grande is basically one guy making contracts with designers and production shops; there is some concern about what will happen when he decides to retire.

  54. Paul Brinkley:

    Small world.

    Indeed. :-) And I didn’t know BfH was written in assembler. That must be very difficult.

    TheDividualist:

    I feel nostalgic about it, any chance anyone found any trace of it?

    Sorry, I don’t know that project. But here’s a possible consolation prize: if you’re into DOS games, you might enjoy Shadow President. I haven’t played it yet, but it looks appealing.

    Ken Burnside and esr:

    Have you read Johan Huizinga’s Homo Ludens? If so, did you find it worthwhile?

  55. I’m going to say that Star Trek gets to be BOTH an early text game AND an early GUI game. The inclination to use text to make graphics was there right from the beginning on computer terminals. It’s still a terminal game. Star Trek in particular was written when most terminals didn’t even have cursor addressing. The screen had to be redrawn from scratch (and in fact
    would run fine on a paper terminal).

    You type stuff in, the computer displays some results as formatted text, and you type more stuff in. The fact that it was a predictor for everything that followed, an expression of desire for graphics which did not exist, does not mean it was a GUI.

    The worst part about this false distinction is it lets us all forget the history of GUI design, which was not a revolution with the 1984 Mac, but an evolution throughout the 70s and early 80s, a gradual conversion from command mode programs to text-based GUIs, during which text was used to lay the foundation of most of our modern GUI design principles. Buttons, menus, checkboxes, radiobuttons, and more were all designs that were created for text-only terminals. And by the end of that road (before the Mac), these programs were surely 95% GUI and only 5% command line. But Star Trek was the first step down that long road.

  56. @esr: >Much cheaper all told to print there and ship here.

    That’s interesting. The change driver, then, might be lower costs for contracting and shipping outsourced printing jobs.

    The change driver was simply lower costs, and it doesn’t take an underlying technological change to produce that.

    There are technological changes in the printing industry that are in play. Print On Demand is making much lower press runs feasible for things like books. (And eBooks and POD are disrupting publishing. Traditionally, authors have been able to request that rights to a title revert to them when a publisher declares a title is out of print. What does “out of print” mean when eBooks and POD are in the mix? Current contracts are structured on sales levels, and when sales drop below a certain point it is considered evidence the publisher is no longer actively selling the book and the author can request that the rights revert and try to resell it elsewhere or self-publish.)

    This would go with the fact that a lot of U.S. Eurogames outfits are very light on staff. IIRC, Rio Grande is basically one guy making contracts with designers and production shops; there is somer concern about what will happen when he decides to retire.

    He either brings on someone else to take over, or Rio Grande ceases to exist.
    ______
    Dennis

  57. Dwarf Fortress type stuff would be IMHO an excellent case for what non-Unix-Hackers call Service Oriented Architecture and I suppose ESR will tell us Unix hackers knew that concept and had a different name for it 30 years ago

    Ehhh, not really. In order to do SOA, breaking large systems down into single-purpose intercommunicating services is only the first step. You have to worry about service discovery, registration, and availability. You have to worry about failover and redundancy — what if a service goes down? Who takes the load? You have to worry about standardizing messaging protocols and transports. You have to worry about scale — we have 10 users, do we need to scale this architecture up to a hundred? A thousand? A million? And if so, how? How do we balance the loads? How do we secure the application in depth so if one box on our internal network is compromised, the vulnerability of the others is mitigated? And there’s more — I haven’t even begun to touch on the cloud, VM provisioning, and automatic configuration management yet.

    Unix has nothing to say about any of that. The standards for all that stuff started to coalesce in the late 90s at the earliest. And that’s the hard stuff, the real meat of SOA.

  58. I think the commonalities between “terminal games” and early-microcomputer games (especially on the 8-bitters) have not been sufficiently acknowledged here. Consider the well-known “Lemonade stand” BASIC game which was played on the Apple II, or later ‘TUI’ games like dopewars, which has even been ported to the Linux terminal and included in Debian and its derivatives. The early teletype games like wumpus were obviously a common ancestor (BTW there were plenty of earlier examples, for sure – people started writing games pretty much as soon as Dartmouth BASIC was first made available to the undergrads there!) but there was a lot of independent development, much of it now preserved in tape- and even in diskette dumps for these systems, as well as type-in magazines and books.

    > See the big picture please, while the Amiga had a keyboard culturally it belonged to the keyboardless coin-op arcade and maybe early console world.

    The 8-bitters were just as much a part of that culture as the Amiga was, in fact they were arguably even more invested in it, being de-facto glorified console. (There were some big differentiators though – and obviously text-based games and BASIC were important ones.)

  59. Eric’s pushing TUI as a term of art is a good one, because a lot of what we think of as GUIs had roots in it.

    Old timers may recall when Lotus Development sued Borland over what they claimed was copyright violation when Borland tried to use an interface for their Quattro Pro spreadsheet that Lotus thought was too close a copy to what they did in Lotus 1,2,3.

    Along that line, a chap I knew back in the 80s worked for big financial outfit Vanguard. His users were financial analysts who downloaded real time stock data from Tandem mainframes, imported it into Lotus 1,2,3 for analysis, and then wrote commentary in the XYWrite word processor based on their analysis. My guy implemented a Lotus menu bar style interface in XYWrite’s Help program that tied it all together under one menuing system, and his users didn’t need to be aware of what was happening under the hood.

    For that matter, Borland’s Turbo Vision interface had split screens, resizable windows, and mouse support, and did it entirely in character mode under MSDOS. You can still find apps distributed with the FreeDOS project that use it.
    ______
    Dennis

  60. Thomas A. Fine,

    > Buttons, menus, checkboxes, radiobuttons, and more were all designs that were created for text-only terminals. …

    DMcCunney,

    > Eric’s pushing TUI as a term of art is a good one, because a lot of what we think of as GUIs had roots in it.

    I think that’s a bit extreme, TBH. Late TUI’s were _heavily_ influenced by GUIs proper, to the point that they often benefited from mouse input. But early terminal interfaces were rather different – they were obviously built for exclusive keyboard use, with the one very common pattern being a status bar in the bottom row(s) of the screen listing currently active shortcuts, and modal ‘pop up’ windows or screens were almost invariably used, even for the equivalent of browsing a drop-down menu bar. While _some_ text-based graphics was obviously useful, most of the ‘Turbo-Vision’ elements would’ve been wholly superfluous there.

  61. guest:
    > “I think that’s a bit extreme, TBH. Late TUI’s were _heavily_ influenced by GUIs proper, to the point that they often benefited from mouse input. ”

    I was developing a database interface for computer terminals before the Macintosh existed. The basic library that came with the database, not in itself an interface library, nevertheless contained some of these basic GUI elements, before anybody on the planet was coding GUIs. And the software I was using was rudimentary compared to what other people were doing with terminals.

    Yes, they were fundamentally designed for a keyboard, not a mouse, but the interface needs were the same, and the solutions were so similar that I would argue there was greater influence from TUI to GUI than in the other direction. GUI didn’t so much introduce new interface elements, as it allowed them to occupy more different spatial relations to each other, and pack more of them closer together.

  62. @guest: > Eric’s pushing TUI as a term of art is a good one, because a lot of what we think of as GUIs had roots in it.

    I think that’s a bit extreme, TBH. Late TUI’s were _heavily_ influenced by GUIs proper, to the point that they often benefited from mouse input. But early terminal interfaces were rather different – they were obviously built for exclusive keyboard use, with the one very common pattern being a status bar in the bottom row(s) of the screen listing currently active shortcuts, and modal ‘pop up’ windows or screens were almost invariably used, even for the equivalent of browsing a drop-down menu bar. While _some_ text-based graphics was obviously useful, most of the ‘Turbo-Vision’ elements would’ve been wholly superfluous there.

    The key point I see was a UI that occupied the entire screen. Whether the screen was color, or had actual images or used a mouse for selection was secondary.

    The first computer I dealt with was an IBM mainframe in the 80’s. I interacted with it via the Time Sharing Option (TSO) which provided a command line, and a full screen editor called SPF. SPF used panels as an interface, giving you a full screen display which could define elements you had access to and let you use cursor keys to select the functions you wished to perform. The actual text editor was simply one of those functions. The normal terminal I used was a monochrome 3270 emulator, but real 3270s could incorporate color as well for menu items and highlighting.

    Of course, 3270s were block mode terminals rather than character at a time, but the principles were the same.

    TUIs you could use with a mouse were a later development as mice became wide spread, and rather inevitable, but claiming they were influenced by GUIs is open to question. Individual applications such as word processors and spreadsheets had long provided a full screen UI to permit the users to perform the functions they offered. It was a hope, skip, and jump to a full screen TUI OS shell to make it easier for users to specify what applications they wanted to run.
    ______
    Dennis

  63. TUIs you could use with a mouse were a later development as mice became wide spread, and rather inevitable, but claiming they were influenced by GUIs is open to question.

    Eh, not really. Look at the older TUIs for Microsoft Word for DOS (which did support mouse input) and then look at Word for DOS 6.0. The latter was clearly a ripoff of Windows.

    The same goes for Paradox 3.5 vs. Paradox 4.0 which used Turbo Vision. The Turbo Vision one looks and feels much more like Windows than it does its predecessor.

  64. AlexK

    So there it was Thursday, click on the Glass link. Sometime later “*** Cinderella and the Prince are (eventually) wed ***”

    That was fun! Click on the Bronze link, mess around some and I look up and it’s 9:25 PM on Friday. I think I want to say thanks for putting up Emily Short’s games as a great example. But I think the emails from my boss maybe telling another story.

    They are really amazing and are a good example of how you don’t need graphics to have a great game.

  65. > Eh, not really. Look at the older TUIs for Microsoft Word for DOS (which did support mouse input) and then look at Word for DOS 6.0. The latter was clearly a ripoff of Windows.

    In case anyone else gets confused by initial search results, the transition actually occurred in Word 5.5 for DOS – I had to search for Word 5.0 or earlier for the older interface. (5.1 also apparently existed, and to all accounts had the older interface, but there are no search results for it)

    One thing that is interesting is that word was clearly using bitmapped graphic modes (screenshots show bold, italic, double underlined, and small capital text, and an arrow mouse pointer), but still imitated the appearance of text mode. I assume it could also be used in text mode, so maybe this was to maximize the amount of code shared between both modes. (There are also screenshots out there of word 1.15 using CGA graphics mode, with a much lower quality font and black & white, but all of the features I listed clearly already in place). To bring this longer-than-planned post back on topic, I think this is another possible definitional gap between TUI and GUI.

  66. > GUI didn’t so much introduce new interface elements, as it allowed them to occupy more different spatial relations to each other, and pack more of them closer together.

    It’s interesting that we’re now back to interactive elements being spaced widely apart, at least on phones and tablet computers, due to the extremely low resolution of (capacitive) touch input. (In fact, touch input is so ineffective that the best way of controlling a touchscreen phone/tablet for anything but the very simplest tasks is arguably to use the whole sensing surface as a touchpad controlling a pointer, which some VNC clients enable you to do. This essentially turns a sort of open-loop control into fine-grained feedback control, so it’s no wonder that it’s so much more efficient. I’m surprised that it’s not being supported as an ‘accessibility’ mode in phone and tablet OS’s.)

  67. I feel like bridging the graphics gap here a little by bringing up a few personal favorite roguelikes of mine: Brogue and Crypt of the NecroDancer.

    Brogue, like Dwarf Fortress, uses some graphical programming to simulate a terminal, with the game being displayed using character graphics. But in Brogue’s case, it’s done this way in part to allow vastly greater color depth than terminals tend to allow, so that while a torch in a wall might still be represented by a # like any other wall, the tiles nearby will have a warm glow cast over them that gradually diminishes with distance. Tiles in the upper reaches of the dungeon with sunlight cast upon them will shimmer gently in the light. This isn’t just done for show, though; for example, spreading toxic/flammable gases are a common gameplay element, and the vividness of the gas color in a given area can give an idea of how much longer it’ll take to disperse.

    The Linux port (and ONLY the Linux port) of Brogue can run in an actual terminal, but you’ll lose a bit of information playing that way.

    Crypt of the NecroDancer is graphical but deliberately low-res, in service of a gameplay concept probably that couldn’t be done neatly in a terminal: it’s a roguelike with a streamlined interface requiring only the arrow keys, where you must give your input in time with whatever music is playing at the moment or else lose your turn.

    And since the OP mentioned humor, I’ll just mention that two of the game’s bosses are a grim reaper with a mic stand scythe and a chess army jazz ensemble called Deep Blues.

  68. I’ve noticed the inverse correlation between graphics and plot/story/gameplay myself. I wasn’t around for the terminal games (or, I was off to one side on a DOS box without much awareness of what was going on in the wider geek world), but I do remember the golden age of console gaming RPGs.

    It seems that as the graphics got prettier, the stories got worse – I think conservation of developer effort, and the ease of experimentation is a pretty good explanation as to why. If you’re working with simple sprites, you can do whatever is currently floating through your head after a quick session in a simple image editor that everyone has. If you’re working in text, or you already have all the sprites in question, you don’t even have to wait that long.

    If you want to do something in a fully rendered “realistic” 3d setting, you need a hollywood studio.

    Some modern examples of the paradigm off the top of my head: Minecraft. Graphics are deliberately simple. (Silly-simple). Starbound (old school sprites). (The fact that these games have such a robust dev community is partially because they don’t need a hollywood studio to add things that integrate with the game.)

  69. Robust modding community, I mean.

    You know, one of the programming projects I was doing was a simple game using the DOS rendering of ASCII characters as “graphics”, which was probably very similar to a (simple) roguelike.

    It’s pretty weird how much geek culture my brother and I independently reinvented unaware that such things existed in the wider world. Pen and paper RPGs were something else that we had absolutely no idea was a thing that other people did until we had more internet exposure in undergrad.

  70. Please pardon me, this is a little off-topic.
    Years ago (ten or fifteen, maybe) I briefly played a text adventure game provided via a telnet connection to some server. I don’t recall the name of the game or the server address. Early in the game, you encountered a dragon, which would fry you to a crisp unless you apologized for disturbing it. Does anyone know the name and whether it’s still around?

  71. In re the inflection point of “atomic gaming” (as opposed to “electronic gaming).

    I read a design article by Steve Jackson about the Car Wars Card Game (“Card Wars”) that stated one of their design constraints was the card count had to be a multiple of 52, because all the card printers of the time were set up to do “poker” decks; and non-standard card-count sheets were significantly extra. M:tG and the CCG explosion of the first half of the nineties changed that. I also

    (The article was almost certainly in an early issue of Pyramid, which means it’s behind a paywall today; and I don’t feel like looking it up)

  72. I also don’t think it’s a coincidence that the rise of “eurogaming” was coincident with the rise of commercial internet access. When the customer>printer leg of the development cycle is no longer shipping atoms, (and large chunks of the printer>customer leg in the early iterations of the cycle); that means you don’t have to stay “local.” China can do it cheaper, true; but it’s not slow-boat slow/costly to iterate your design either.

  73. >There is a term of art for this, not yet common but I’m trying to propagate it because it’s useful: TUI = Terminal User Interface, in both similarity and contrast with GUI.

    TUI really should stand for Text User Interface, precisely for contrast with GUI. It hearkens back to the text modes of IBM-compatible video adapters (in which they still initially boot), which are contrasted against graphical display modes.

    (Or make it a multiple-choice initialism.)

Leave a Reply

Your email address will not be published. Required fields are marked *