Hacker News Reader

Comment by dllthomas | Hacker News Reader

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

View on HN

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

0: https://github.com/mattbierner/Super-Template-Tetris

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 guess you are right, but a non turn based game would require some way of saving state at least right?

Either through a savefile:

    $ play -savefile somefile.sav -moves run,run,jump

... Or maybe using some sort of "cookie":

    $ play -cookie "perico" -moves left # outputs "perico42"

    $ play -cookie "perico42" -moves left # outputs "the-new-encoded-game-state"

In your case, it seems like the purple server was holding the game state.

Another idea is to make a deterministic game, then allow the user to expand the input one move at the time:

    $ play -seed 314 -moves left

    $ play -seed 314 -moves left,right

    $ play -seed 314 -moves left,right,up

    $ ...

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

Yes, I came here to say this, these are not command line games.

I'm tempted to make some kind of gimmick website or Twitter account, "Not Command Line", which posts examples of this confusion...

MUDs took over your terminal but it's not hard to imagine one that works like https://tools.suckless.org/ii/

Yep. Usually I hear this stuff called TUI rather than CLI.

Reply on news.ycombinator.com