Re: Online games

[Erik <br0ke@math.smsu.edu>]

On 10-Mar-2000 Pierre Phaneuf wrote:
> 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.
> 

I talk about games.yahoo.com and microsoft game zone like they provide an
interface for users to find a game, join/start a game, track ladder
information, and allow 'chat'. I don't beleive I claimed either was a generic
meta-server :) yahoo uses cgi's and javascript to launch the game (all of them
are java iirc). The m$ one provides an interface that uses parts of IE for
transfers and info and I THINK the server has small chunks written per game and
plugged into the larger setup. the m$ one will allow people to start games that
were not written for it (like mechwarrior2/3, quake, halflife, etc), and
provides a medium for the user to select a game, confer with other
participants, and launch a multiplayer game. That's exactly what a meta-server
should do :)

> 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.
> 

I disagree, I think a generic server would be better. Each game can figure out
what it's supposed to display (using a dandy api), and the user is presented
with what the game developer intends, and automatically slapped into the
metaservers display. I smell XML :)

> 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!
> 

When a use wants to play chess, they select the chess icon or 'room' if you
will. I think the most intuitive way to think about a metaserver is a building,
each room is where one specific game is played, in that room are several clumps
of people. When you want to play quatra (yaftc), you go into the building, go
to the room for tetris wannabes, and find some ppl to whup ass on. It could be
further catagorized with different 'halls' for different genres. So I load up
GameGuru, and feel like pounding some poor snot into mush, so I click "first
person shooters", which gives me a list (qw, q2, q3, ut, csdemo413, ...), and I
click the one I want. Joe blow the end user likes 20 different online games, so
now he has one icon for when he wants to play a game, not 20. He clickes
"games" and it asks him the genre (with pretty pictures).

> 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.
> 

administation is not an issue, the idea is to make it easy for a game player to
jump in the mix. If the server doesn't use outragous resources and doesn't
require a lot of effort, admins won't have too much of a problem with it.

> 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.
> 

in yahoo, you start by selecting your game. In the game zone, you join the
zone, then choose a game inside of that. I think m$ almost did something right
for once.

> 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.
> 

If 'games in progress' are to be monitored, I don't think a 'heartbeat/status'
would be too awefully expensive. Even games with 50 users could fit a
presentable amount of information into single udp packet...

> 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
> 

I'm seeing an icon on my desktop. I click on it and a window pops up shows me
buttons for different kinds of games... board games, card games, RTS games, FPS
games, flight sims, etc. I click on 'card games'. Now I have a bunch of buttons
like poker, spades, hearts, 52 pickup, etc. I click on spades (cuz my fiance
digs it), and I see a bunch of 'tables', some of them have open seats, some are
closed. I click on a table with 3 ppl sitting at it, and one of them's a
friend. My spade program loads up and connects to the server for that spade
game, while the meta client either dies, or disappears and puts itself to
sleep.

On another day, I have korn and limp bizkit blasting on the stereo and can only
think about blowing shit up. So I click the icon on my desktop. I pick FPS
games, and I click q3. I see 80 games going, so I look for one on a map I like
with a good ping. I lcick it, the metaclient goes away, and I see a big Q with
a couple extra lines, followed by explosions and breaking stuff :)

I think at a stage like this, the internal implementation is less important
than the overall user interface. The server could be loading dll's and talking
to the game servers, the game servers could be sending the players xml goodies
that tell him/her what the deal is. It may require the games use a special API
to announce stuff and accept players. It may be that the programs information
has to be entered somewhere much like netscapes 'helper' crap. The
implementation of the idea is secondary to the idea... And I think the idea
allows for game specific interfaces to be generated for the meta server. I
THINK m$'s does it by passing info with some kinda 'enriched' html, and the
images are loaded off the server then stored on the players hdd. It's been a
couple years since I've seen it (the neatest thing was it also used a voice
chat proto. The peice that pissed me off was it used some IE components, so ya
needed IE installed).

        -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.
        

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