It was based on a reliable stream as its original primitive (way back in qtest), then was retrofited to have an unreliable sideband to make internet play feasable. The first move was to scrap the current net code. I have a T1 to my house, so I just wasn't familliar with PPP life. ![]() Unfortunately, 99% of the world gets on with a slip or ppp connection over a modem, often through a crappy overcrowded ISP. People that have a digital connection to the internet through a good provider get a pretty good game experience. My original design was targeted at <200ms connection latencies. While I can remember and justify all of my decisions about networking from DOOM through Quake, the bottom line is that I was working with the wrong basic assumptions for doing a good internet game. If somebody manages to piss off the entire community, we could even ban them at the master server. Servers will have good access control lists. A few other non-crucial game behaviors are also being cut in the interest of making the physics easier to match on the client side. The automatic view tilting on slopes and stairs is buggy in v1.01, and over a couple hundred millisecond latancy connection, it doesn't usually start tilting until you are allready on a different surface, so I just ripped it out entirely. Multiple servers running on a single machine will work a lot better with the master server automatically dealing with different port adresses behind the client's back.Ī couple subtle features are actually going away. A single p6-200 system should be able to run around ten simultanious eight player servers. The new network code causes a higher cpu load, so I am trying to at least overbalance that, and maybe make a little headway. Currently, a p90 dedicated server is about 50% loaded with eight players. The game physics is being reworked to make it faster and more uniform. Newbies would be automatically kicked from servers if a paying customer wants to get on. My halfway thought out proposal for a biz plan is that we let anyone play the game as an anonymous newbie to see if they like it, but to get their name registered and get on the ranking list, they need to pay $10 or so. Its definately cool, but it is uncertain if people can actually make money at it. ![]() If it looks feasable, I would like to see internet focused gaming become a justifiable biz direction for us. The new exes will only work with registered Quake, so I can justify it as a registration incentive (don't pirate!). There are all sorts of other cool stats that we could mine out of the data: greatest frags/minute, longest uninterrupted quake game, cruelest to newbies, etc, etc.įor the time being, this is just my pet research project. You should be able to say, "I am one of the ten best QuakeWorld players in existance", and have the record to back it up. I want us to be able to give a global ranking order of everyone playing the game. Users will have a persistant account, and all frags on the entire internet will be logged. Whenever anyone starts up a server, it will register itself with the master server, and whenever a client wants to start a game, it will inquire with the master to find out which servers are available. There will be a single master server running here at id. They will use the same data as the current registered quake, so the only thing that will be distributed is new executables (they will peacefully coexist with current quake). It will be rolled back into the single player game sometime along the road to Quake 2 (or whatever it turns out to be called), but the experimental QuakeWorld release will consist of seperate programs for the client and the server. The code I am developing right now is EXCLUSIVELY for internet play. I still have my grand plans for the future, but I want to get some stuff going NOW. While I can lay out a grand clean-sheet-of-paper design, I have chosen to pursue something of a limited enough scope that I can expect to start testing it around the end of the month (august). I am focusing on the internet play aspect of the game. ![]() The old v1.01 codebase will still be updated to fix bugs with the current version, but I didn't want to hold back from fixing things properly even if it involves some major changes. I copied off the quake codebase and set about doing some major improvements. In software mode it's almost roughly 2x as slow: Just a guess but it's possible it was inherited from the Quake engine and possibly it was set to that value due to Quake being designed on a CRT and/or stereo and/or being a range that was probably flicker free and supported by the range of video cards and hardware and networking that Quake was designed for and tested on. May be a question for Carmack or Romero as far as the limit.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |