Re: Online games

[Pierre Phaneuf <pphaneuf@sx.nec.com>]

Erik wrote:

> I think that each game having its own online server (like quatra,
> for example), or very limited sets of games having a common server
> (I smell battlenet) are *BAD* things :) All a meta-server like this
> has to do is get the end users into communication.

You talk about games.yahoo.com or the Microsoft service (the Internet
Gaming Zone, or something similar). They are very similar to Battle.net
actually, with a limited set of supported games. They are *not* generic.

And anyway, while there are a few generic parts in a meta-server, a good
meta-server is *not* generic, it has game specific features, like ways
to show you statistics on ongoing games.

When you think about this, a generic meta-server makes almost no sense
for a user! A player want to play Quadra or chess, he starts his Quadra
program or chess program and browses the games of this type only. It
wouldn't make any sense to see Quake and othello servers in the list the
meta-server gave them!

It makes sense for a site administrator though, who doesn't want N
separate processes and open ports on his server, but would rather like
one big program that incorporates multiple games. This is like Netscape
Communicator supporting HTTP, FTP, Gopher and other protocols, all
rolled into a single program, but from the server side instead of the
client side. For a server, it saves resources to have a single program
handling multiple games.

For some cases, like the gaming web sites (like games.yahoo.com), it
might look like a generic interface to multiple games on a single
meta-server is going on, it is not really: you start by choosing your
*game*. It is just that the game itself is a web application, but that's
different than the meta-server.

Don't get me wrong, a generic meta-server *is* possible, but could be
either under-featured, or would be slow. If all the meta-server would do
would be keeping a list of servers, it could be generic. But a game
fetching just the list of server would then have no information beside
the list itself to present to the user, or would have to fetch the
specifics from each servers. This might be okay.

Also, a more flexible generic server might support attaching some
arbitrary data to the server entry, that the specific game would
interpret.

Another idea that I had was to make a server which would have an initial
handshake protocol that would enable a client to query what
sub-protocols it supports and start one of them, which would make the
server hand the connection to a plugin (in the same process, to save
resources, loaded with dlopen() or similar) which would run the show
afterward. This could be done on multiple levels, with a meta-server
sub-protocol that would be a "generic" meta-server, but would also
support sub-sub-protocols for the specifics to each games.

This would enable a single process to be both a server and a meta-server
for multiple game types and multiple games at once!

But even with all those ideas for a generic meta-server, all this thing
has "generic" is the code. The user interface would still be specific to
each games, and I think it should stay that way. The user chooses a game
on his machine, *then* chooses a server, not the two at the same time.

-- 
Pierre Phaneuf
Systems Exorcist

---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk