3 ms·

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 bi

• emmanueloga_ 4y ago
  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).
  • dllthomas 4y ago
    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".