I'm going to hijack this thread and mention the modern spiritual cousin of terminal games (but not really a terminal command line game at all) "Caves of Qud"
It's like Nethack, only weirder. In a good way. Don't let the Early Access label fool you. It's been around for seven years already and is highly polished, and getting weirder all the time. In a good way.
Nitpicking, several years after the fact, but: most of these are not "command line" video games. They're terminal (and terminal emulator) games. "Zork", or even "Quest for Glory" are command line games: you play them by typing on the command line. The ones shown here (save Frotz) are not that.
I do recall starting my comment with the explicit note that I'm nitpicking.
If, to you, "command line games" just means "something I can run while in a terminal" then cool, but that's not technically what that term means, and we're technical people here on HN. Especially those of us who use (any flavour of) the terminal day in day out.
I think a lot of the time that's basically synecdoche and unobjectionable. Other times it's confusion and that matters when it matters, outside of which it can be nice to clarify... if it can be done respectfully.
In this case, though, it's writing in The Linux Journal, and it appears to be promising something it's failing to deliver.
Then the reasonable thing is to educate these people, since they are in no way[0] equivalent. Words are supposed to have meaning, so you know what the hell people talk about.
It's not hard to use the correct terms, and something that tries to be an authority on, say, Linux, such as Linux Journal, could simply do so instead of spreading confusion.
[0] OK, there's some equivalence between a few of the words.
Exactly. "Letting it slide" is how we end up being told that because for most people a "hacker" is a cyber-criminal, it is now the sole valid definition.
I think an example of a theoretical command line game would be one that a user would pipe a command though the shell in to the game and get the resulting output.
I think IF games are solidly "command line games" - it is a game that you interact with entirely through commands you type at a... line...
Games you play at "the command line" - or, as the article puts it, "expansive and impressive games that you can run entirely in your Linux shell," is an interesting notion. I'm generally a big fan of decomposing actions out of applications into individual commands run at the shell; I had not applied the same to games.
You could run the game itself in a long running process, talking through (unix?) sockets that the individual commands know how to find. Polling in PROMPT_COMMAND could make it sufficiently interactive for some measure of real-time.
I would have to begrudgingly agree that cli games would include all infocom games would be command lines games since it doesn't have to be constrained to the command line shell like /bin/sh
I forgot to mention after my comment "play by email" games which would broaden the scope to network games since the interface could be through a shell when using sendmail.
Play By Email seems marginal. It's certainly true that you can do it from the command line (I'd heartily recommend nmh over using sendmail directly), but it's sort of incidental rather than by design. That said, I'd count it.
I agree. What I think makes PBEM marginal as an example of "command-line-only" is that it is designed with email in mind as the interface, and it is only because we have command line access to email that we have command line access to the game. As I noted, though, I still think it counts.
Last time I played (few years ago) there seemed to be some controversy about the direction the project lead was taking the game. Something about realism over fun. Did that ever get resolved in some fashion?
Been a while for me unfortunately, that dichotomy is not particularly new to games of this genre and I think the lead's done a reasonable job at balancing it; there's always mods that push it further in either direction.
The first time I used a computer was also the first time I played a computer game. And I'll call it a "command-line" game as it was played on a teletype machine.
"Star Trek" first came out in 1971. I probably played it in 1972-3 when my father brought home from work a teletype machine. All I remember doing is launching a photon torpedo and destroying a planet. For me it was (and still is) the best command-line-only game.
Am I nitpicking to point out that there's no such thing as a "command-line-only video game"?
Giving credit where it's due, the article mentions Infocom (to which I'd add -style) interactive fiction, which I think solidly count as command-line-only video games even if the command line in question is internal to the game.
The interface for one of those games is entirely text (sentences, not ascii art) presented before a prompt where you type a command, which will provoke more sentences and another prompt. I think it's perfectly legitimate to call that a command line, even if we might want to distinguish it from "the command line".
I came here looking for DCSS. Anyone who likes roguelikes should take a look at it, if they haven't.
It's actively developed, so you can play it once, come back a year later, and there will probably be new things to try.
There's an active community, you can play over SSH with ASCII or over a webapp with tilesets or you can run it standalone on your PC.
Magic, extremely varied gods that favor you with powers for your devotions (these can have a drastic impact on playstyle), huge variety of classes... I could go on.
Yes! The game itself supports [PRINT_MODE:TEXT] in the ini. Depending on the version you might need a virtual x server to trick the game into starting though.
Used that to run it via wine + quemu on my android phone, at a whopping 5fps at embark. Didn't play for long, but was totally worth it!
I feel like Wikis and modern communication tools in general have made Nethack less fun. Nethack represents one extreme of roguelike design philosophy, where the focus is more on exploring and discovering things than solving tactical puzzles. The phrase "the dev team thinks of everything" illustrates this well; the game is full of interactions that are fun to discover and add to the illusion of exploring a world, but don't actually contribute to winning or losing. You can easily break the game, i.e. find techniques that make large parts of it pointless, and that's acceptable because the joy of discovering them makes up for that loss. If you read Wikis and watch expert players then you will never experience it and be left with only an easy and boring game.
The other end of the spectrum is DCSS, which sacrifices this sense of wonder to produce a tightly designed tactical challenge. There's little need for an external Wiki because that kind of information is built into the game. You can look up any entity in the game and get detailed information about its abilities. All useless/boring/unbalanced interactions are removed even if that makes the world less believable, e.g. you cannot sell items to shops, because that would necessitate tedious tracking of all junk items to recover their value, and the traditional roguelike "food clock" was replaced by an explicit countdown clock, because optimizing food usage so rarely made a difference (Nethack includes food, but also many methods to make it irrelevant). Assuming a skilled player, DCSS is the more difficult game.
I recommend playing both, but in the case of Nethack, only if you keep spoilers to a minimum. (Zero spoilers is unnecessary. I believe the game was originally designed around the assumption that players would be sharing information about how to win. Only improved communications have made this sharing too powerful.)
Weird to have a list of command line games and not even mention nethack. Like maybe its not interesting to mention because everyone knows it, but still.
It'd be like having a list of best fantasy novels and not mentioning lord of the rings. Its just odd. Even if you disagreed, its so famous that they would probably say why they dont think it doesn't make the list.
On this topic, there is still a community of players and creators around adventure games (or 'interactive fiction'). Check ifdb.org for reviews and recommendations.
I'd say modern IF games are often more playable than classic games, which are in some cases really unforgiving in this particular genre.
These are some of the games I would recommend: 'Fate' by Victor Gijsbers, 'Floatpoint' by Emily Short, 'Galatea' also by Emily Short, 'Photopia' by Adam Cadre, 'Aisle' by Sam Barlow, and 'Nightfall' by Eric Eve.
There's sixel [0] to display pics in text terminals. Also apparently the kitty terminal has a custom protocol to blit graphics on text terminals too [1].
There's a library with some impressive demos called "notcurses" if you are curious what kind of graphics can be displayed in a terminal ... the author uploaded some demos to YT showing the capabilities. It's been discussed in HN a bunch of times [2].
Pretty fascinating, I found the tip of the iceberg on XTerm's src [0] but it's kinda table driven so hard to tell what's going on :-). I just wanted to see exactly how much code was there in XTerm to support hardware that was popular between the 70s and early 80s.. [1]
Ages and ages ago I wrote a 'ppmtotek' program that would display raster graphics on terminal emulators with Tek 4014 graphics. It worked somewhat but depended on quirks of the specific terminal emulator. I should dust it off anyway.
After some fiddling I have built Moon Patrol on macOS. I was curious why a text mode program requires X11 and libpulse libraries. I had to install xquartz.
But overall, I salute the author of AsciiPatrol ;-). Kudos!
Was that the one you start at the bottom of Moria with all the monsters sleeping as level 1? I can remember playing it but I can’t find it on the variants page
Personally I enjoyed IF like TATCTAE (Time: All Things Come To An End), Jigsaw and Curses! which where included in early GNU/Linux distributions (unbeknownst to me at that time that much other int-fiction was being created, since we were exploring the OS distributions offline, InfoMagic CDs etc.)
Before that, BBS door games existed (much avoided because exhuberant dialup costs). Typing in BASIC source code from books lent from the library (mostly text-based games). My interest was piqued by MUDs at one point afterwards, but never really got active (again because of dialup costs to connect to the Internet).
Nitpick, maybe, but I think it's worth maintaining a distinction between "terminal (or terminal emulator)" and "shell (or command line)".
From a skim, these seem like games that run in the terminal usually spawned from a shell, but that is not the same thing as being "run entirely in your Linux shell."
For the headline itself I think IF with a parser counts as "command line only", though it still doesn't run in your shell.
I don't know of any games that run "in your shell" but a good example of the distinction is that mutt and pine run in a terminal, but nmh actually runs in the shell (not in the sense of processes but in the sense that the shell is what I am using to string together actions when I use nmh).
Agreed... by nature a "command line game" would have to be turn oriented, I think. I was curious what kind of games where going to be linked here. It seems is mostly games that run on "text mode" on a terminal, as opposed to turn based games using the command line as UI.
Counter example: command line tetris! [0]. Although... still gives the player the advantage of "freezing time" on every move :-).
It doesn't need to be turn based, though it does need relatively self contained actions and avoiding unfortunate race conditions could be tricky.
I once made a shell driven instant messaging (libpurple) client that could serve as a point of reference - incoming messages were reported with PROMPT_COMMAND, and reply would send a message to the sender of the last message reported rather than the last message received.
I think you'd generally want a long-running process that your individual commands interact with, probably over sockets. I've played around with that model a bit in a few contexts, though haven't written any games yet.
sure, although in the context of a "command line only" game, using a daemon feels a little bit like cheating :-)
Ok, so... a cmd line game:
* receives as input plaintext (the cmd line to be parsed)
* outputs plaintext in some format, perhaps just colorless text, but I imagine it could output something more interesting too
(JSON? SVG? Dotfiles? As long as it can be printed as plaintext or ANSI text! It is also possible to read, say, Dotfiles without rendering them, so ...)
* is not necessarily stateless (requiring the use of file or cookies to save state between runs), it can also make use of a daemon if necessary.
It my mind, the smaller the state that the game needs to run, the more impressive the game would be (assuming it manages to be a fun game, as opposed to some sort of technical demonstration).
On the one hand, I think as definitions go "command line only" game should focus on the interface; daemons (or similar) should be used where appropriate.
On the other hand, I certainly agree with you here:
> the smaller the state that the game needs to run, the more impressive the game would be
But that's on a slightly different level than "is it a command-line-only game" and "is it fun".
https://store.steampowered.com/app/333640/Caves_of_Qud
It's like Nethack, only weirder. In a good way. Don't let the Early Access label fool you. It's been around for seven years already and is highly polished, and getting weirder all the time. In a good way.