Open Source FPS Game Alien Arena 2009 Released 142
Alienkillerrace writes "The open sourced, freeware FPS game Alien Arena 2009 has been released (Windows and Linux). The improvements to the game engine are very significant, and have surely raised the bar for free games of this genre. All surfaces in the game are now rendered using GLSL, not only improving the visual quality, but the performance as well. Interesting new effects like post-process distortions using GLSL have been implemented, as well as light volumes, better per-pixel lighting (reminiscent of UT3), and shaded water. Equally notable is that the sound system has been completely rewritten using OpenAL, allowing for effects such as Doppler, and adding Ogg Vorbis support. The game is free to play and available for download on its official website. It has a stats system and a built-in IRC client in its front-end game browser."
Windows installer totally broken (Score:2, Interesting)
Just fair warning, if you let their crap-ass installer do its think it'll put the game on the root level of your C: drive. I don't know whether it's 32 or 64-bit, and since the installer's busted, I have absolutely no clue where to install it on my 64-bit Vista machine.
Quality work, as always, from the open source game front.
Re:Windows installer totally broken (Score:5, Interesting)
I noticed that too. I also noticed that you can change the installation directory, as long as you have one of those input devices... What are they called now? Keyboards? Kids these days.
That I didn't mind nearly as much as the search toolbar they try to get you to install after the game is installed. Can't blame the guys for trying to get some compensation for their work, but I, like everyone else I'm sure, avoid those toolbars like the plague. (o:
Re:Wow, it has technical specs. (Score:5, Interesting)
I played for 15-20 minutes and, for me, it isn't all that fun for one simple reason: All of the weapons take only a few shots to kill someone, at most. Usually just one or two. So, it ends up being a twitch-fest. There's enough twitch games out there already.
Half-life, now there is a game that had deathmatch down. It took a while to kill someone. There weren't a lot of insta-kill weapons. A little slower paced. The "thinking man's deathmatch" if you will.
Graphically, it is pretty nice. For an open source game, it is fantastic.
Re:Wow, it has technical specs. (Score:3, Interesting)
OpenAL (Score:4, Interesting)
Ignoring for a moment that doppler has been supported in Q3 engines since 2000 anyway, it really makes me cringe to see uninformed people touting OAL as an "upgrade" to ANYTHING, just because of its name. Pasting from a post of mine from our engine forum about a year ago:
(apologies for Wall Of Text if it comes out that way: /. seems to want to use HTML whitespace consolidation even in POT mode)
>>>
As some of you have noticed, over the years we've gone from "openal is off by default" to "openal is excluded from builds" to, finally, "openal is removed completely".
In many ways, this irritates me a lot. I like the CONCEPT of openal, and I especially like the idea that we could have HRTF etc in hardware someday "for free", and ideally I'd like to make oal the ONLY sound backend we supported and get rid of the "ugly" direct-DMA stuff.
There's just one tiny problem: openal simply isn't very good.
As I mentioned in the 1.43 notes, we've made some very significant speedups in the last year or so, and sound is one of the key contributors to that (aside from actually, yknow, WORKING properly now too :P). With my standard config, there's now NO difference in timedemo rates between having full sound and disabling it completely. If you've been around Q3 for a while, that's pretty staggering. Even if I drop to a quarter of that resolution and essentially take the graphics card out of the equation, the numbers are 478 fps with sound disabled, and ... 474 with it on.
That's 96 channels, and they're ALL used when timedemoing "four".
I tried one of the openal test programs, and clocked it at ~6% CPU, which I'd probably just about be willing to accept, except that it was only mixing 64 channels, and the entire thing was static (i.e. this is an absolute "best possible case", where it could potentially pre-mix to an absurd degree because it wasn't doing any dynamic spatialisation).
6% CPU vs 0% CPU, for 64 channels rather than 96, puts it *at a minimum* at ~10% CPU overhead when you're talking apples to apples, and that's not very encouraging. I don't expect it to MATCH cnq3's sound code by any stretch, but that's a pretty big difference and it's even worse if it IS using lazy spatialisation.
There are also questions about how "timely" it is. If positioning etc only updates 30 times a second, or sounds don't actually start playing until 50-100ms after they're added, that's fine for WoW but absolutely shit for Q3. There's no guarantees in the oal spec, or even ANY documented indication of what the "reference" implementation's behavior is, which means we'd have to wade through a bunch of (frankly, pretty sloppy and mediocre) code to actually find out. I have no intention of moving to oal just to end up spending weeks fixing it for Creative.
There are several other issues too: the bug that Q4 has with looped sounds is a direct result of bad design that would have to be worked around at the app level; likewise, oal requires app-level culling of sounds despite the fact that the app CANNOT do so correctly because only the oal implementation actually knows what the 0-volume falloff distance for any given sound is. That's just utterly incompetent design/implementation.
[snip]
Happily, Timbo (ioq3's developer) was kind enough to run the tests for me, and the numbers very nicely match the observations I've made here:
131.6 fps 2.0/7.6/35.0/3.6 ms no sound
113.5 fps 3.0/8.8/82.0/5.4 ms dma
104.1 fps 3.0/9.6/72.0/5.7 ms openal
So, "normal" Q3 sound (with some of our fixes from 141/142) is about 16% slower than no sound, which is historically what you'd expect; and oal is another 9% slower than that (while mixing only 2/3 as many channels, so the truth is more like 14%, for a total of ~30% slower than cnq3).
And that's why we no longer support oal at all.
I MAY someday revisit this. I doubt there are too many cases where the "missing" 32 channels are actually going to matter, simply beca
Re:Windows installer totally broken (Score:3, Interesting)
welcome to the hasrh reality of end users !
Re:Wow, it has technical specs. (Score:3, Interesting)
All of the weapons take only a few shots to kill someone, at most. Usually just one or two. So, it ends up being a twitch-fest. There's enough twitch games out there already.
That's true that a lot of multiplayer FPSes these days give you less than a second from the time you see your enemy to kill or get killed, but making it so you have to empty a whole clip and a half into your opponent doesn't fix it. The solution isn't necessarily in a trade-off.
Which reminds me of a very fun mod for CoD4 I've played lately. It's a paintball mod, a Simpsons mod (you play in 3D Springfield) and you can jump very high, there are few buildings you can't leap over in one bound. So basically, it's a huge bunny hopping map, but here's the fun thing : if you pick a grenade launcher, you can kill an enemy on the ground easily (takes lots of luck to hit a flying enemy with that), and you have a poor firing rate (one shot every 2-3 seconds).
So what happens is you spot an enemy, let's say you're on the ground, not jumping. At first you don't shoot, because grenade launchers don't fire straight, and because you need to make the projectile hit the ground not the enemy to have a chance to kill the enemy on the ground. Your enemy is bunny hopping, all over the place. So what you do is start hopping too, but carefully you only start hopping when your target is about to reach the apex of his jump. Because what you want to do is be at a high point and be relatively stable while your enemy is near the ground to shoot him. So you jump, keep track of your enemy, and hopefully if it worked out well you get him in one shot while you're quite steady in the air by shooting at the point on the ground where you predict he's about to land. Optionally another quite fun option is to stand on land while your target is in the air, run to the point where you think he's going to land, and punch him dead when he lands right next to you.
For short, it's fun because you first have to track down your enemy, you don't have to start aim and shooting mindlessly but rather carefully calculate your time of jumping, your time of shooting and where to shoot (which is not where your enemy appears to be but where you think he'll be, which makes it more fun), and if you're against a skilled bunny-hopper it can lead to an exciting jump-dogfight which outcome can be quite interesting, like for example the two jumping towards each other and punching or shooting each other at close range in mid-air. Alternatively it's also quite fun to pick out guys that are high perched and staying there by jumping high and shooting a paint grenade from a distance straight into them or their immediate surroundings.
A shame these days we're sticking to a guy who runs all over the place and shoots supersonic bullets straight into his enemy when there's much room for trying alternatives that have wildly different gameplay results.