------------------------------------------------------------------------------- From: John Carmack To: jep@sclsis.navy.mil Cc: cookti@jaxmail.navy.mil Subject: Quake World Date: Wednesday, August 07, 1996 11:03 AM Qspy is cool. Want to be the official front end for the QuakeWorld project? I think the initial research releases of QuakeWorld are going to be native win32 apps only, and they will listen on a control socket, so an external windows app can very nicely send them from server to server. If you are interested, I can go over the new features we are considering that would be pertinent, and solicit some opinions from you. John Carmack ----------------------------------------------------------------------------- From: John Carmack To: "Joe E. Powell" Subject: Re: Quake World Date: Wednesday, August 07, 1996 01:36 PM Ok, the basic structure looks like this: A single master server running at a well known address at idsoftware.com. Freely available client and server win-32 executables. The servers do not require well known port numbers, because they register with the master, so you can just start up ten servers on a pp200, one after the other. When a server is started up, it configures all of its options, then sends a heartbeat out to the master to let it know it is alive. Heartbeats are sent once a minute, and contain all server information, a list of all connected clients, and all of the frags that have taken place in the last minute. They are udp packets fired into the void, so I'm not guaranteeing 100% accurate logging, but it should do just fine for all my purposes. External programs can request information directly from a server, but because they won't know the port number, they will generally be forced to ask the master for at least an address. (they MUST go through the master to connect to a server, they can't just go there directly) Any program can request current server information from the master. I'm still unsure exactly how I want to handle this. I want to have a rough idea of how to scale this setup to around 1000 active servers and 5000 active users, which impacts options a bit. In addition to the current quake info (level, current users, max users), the master will also have a set of key/value pairs from the server that can be used for arbitrary information, like which skill ranks are allowed. I am currently torn between having some form of a query sent to the master to pare down the number of returned servers vs just dumping some form of the entire list to let the client search it. I am leaning toward the dump-the-list aproach, because I know I can change it if it looks like it is going to get overloaded, and it gives max flexibility. Comments? The master will also be able to return the public information for any userid, so you can print out proper named rosters for each server. It will be cool to be able to find out if any of your friends are playing on servers anywhere in the world. User accounts consist of a user id, a password, and two sets of arbitrary key/value pairs. The user modifiable set will be for name, color, clan, etc. The protected (master-modifiable only) will be for rankings and other read only rights that can only be changed by the master server. I don't know all the things we are going to want to try, so I think the unstructured pair lists will give the best flexebility. When a user requests a connection to a server, the master sends their account information and ip address in a message to the server they requested. Servers ignore connect messages from any address but the master. The individual servers are the final authorities for admission of a user. They can accept a user connect command from the master, and simply refuse to honor it for whatever reason (wrong rank, on the banned list, etc). There is an internal ping command in the servers, which should be used over a regular internet ping for quality testing, because the turnaround time for it will also be somewhat influenced by the current server load. There is a "logon" protocol message to the master that returns the current userdata and masterdata for an account if the proper password is given. It isn't really establishing any connection, because you must present user id and password for the connect The first real game extension that I want to add is a centrally administered ranking scheme. Start everyone at private, and let them advance. This gives everyone something to achieve, and will also be used to limit servers to various skill levels. There are millions of other things I want to try, especially with teams, but I want to take this in small managable steps. I am presenting this as research-in-progress, so I'm not going to feel any guilt for downing the master at various times or doing frequent updates to the client/server exes. I would like to move user account creation and logon out of Quake proper, into the GUI app. My vague vision of the gui front end looks like: Launch Quake and get the port number that it running at, which will be needed for connect messages. An initial choice to either logon with an existing userid / password, or create a new account. If logon, fetch the current information from the master and display it. The user data should only change when the user directs it, but the master data will be updated sparadically. The user should be able to see that he advanced in rank before searching for servers. If newuser, prompt for a name, color, and password then fire off a message to the master that will respond with a new userid. Perform a logon to see if any masterdata was generated for the new account. Once the app has a valid userid/password, fetch the server list from the master, and do all the qspy like performance sorting and filtering. When one is selected, send a message to Quake to try to actually log in. These messages will be heeded at any time, so a user can just drop out of full screen Quake mode and click on another server if they like. I am totally open to comments and suggestions. John Carmack ---------------------------------------------------------------------------