For years I have enjoyed working on Alien Arena in my spare time.  It’s my hobby, my passion, my artistic outlet.  When people would criticize the game(and believe me they do), it would only serve to fuel me into striving to do better, and improve my abilities.  The ironic thing is, at the time of each release of the game, I honestly felt it was the best it could be, and the best freeware game of it’s genre.  Looking back, I realize I often saw/see things with a bit of rose colored glasses, but I also see what exactly made me think of it that way.  The game has evolved tremendously since then.  Not only have the artwork and gameplay improved dramatically, but so has the engine.  In the early days, the CRX engine was nothing more than Quake II with some Quake III style shaders on it.  In comparison to say the Darkplaces engine at the time, we were *far* behind on technology.  For several years, it seemed like we were chasing other free game’s engines, never really being the “first”  to implement anything.  This is all beginning to change…

In the summer of 2008, after a massive amount of content ravamping, and addition, which IMO put the game on a whole new level of quality, we found ourselves being overshadowed at a time when we thought we would be in the spotlight.  The biggest criticisms we were seeing was “great game, bad engine”.  Bad engine…that hurt a little…but it was true.  We were still using tech that was prevalent in 1999’s Quake III.  Games like Unreal Tournament 2003/2004 look far better, and games like Doom III/Quake IV, using mid-2000’s era engines, were like a distant star that we could not reach.  Oh, I loved to claim we had advanced features, but the truth was, we were falling further behind, and at a very rapid rate.  It was then, in July of 2008, that I made a personal commitment that the game renderer would have to be addressed, no matter what it took.

Parallax mapping
Parallax mapping

What it took exactly, was to rethink a lot of what the renderer was doing.  GLSL was becoming much more common in game rendering, and the amount of tutorials were prolific on the web.

Specular highlights
Specular hightlights from static light sources

So the first step was just getting a GLSL framework established, before moving too far ahead.  Baby steps….that luckily, had some precedent.  A little known project known as the “Quake 2 Graphics Mod” by Ben Lane provided a host of clues as how to accomplish what I wanted to do.  While this really only dealt with a small part of the picture(normalmapping dynamicaly lit surfaces), it did provide some invaluable insight.  By the end of the summer of 2008, the CRX engine was now rendering bsp(map) surfaces using GLSL.  Not only that, but I had managed to add parallax mapping, as well as specular highlighting from static light sources.  The engine was being, at last, thrust into the modern age of game rendering.

The next stage was a bit more difficult, which was the application of this technology on meshes such as character models and weapons.  Engines such as Darkplaces had achieved this, but the documentation and code structure was such that it provided little help.  Finally, it was at this time that I broke down and bought the Red and Orange books, on the advice of Jay Dolan, author of the Quetoo and Q2World engines.  He and I were both working on similar things at that time, and he found it to be a vital resource.  Using some code examples from the Orange book, and some online tutorials, by spring of 2009, I had achieved what I once thought was beyond my reach, which was proper normalmapping on meshes. 
Old fixed function normalmapping

Old fixed function normalmapping effort.

By summer of 2009, I had this working for fixed and dynamic light sources, and while there were a number of trials and tribulations early on, it was finally ready for public consumption.  Once again Jay Dolan provided a clue after one night of brainstorming with me, and the final piece of the rendering puzzle was in
place.  I was amazed how fast normalmapping was now and how much better it looked!  

 All of these new rendering features, as well as a load of new content, provided the impetus of releasing Alien Arena 2009.  Armed with a new trailer, a host of screenshots, and a number of gameplay updates, we unleashed the game on the public.  Now were were starting to get some recognition for the engine work, and it seemed that the players were really enjoying the new look of the game.  However, for all of that effort, we were still a very long ways behind some other free game engines, and had much work to do.  The next big phase of renderer development was to address shadows.  For years we had been using simple planar stencil shadows, that were stretched to provide the illusion of light angle and direction.  While they were very fast, and looked decent enough, they were still

GLSL normalmapping on meshes

GLSL normalmapping on meshes

 very old tech, and far behind the Unreal 2 engine, Doom III, and Darkplaces.  My first thoughts were to do what Darkplaces had done, which is, in essense, to use the algorithm developed by John Carmack to create stencil volumes.  However, there was some potential issues with legality, as Creative Labs had apparently patented the technique years ago, even though Carmack had come up with his idea on his own.  To be sure though, there were other methods of doing stencil shadows that would not be in jeopardy of patent violations(even as absurd as they are), and I decided to use those.  By fall of 2009, we had our volumetric shadows, but I personally did not feel satisfied.  The Unreal 3 engine, as well as many other new engines, were using soft shadows.  In fact, even Unreal 2.5 had soft shadows.  We needed soft shadows!  

 My first attempts at soft shadows involved the use of shadowmapping, using GLSL.  There were a host of problems though for doing this for the static light sources.  Every solution I saw was the same – they weren’t accurate, and they didn’t look very good.  On top of that, there was a performance issue that while wasn’t bad, it annoyed me a bit.  For dynamic lights though, shadowmaps worked splendidly, as you are only dealing with one light source.  For our purposes, I
Soft shadows
Soft shadows

would eventually settle on a combination:  stencil volumes for static lights, shadowmaps for dynamic.  I had read some theories on how to create soft stencil volumes, and after seeing that it was a low cost method, I implemented it.  The process was actually a bit tricky, requiring some more advanced frame buffer management than I had previously done, but in the end, the results were very good.

 By now, the engine was just starting to reach what I would consider a modern state, at least on the end result aspect of things.  We were still doing some old methods, such as vertex animation for meshes, compiled vertex arrays(more on this later), bitmap fonts, as well as an outdated sound system.  For years, the engine was my own personal domain, with a little help from friends here and there.  By now though, I had started to receive some help, from the likes of Tony Jackson, Jim Bower, and Emmanuel Benoit.  Tony was the first of the major contributors, and he was very good at finding many of my coding mistakes.  Tony focused mainly on the game code, finding memory leaks, pointer problems, and other issues.  Soon, our server code was vastly more stable, something that had plagued earlier releases.  Jim Bower, known affectionally as “Stratocaster” in the community, took it upon himself to rewrite our sound system, using OpenAL.  This allowed us to do a great number of new things, and vastly improved the experience of the game.  Jim didn’t stop there though.  Pretty soon he had a hand in most everything we did, including implementing AutoTools to make compiling the game much easier for Linux repo managers.  Emmanuel made his presence felt quickly.  Like Tony, he found a number of inefficiencies, errors, and opportunities for improvement.  Eventually he rewrote our in-game IRC client, and implemented a True Type font subsystem.  Our little engine(and it’s now truly “our”) had begun to gain some notoriety in the gaming and tech world!
With the game engine now closing the gap not only with a number of free engines, but commercial ones as well, it was time to make another quantum leap.  For years, the old model format had not only been limiting us, but it was a slow, cumbersome, and quite ugly method.  It was time for us to move to a skeletal model format.  Much like the time when I felt we needed GLSL, it was another one of those “at any cost, any means
Skeletal model format

A render of the IQM skeletal model

necessary” moments.  My first instinct was to use either the SKM or MD5 formats, which were popular, but both poorly supported and documented.  It was at this time that Lee Salzman, the lead developer for the Cube2 engine, approached me about possibly writing a new model format, and if I would be interested in using it.  It was almost as if fate had struck!  I was very interested.  Very.  When I finally completed the shadow code, Lee had finished writing the new model format, and I began work on implementing it into the CRX engine.  At first this seemed quite daunting.  Not so much the use of the format, but the integration.  In the end, with some assistance and bugfixing from Lee, the new model format was in the game and working perfectly!  Not only this, but Lee pointed out some errors I had made in my older mesh rendering code, and performance for all meshes, MD2 and the new IQM were vastly improved.  The stage was being set for us to begin moving rapidly forward yet again.  Again, with some assistance from Lee, we first added pitch/spine bending for player models, and then…the ultimate frontier…ragdoll physics!

 Ragdolls were without question, going to be the most difficult task I had ever taken on since working on the GLSL mesh rendering features.  I had spoken of this often while completing the IQM rendering, and in a sense, wrote a check that I was unsure I’d be able to cash in.  I honestly considered giving up on this a great number of times, but each time, I managed to convince myself that this was worth doing, no matter what it took.  For the first time, we had a chance to be a pioneer – no other free game based off of the Quake sources had 3D ragdolls, and in fact, only one other free game had managed to implement it:  Cube 2.  Lee had warned me of the perils that lie ahead, but I truly had no idea. 
The Open Dynamic Engine had been on my radar for some time.  I was not sure if this was the best choice, but after some research, and noting that Darkplaces had recently integrated ODE into it’s code, I felt that it would be the one for us.  The Bullet engine, as well as Cube 2’s physics code might have been more suitable, but they were written in C++, and this really wasn’t a good option for us.  I’ve never personally liked, or felt comfortable with C++, so I chose ODE, despite a tragic lack of any real good ragdoll physics examples.  In my searches, I eventually found one, however it was written in Python, and would require extensive translation.  So, I began the slow, tedious process of building up the ragdoll subsystems, framework, and rendering routines.  Just the concept of how they would be implemented took a good amount of thought and planning(I had in fact been thinking of it for a year or more).  I moved slowly, getting basic functions and ODE framework started, then onto actually trying to render a rudimentary ragdoll before actually applying it to the skeletal model.  I actually surprised myself a bit, and made good progress initially.  I made it a point not to hound Lee too much for advice early on, as I really wanted to understand the things I was doing.  Finally, I had reached the point of applying the ragdoll to the model, and again, was surprised that it kind of semi worked.  At this point I turned to Lee for assistance, which he very willingly obliged.  It turns out that I was much closer than I had thought, and Lee was able to pinpoint where I was going wrong, which turned out to be a fairly simple thing regarding the position of the base frame.  In the end, Lee probably saved my sanity…and before I knew it, we had working ragdolls in the game! 
 Finally, after many months, years of work, I believe Alien Arena is on the verge of something special.  I would be remiss to not mention some of the other contributors such as Dennis Zadlach, one of our wonderful map makers who has for years been making amazing maps for the game, Chris Preble and Victor B for setting up our own IRC network and maintaining it.  Guys like Cthulhu, Spot, Stirky, Sinno, JoTurkey, MaxToTheMax, Tik, for hosting servers, writing code, and spreading the gospel.  The list of contributors is endless, and I’m sure I’ve left a great many out.  Even though it’s been many years since this project began(2003 to be exact), we are really only at the beginning.  There is so much ahead of us!  Even though I feel we have an excellent game and engine, I know there is plenty of room for improvement.  As time marches on, I will continue to update this blog with my thoughts on where things are heading. 
Until then….frag on!