Note: I originally sent this reply straight to Stephane by accident -
sorry Stephane. In case this isn't just my mistake, I suggest people
double-check that they're replying to the list rather than individuals
for the next few days.
On Tue, Oct 25, 2005 at 10:04:26AM +0200, Stephane Magnenat wrote:
> Hi,
>
> > Since each player has to receive orders and execute a tick
> > before it can send orders back to a server, you're just as likely to
> > wait for a player with a client/server model as peer-to-peer.
>
> Not with a thin client model where only the server does execute the game
> logic. Such a model also allows a client to reconnect after a crash or join a
> running game.
That only works if commands don't have a specific execution time,
they're just executed whenever they turn up. Although you'd have to
take steps to ensure low-latency clients didn't get an unfair advantage,
this does strike me as an advantage of a client/server model.
As for reconnecting after a crash, it strikes me that a better solution
would be for the game to be saved when one player goes offline, then
restored when he gets back. I'd be quite annoyed if I got back to a
game after 5 minutes, only to find that the AI appointed to run my team
had left my colony in a mess.
Saving and restoration would work with any network model. With a
client/server model, all is lost if the server crashes. Because a
peer-to-peer model has all the game's state information on every
computer, the loss of any single peer should be recoverable. However,
if a peer that crashes was hosting an AI, the AI would be unable to
restore its internal state information. I would expect that AIs can
recover from that by starting again as if it was a completely new game,
but I don't know enough to say for certain.
- Andrew
_______________________________________________
glob2-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/glob2-devel
