[MUD-Dev] Remote client connection

Caliban Tiresias Darklock caliban at darklock.com
Fri Jun 16 15:46:51 CEST 2000


Kyle Leithoff wrote:
> 
> Rather than have a character removed to storage when a player logs out,
> would it be feasible to allow updates to be sent via a pager or cell
> phone of what's happening to a character, then allow that player to
> modify the characters behaviour through the cell phone?  I guess working
> somewhat like stock trading and the updates you can receive now.

For my project, which is admittedly not even *intended* to be the state
of the art in gaming, I'd stop at the first half of this. I would like
to send the player updates at a configurable frequency: a player might
say "tell me what happens to me every morning", or every six hours, or
even *immediately*. With all options, email would be dispatched at the
appropriate time with a little report of what's gone down since the last
communication. 

Of course, unlike most modern games, I encourage players to fuck with
one another even while their opponents are offline. Your in-game persona
is still there, and anyone determined enough to find it and smart enough
to launch an effective assault can easily kill you in absentia. Without
this feature, I wouldn't think email alerts are that important. 

This relates in that many pagers and cell phones allow you to retrieve
and read email, and even more of them allow pages and text messages to
be emailed to the phone. 

> Would this be something that you'd want to do?  Would the added
> resources to support this outweigh the niftyness of the feature?  This,
> from what I can see, would only add to the average connection time of
> players.

I've been trying to figure out a way to kill the whole connection time
thing, running the whole schmear via stateless connections. The server
saves state, and the client requests updates. No logins. No disconnects.
No idling for long periods and using resources. Just consider everybody
logged in 24-7 and send updates when requested. My major obstacles in
this are security and efficiency. I haven't come up with viable enough
solutions to consider this something worth discussing in depth or
attempting to implement just yet.



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list