Slashdot Mirror
Multiplayer Linux Games
gooshy1 writes "Ok it's getting near the end of the year and people are beginning to wind down for the holidays. What I want to know is are there any decent multiplayer games that an office of about 4-7 can play, preferably action. The machines that we use are not all that great, P4 1.7Ghz with 2 year old NVidia graphics cards, so Quake and the likes are out of the question. A favorite is BZFlag due to its playability and nice tunable graphics. All thoughts welcome, and Merry Chistmas/Happy Holidays :-)"
There is a great game being developed with Garagegames' "Torque" engine. It has rock-solid 32-player multiplayer, high fps, emboss terrain bump-mapping, and, most importantly -- great, unique movement dynamics.
:) Great guys on that dev team, though -- download the game, it comes with a modified version of a stable auto-updater program. Download it once, and if nobody is playing, you'll always have it -- when the next release comes out, you can autoupdate! Also, the team is very good about arranging regular scrimmages for everyone that is interested.
Well, not unique entirely. Some might even argue that the game is nothing more than an independent resurrection of a type of gameplay that was accidentally (bug) introduced in the first game of a franchise, was LOVED TO PEICES by the fanbase and introduced thousands of players to the game, and then was nixed in the second installment because an arrogant jackass (*cough*he made Planetside*cough*) who got owned every time he played the game in multiplayer decided that player skill was overrated and unfair to the majority of players.
http://hosted.tribalwar.com/legends
My work here is done.
Summary:
Legends. A team-based multiplayer FPS with a very deep and well-developed movement-and-combat model.
Two reasons. The first (and undisputable one) is that for scientific purposes of measuring system performance, you want to have as precise numbers as possible. So when starting to tweak for speed, you certainly have to be in a configuration where the effect of every setting changed can be detected. Vertical-sync locking might hide the effect (positive or negative) of weirdly-labeled OpenGL options.
But there's another reason, so people may want to leave vsync disabled after figuring out the tweaks they want. It's almost too simple to bother typing out: "Because it gives higher frame rates".
You said "faster frame rate in numerical terms". But that just means "faster overall".
surely it means that your monitor is showing two or more frames at once (eg the top 1/3 of your screen showing two frames ago, middle 1/3 showing one frame ago, bottom 1/3 showing current frame)?
Not three, just two. Your description is as if there was no such thing as hardware pageflipping. In reality, there will be a single "tear" line going horizontally across the screen, with the prior frame above it and the current below. (vertical syncing forces that line to always stay at Y=0 at the top of the screen, meaning you see only one frame)
The reason the tear-line doesn't matter at all is a fundamental principle of visual perception. "Persistence of vision". I won't go into lengthy details, just look it up.
Hint1: A movie projector shows you fully black screens 50% of the time, yet that doesn't bother anybody.
Hint2: the higher the framerate is, the smaller the difference between the prior and current frame will be, making the "tear" even less detectable. At above 50 fps, it's hard to see, even if you're looking.
If your monitor is set to 100hz vertical refresh then that's your optimal frame rate. No more. No less.
Absolutely not, especially in games based on Quake. There's MUCH more than your monitor to consider. There's also the simulation model inside the game. The tight coupling between client and server can have weird effects. For example, if you're playing Quake3, the forward distance you can jump is maximized with a framerate evenly disible by 125. Going at 130 fps will unsync you from the underlying physics code, cutting 4-7 units off your jump height, and generally impairing all your movements (by a tiny amount, but serious deathmatches are won by slim margins)
(I don't know if other games exhibit fps effecting the server's processing, but that phenomena is well documented in Quake)
Actually, it was never fixed.
.6 units/sec shaved off of it. It feels a bit floaty, and you can obviously jump a little farther.
The problem is that the player movement code snaps the player's velocity vector (floors each component) after every player command is processed. Player commands are sent every client frame.
If you're getting a solid 125 FPS and the gravity is at 800 (always is), your frames last 8ms, and your downward velocity will almost always have
The other magic framerates are 200 (.6 units error) and 333 (.8 units error).
The truncating saves about 120 bytes/sec. I suppose that would matter a lot to someone playing over 56k.
I got my Linux laptop at System76.