|
|
Posted by Leif K-Brooks on 05/21/05 17:57
I'm in the process of coding what amounts to a Web-based multi-player
RPG. An important feature will be player-versus-player fighting. Since
the players in a fight will never move instantly (or even close to it),
there will need to be a way to inform players when their opponents have
made a move.
The most common implementation I've seen is using the Refresh header
(possibly simulated via http-equiv -- ew!) with a period of around one
refresh per second. When the opponent has moved, the page stops
refreshing and displays the results of the turn along with a form for
the player to make their move.
This approach has a few problems: it's non-standard (although
widely-supported, the Refresh header isn't in any HTTP spec), the
constant reloading can cause high server load, and it takes at least one
second for a player to be notified of their opponent's move (since
that's how long it takes for the page to refresh).
One alternative I've thought of is having keeping the HTTP connection
open until the opponent moves, so that the page would look like this:
------------------------------------------------------------------------
<p>Your opponent is moving, please wait...</p>
(The page will stop loading at this point, but the connection will stay
open. When the opponent moves, the loading will continue:)
<p>Your opponent, <strong>Big Meanie</strong>, has kicked you in the
crotch doing 30HP of damage.</p>
------------------------------------------------------------------------
Unfortunately, this approach has a few problems of its own: the user
might be confused by the page continuing to load even when nothing
appears to be happening; some proxies would probably only send the user
the page once it has been completely sent by the server (which could
take over a minute in some cases); some browsers might timeout the
request after a while; also, this approach would work with an
asynchronous server, but wouldn't work so well with a multi-threaded or
multi-process server (since the whole thread or process would be tied up
until the opponent moved).
Does anyone have suggestions for approaches I haven't thought of?
Accessibility is a concern, but I recognize that this might be something
that simply can't be done in every environment, so my biggest concern at
the moment is usability in common visual browsers.
Navigation:
[Reply to this message]
|