'Alien Arena', an in-depth developers' interview - Part II

This is part two of an e-interview we did with the developers of 'Alien Arena', the free multiplayer deathmatch FPS available on almost any system today. Last time we provided thoughts by current lead developer, so this time the discussion will be more Linux-focused while we talk to the package maintainers and other important members of the team. Following are answers by James "Stratokaztr" Bower, Linux guru and a great mathematician, Max "MaxToTheMax" Eliaser, a bright young star - Linux giant, and Chandler "l'Emmerdeur" Wilkington, the latest addition to the team and Fedora package maintainer.

To read the first part of the interview with the game's creator, John Diamond, click here.

Bear in mind that the game is free and can be downloaded from mirrors listed on their website red.planetarena.org, from Desura or PlayDeb.


Before we go any further, please introduce yourselves to our readers.
Tell us something about your game development history; what do you do?
Did you work on any other project prior? How did you end up joining the team?

stratokaztr:
    Around Alien Arena, I am known as "strat" which is short for "stratocaster", now morphed into "stratokaztr". No, I don't have a real one, just a economy copy. Strats came out about the time I entered first grade so I guess that nick is appropriate. Several years ago, for reasons unimportant here, I found myself with time on my hands. I was a programmer from about 1980 to 2000, working mostly on embedded systems. Have had an interest in computer audio and 3D graphics for a long time. At some point, I started looking at Open Source 3D games. Somehow ended up at Alien Arena, running it on Windows XP.
    After playing Alien Arena for several months, I started suggesting some minor bug fixes. After awhile, that evolved into becoming part of the development team. I have been planning on setting up a Linux DAW (Digital Audio Workstation), but added an NVidia 8800 to the specs for sweet gaming performance. I originally started out with Fedora, but after awhile switched to Gentoo.

MaxToTheMax:
   My name is Max Eliaser. I go by the alias MaxToTheMax ingame. I'm presently a student at Oregon State University, studying computer science, although I've been involved with AA development since high-school and playing the game long before that. I've written a lot of my own code for various personal projects over the years, but Alien Arena is certainly the biggest codebase I've been involved with so far.
   Here's a funny story: the reason I ended up on the Alien Arena dev team is (indirectly) because of alphabetical order. This would have been around 2006: I was looking for free video games, and Alien Arena was at the top of Wikipedia's list of free first-person shooters, so naturally I tried it first. One thing led to another, I started submitting patches in around 2009, and the rest, as they say, is history.

l'Emmerdeur:
    I'm more of a Linux (cluster) systems administrator than a developer. My experience lies in getting various different codes to compile on our systems, and hopefully run efficiently in an optimized manner. One of my co-workers introduced the rest of us to Alien Arena several years ago, and we all started playing, first with bots, then against each other on a server running on a workstation, then we started playing in the big multiplayer servers and started getting involved in the online community. I highly recommend the Alien Arena community--it's a warm, friendly, and good-humored group.
    I started the transition from player/community member to the development team because I became the de facto maintainer of the alien arena package in Red Hat's RPM format for my co-workers. As part of maintaining the RPMs, I built upon Fedora's existing Alien Arena RPMs which were not quite following the latest development efforts. Last year, I contacted Tom Callaway, the original author of the Fedora SRPM, and offered to co-maintain the package. Long story short, he agreed, and I am now maintaining the SRPM, bringing the occasional feedback upstream from Fedora to the AA dev community.


Care to give us some insights about the actual development process?
Do you have any organisation, schedules or a roadmap? What tools do you use?

stratokaztr:
    Not sure we have a "development process". I just see something that looks like it might be an improvement, be interesting, and, hopefully fun. My first major project was converting the audio from SDL to OpenAL. On the Linux side, we use the excellent OpenAL-Soft library. Had a few compatibility issues at first, but that code has been mostly solid for several years.
    Second big project was implementing GNU Autotools (and updating to Windows Visual 2010 tools). That was painful, but worth it. Would not have turned out very good, but fortunately, another dev, BlackIce, showed up one day with some time on his hands, and rescued the Autotools project.
    I run the Eclipse IDE with GNU tool support on Gentoo. Contemplating moving to Emacs, though. Eclipse is very good, but has a lot of overhead that I don't need. But mostly, it's just time to try something different. Plus, Emacs has a certain coolness.

MaxToTheMax:
    The development process isn't particularly formal -- with a small core team of three or four active developers, there's no need for a lot of bureaucracy. We're all free to pick projects that interest us and approach them in whatever way we think is best. There's no centralized roadmap, but we all have clear pictures of what we want to accomplish. However, Irritant is the lead developer, and his say is always final. For user-facing changes, his sign-off is required. For really extensive changes that affect the familiarity of the codebase, it's also best to keep everyone apprised of what's being changed. Finally, if I'm messing with an area of code that I'm not fully familiar with (I'm running out of those) I'll usually ask people to look at the changes before I commit anything.
    For development tools, we all have different preferences. I personally don't like using a big IDE, especially not on a laptop screen. I use gedit 2.x -- if you install the right plugins, it makes a very capable programming editor. I also have a terminal emulator open for running 'make' and launching the game. I use gdb, straight-up, for debugging, and I also make extensive use of the Valgrind suite, Sysprof, APItrace, and cppcheck, all of which are valuable tools.
    As far as collaboration tools are concerned, we have a private development forum that gets quite a lot of use. We use Subversion for source control. This isn't my preference, but with six years of huge texture and sound files coming and going in our commit history, a distributed VCS isn't really an option.

l'Emmerdeur:
   The development process is largely driven by SVN and messages on the Alien Arena forums. In addition, I have access to the Fedora developers system for pushing updates to the alienarena package.


So what can you tell us about the aesthetic of the game?
Are they withstand the test of time? Anything being done to 'modernise' the looks?

MaxToTheMax:
    When everyone finally realizes that drab grey and brown deserts and bombed-out smoking ruins aren't actually nice to look at, we'll be here. Camp is timeless. Bright colors and brains in jars are forever.

l'Emmerdeur:
    Alien Arena is based on a retro sci-fi aesthetic that reminds me of the movie Mars Attacks! All the content is a brainchild and fiercely guarded intellectual property of the head developer, Irritant.


Seeing as it was built atop a heavily modified 'id Tech 2',
just how is the 'CRX game engine' holding out compare to the newer ones?
What are some of the more anticipated upcoming features?

stratokaztr:
    It amazes me how well Quake code has stood the test of time. Many thanks to id for open sourcing the code and giving us a Linux port. CRX is heavily modified in many places, but a lot of the original design and code is still in there. It has been quite a learning experience. That said, the game code is not for beginners. I thought I was pretty good, but have been burned a few times by hidden gotchas.
    Right now, Real Life keeps me from being active, but will be settled and back to it this winter. It would be nice to upgrade the sound effects of 44.1kHz. So that is something I may explore. The release of c++11 compilers has got me thinking (dangerous!). The runtime performance improvements in c++ make it a better tool for game programming. Might be too big a project to take on, but I am tempted to try a complete conversion to what is being called "modern c++".

MaxToTheMax:
    This is going to be a fairly technical answer, but then again, it's a fairly technical question. :)

    Compared to CRX, a lot of newer engines are tragically over-engineered. For example, let's look at Doom 3's Id Tech 4 engine: Id Tech 4's menu subsystem alone, including the menu editor, totals 32,000 lines of code, nearly as much as our entire renderer! Id Tech 4's renderer is bigger than our entire game, but is actually less advanced than our renderer.
Although nearly every aspect of the renderer has been at least partially rewritten, it's still a fairly old-school approach, as a whole. We use forward rendering rather than fashionable deferred rendering. At higher-performance settings, we render everything in one pass and avoid reading back from the framebuffer almost completely. Meanwhile, at higher settings we can still use modern techniques like shadow mapping, displacement mapping, full-screen distortion, and so on.
    What this gets us is extreme scalability. If you know what hidden settings to tweak, you can pare down the graphics to something not far from the original Quake 2, or you can get it close to Unreal Tournament 3. This is unlike a deferred renderer, which supports advanced effects well, but is completely pointless if you try to strip it down for speed (where speed = 300 FPS, not 30). Our approach isn't always the best one, but it works well for a twitch game where many players have 120 Hz monitors and 1000 Hz gaming mice.
    Make no mistake, even the "low" settings are targeted squarely at modern(ish) hardware. For example, we store all world geometry in a VBO and we accelerate skeletal mesh animation using a vertex shader. If you turn some of the more expensive effects off, the CRX engine becomes a speed demon. In a fair fight, we'd easily outperform the original Quake 2, and a lot of other engines too!
    In the future, we'd like to improve our support for big outdoor maps. Quake 2's BSP technology genuinely is holding us back in this area. The ability to combine BSPs for buildings with big meshes for terrain would be welcome. It would also be good to work on the network protocol a little and add some extensions to it, although backward compatibility is important for us. Long-term, I'd like to see us move toward scripting for the gameplay logic.


Now tell us about about when the game was first made cross-platform:
Did this have any impact on the future development cycle?
Did this have any (dis)advantages over how it was before?

MaxToTheMax:
    That happened before I joined the project, but I can tell you that I'm glad it happened. It helps to be a fish in a small pond. The situation is definitely changing now, but for a while, Linux games were hard to come by. That has helped us stand out, and is responsible for a lot of our exposure, especially since so many Linux users are also open-source programmers. Neither Stratocaster, L'Emmerdeur, nor I, for that matter, would be on the development team if we hadn't had a first-class Linux port.


Are there a lot of people playing 'Alien Arena' now?
How is it received by new players nowadays?
What about the broader gaming community in general?

MaxToTheMax:
    Once you get someone in front of the game, it's usually quite well-received, regardless of what they're used to, but it can be hard to attract new players these days. Sadly, fast-paced arena style shooters are going out of fashion now, something a lot of Quake-lineage open-source games are struggling with. But then again, as I write this, I just got done playing the weekly "Martian Mayhem" organized tourney, and we all had a great time. So I think we're still doing fine. :)

l'Emmerdeur:
    There is a very strong community of regulars playing online, and we see new faces all the time.


And what about those who are interested in contributing something to the project?
How would they go about doing that? What is currently needed the most?

stratokaztr:
    Before I arrived at Alien Arena, and since then, there has been a good group of volunteers. Real life comes first and there is no pressure to stay around forever or meet deadlines. The only real requirements are to have something to add that you would enjoy doing, and being somewhat competent.
    Alien Arena development is pretty much free of ego-tripping and drama. It is not a "democracy" or run by committees. Irritant makes the final decisions, and that works really well. For me, it has been a privilege and a lot of fun to be part of his dev team. If that sounds good to you, we can always use help with programming. My Linux development skills are getting better, but there is still a lot to learn. The client-server network code, which uses UDP sockets, is probably the most needy for updating.
    For non-programmers, there is always a place to help out in the IRC channel, and in the forum. We could use help with documentation, too.

MaxToTheMax:
    There's always a need for contributions from those running the game on unusual platforms. During the development of the last release, we had a guy with an old PowerPC Mac running Linux who sent in patches for a load of Endianness related bugs. Our Autotools build has an OSX target, but since none of the permanent developers have Macs, it may very well have broken since the last time someone tested it. Our FreeBSD support is in an even shabbier state. Even a lot of the Linux packages out there are out of date or broken (Fedora 18 and PlayDeb are happy exceptions.) If someone out there is willing to take on the maintenance of supporting an operating system or distribution, that would be quite welcome. Heck, even if you've running something like AmigaOS 4 or Haiku, we'll take patches. As I said before, it helps to be a fish in a small pond.
    If you're not a programmer, the map editor is reasonably easy to get started with. We have a vibrant community of third-party content (maps, models, etc.,) and it's a lot of fun to be part of. But perhaps most importantly, you can help by giving the game a try. It's a multiplayer game, so the more people there are playing, the more fun it gets. :)

l'Emmerdeur:
    Potential contributors should start in the forums, check out the code from SVN, and start creating posts in the Support section. Announce your interest, submit a good patch or two, and the developers may welcome you into the fold – that was my experience at least. At the moment we need more Linux developers to get involved in distribution packaging. I'm loosely covering Fedora at the moment, but I'm not sure what the current state is with Debian, Ubuntu, Arch, or other popular distributions.


Lastly is there anything you'd like to tell our readers that I've overlooked?

stratokaztr:
    If you have not figured that out by now, I am old. Turns out that is not so unusual among Alien Arena players. We have players of all ages from different countries. We are mostly a friendly bunch, too. So, don't let being old stop you from giving the game a try.

MaxToTheMax:
    Just: see you in the arena!


Thank you everyone for agreeing to participate in this interview!

Part I: link
Website: red.planetarena.org
IndieDB: link Article taken from GamingOnLinux.com.