SSH/Telnet support?

[Danfun64]

I'm not sure if this is too much to ask, but can you add support to connecting to a web brogue server through (preferably) a 256-color terminal, or even a standard 16-color terminal when necessary?

[kipraske]

I agree that this would be a great feature! However, the current architecture really doesn't lend itself to doing this very easily.

The current implementation creates an interface directly between the brogue code and the socket that sends the data to the client. The client then interprets this data cell-by-cell to render the output in the web browser. The easiest way I see then to to play over the terminal would be to rewrite this web-platform.c to send the data in a more terminal-like way, which probably would look like a stream of 34x100 characters marked up for color. We already have the curses platform with the original brogue game, so terminal support is certainly possible already.

Now I said that was the easiest way, and that requires changing the whole output interface. The current way is quite efficient. We only send data needed for the cells that need updating. In addition the brogue code itself has been modified to send some additional data about games to help implement all sorts of great stuff. If we add ssh/terminal support we would certainly want to keep these things too.

Alright so how does DCSS webtiles work? The short answer is that because DCSS is fundamentally a console game, the ssh online play over the terminal came first. The following is how I think it works since I used it as a model for this project, but I could be wrong about some things so bear with me.

Because it was able to be played in the terminal already someone figured out that you can record games using the TTYRec protocol which is used for recording terminal sessions for playback later. Next people created the tileset which is just a tile-mapping of the characters that get displayed in various sections on the screen. Because in crawl you have a separate map section, a separate player stat area, and a separate monster list area that all get rendered from different classes, these were easy to hook up which areas needed tiles and which areas could stay relatively console-like.

So then the key of webtiles came from all of these points together. Because crawl already could easily make TTYRecs, the webtiles server just starts recording these TTYRec files. When the file gets updated the server knows that we need to get more data. So it triggers the seek of data. Because each section is handled separately in the code you can send exactly what needs to be updated on the console. If your health goes down, the health number is passed to the client rather than trying to render each of the pieces of the bar separately like brogue does.

So, that was my long winded explanation for why this probably won't work with this project. The best way to implement ssh terminal play with brogue is to probably ignore what we did here and create server scripts like DCSS did more than a decade ago. You would want to use the curses implementation so you could play over the terminal. The curses implementation is really ugly since the colors just get mapped to the 256 color approximation, but it works. I will leave this open since I bet other people have wondered the same thing.

[tomford]

Hmm, I might try keeping the brogue <-> node.js server interface the same and support terminal as an alternative to websockets to communicate with the node.js server.

You'd need node.js to act as an ssh server (https://www.npmjs.com/package/ssh) and potentially might want to alter a terminal library (https://github.com/chjj/blessed) to deal with outputting to the ssh client.

This would have interesting functionality like using ssh to observe a game being played on the web etc.

I'm not interested to actually do this project, but it is an interesting project :)

[Danfun64]

I decided to record a video showing a termrec recording of a terminal brogue session (not ttyrec, as it doesn't like recording brogue...though ttyplay works with the telerec recording). Also in the video is playback of a corresponding .broguerec file.

https://drive.google.com/file/d/0B8lbmaOG_ORKTkpNdkg1cGFESkE/view?usp=sharing https://drive.google.com/file/d/0B8lbmaOG_ORKNWlWc3lJWTlFLTQ/view?usp=sharing

[Danfun64]

I just discovered this. https://asciinema.org/ It actually records terminal Brogue properly

https://github.com/asciinema/discussions/issues/10 lists the attempt at a proper implementation of networking, but it lists a few work arounds (like "gotty and screen + Ngrok" and "shellinabox and tmux")

http://blog.asciinema.org/post/two-point-o/ lists the following

"${benaryorg}" • 10 months ago A great opportunity to bring up the little known tail idiom: tail -fn +1 file

With that you can effectively output an entire file while still tailing it. That means you can stream without any complicated pipe setup:

# record

asciinema rec file.cast
# play
tail -fn +1 file.cast | asciinema play -
# play via ssh
ssh example.com tail -fn +1 file.cast | asciinema play -

Edit: for lots of output (e.g. coloured stuff like syntax highlighting in shell or editor) I recommend putting a buffer in between to account for network latency and such:

ssh example.com tail -fn +1 file.cast | pv -qB 8m | asciinema play -

Edit2: should be all uppercase -B in the pv invocations

Edit3: and there's the fitting cast: https://asciinema.org/a/163778

Edit4: the ssh-streaming part should also be applicable when streaming using e.g. netcat or possibly(?) RTMP (curl & nginx both support that)