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".
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).