Other than writing my own sshd code, the only thing I could see would
be to have a special user account that had dgamelaunch (or similar)
set to be its default shell, and just have people connect to your sshd
and log in under that account (this was completely unsuitable for my
needs, btw).
> I'm asking this more out of curiosity than anything else, as I've
> already solved the problem myself, but how many people have attempted
> to provide an ssh interface for their roguelikes to be network
> accessible, and what have you come up with?
Practically all traditional roguelikes are playable through ssh. You
just ssh to a server on which the game is installed and run it. Nothing
needs to be added. If your game is graphical, you probably have to be
running an X server and do ssh -X, but that's a detail.
> Other than writing my own sshd code, the only thing I could see would
> be to have a special user account that had dgamelaunch (or similar)
> set to be its default shell, and just have people connect to your sshd
> and log in under that account (this was completely unsuitable for my
> needs, btw).
You can just put the game as the default shell, without any additional
helper programs. By the way, no need for ssh in this case, telnet is
sufficient, you don't need encryption as there are no security concerns
(at least as long as the game is not exploitable, but ssh wouldn't help
if it was anyways).
--
Radomir Dopieralski, http://sheep.art.pl
It's the compression that justifies using ssh. Twilight runs a lot
more smoothly (for me, anyway) with ssh than it does with telnet.
--
Gamer_2k4
Of course you can run arbitrary programs from within a shell. That is
hardly a revelation Sheep.
> > Other than writing my own sshd code, the only thing I could see would
> > be to have a special user account that had dgamelaunch (or similar)
> > set to be its default shell, and just have people connect to your sshd
> > and log in under that account (this was completely unsuitable for my
> > needs, btw).
>
> You can just put the game as the default shell, without any additional
> helper programs. By the way, no need for ssh in this case, telnet is
> sufficient, you don't need encryption as there are no security concerns
> (at least as long as the game is not exploitable, but ssh wouldn't help
> if it was anyways).
>
> --
> Radomir Dopieralski,http://sheep.art.pl
Some people have expressed concern about playing my game over telnet,
so there are people who care about the encryption. There's also the
issue that most of the time you don't want a telnetd running on your
system, but an sshd is standard issue.
You're correct that you can use the game itself as the shell. I was
thinking with nao or crawl.akrasiac.org in mind, where dgamelaunch is
desired for other reasons.
Sporkhack's main public server runs this way, as does Crawl's. I don't
see why this should be all that unsuitable unless you've got some sort
of strange need you're not telling us about here; it is both secure and
simple, and can be advertised trivially on one's website along with the
other methods of connection.
--
Derek
Game info and change log: http://sporkhack.com
Beta Server: telnet://sporkhack.com
IRC: irc.freenode.net, #sporkhack
Because it's a multiplayer game, so everyone having separate copies of
the executable running is far from the best/nicest way to do it, imo.
Much nicer to just be able to connect to the server itself.
Like I said, I was just curious what others do.
> On Feb 6, 2:53 pm, Derek Ray <de...@moot.its.only.a.spamtrap.org>
> wrote:
>> On 2009-02-06, twinks...@gmail.com <twinks...@gmail.com> wrote:
>>
>> > Other than writing my own sshd code, the only thing I could see would
>> > be to have a special user account that had dgamelaunch (or similar)
>> > set to be its default shell, and just have people connect to your sshd
>> > and log in under that account (this was completely unsuitable for my
>> > needs, btw).
>>
>> Sporkhack's main public server runs this way, as does Crawl's. I don't
>> see why this should be all that unsuitable unless you've got some sort
>> of strange need you're not telling us about here; it is both secure and
>> simple, and can be advertised trivially on one's website along with the
>> other methods of connection.
>>
>
> Because it's a multiplayer game, so everyone having separate copies of
> the executable running is far from the best/nicest way to do it, imo.
Out of curiosity, is the original post also yours, just with a different
user name?
> Much nicer to just be able to connect to the server itself.
I think it's much easier to still just start separate clients as user
shells (or whatever), and have them communicate locally through one of
available mechanisms: pipes, sockets, IPC, maybe even high-level stuff
like dbus. At least you don't have to run around importing patches from
the ssh server you based your own code on.
Y'know it'd be quite nice if someone could do a RogueBasin article on
this. Terminal access to roguelikes is fairly popular, and a nice way
of improving portability and making it easy for anyone to play (along
with things like combined high score lists etc). I'd quite like to
try it out myself some day, but haven't a clue where to start.
Perhaps someone knows of helpful guides written for MUDs and the like?
--
Darren Grey - http://gruesomegames.com
"It is pitch black. You are likely to eat someone..."
Oh, that sounds like a very good way to do it. Perhaps I will have to
investigate that sometime. Thanks!
That's very true. But it doesn't fit my own personal sense of
"niceness." If I had started from scratch it may have been less of an
issue, but I was adding ssh support to a game that was already 2 years
in development, so there was a lot of code already set up for handling
connections and such, and I really didn't want to have to revamp it
all. It also would mean that the users would have to log in to the
server with an existing user account that would not match the login
credentials for my game itself, which would be confusing to them. I
think there's also a limit to the number of processes my shell host
allows me to have running at one time, so I think that would be
problematic there too.
Also, I didn't base my code on anything, so I don't have to import
patches. I just grabbed OpenSSL and the SSH RFC and wrote it from
scratch.