2 ms·

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

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.

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

emmanueloga_ 4y ago

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

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