Saucermen and the CORTech engine use Bullet physics, which is a departure from CRX’s quake2 physics. While it’s true that CRX used the ODE physics engine for it’s ragdolls, none of that was used for movement. By contrast, everything in CORTech is handled by Bullet. Bullet is of course built off of ODE, so much of this was all familiar to work with.
I had a few items to deal with when it came to the skeletal animation, so I decided the first thing to take on would be the bending of player models at the waist for indicating pitch angles. This was done in CRX, but it was going to take some massaging to get it working here. After a few adjustments though, I had it working nicely. Here is a pic showing a very extreme amount of pitch, with two bots looking directly up and down at each other, respectively:
While this was a really cool example of pitch, I should investigate why those bots cared about each other but didn’t shoot. It appears the top one was just on the edge of the platform and they had sight lines, but they weren’t firing at one another.
The next Big Scary Thing I needed to tackle in this engine was ragdoll physics. This was one of the most difficult things I ever implemented in CRX back in the day, and really much credit had to go to Lee Salzman(of Sauerbraten fame), who provided me a lot of help. Lee and I spent many late nights (well, later for me since his time zone was 3 hours behind) figuring out how to make the IQM model format that he and Forest Hale devised work with the ODE engine. Lee warned me from the start “There’s dragons in there” regarding ragdoll physics. Initially Lee tried to sell me on using his homebrew physics engine, which worked really nice in his game, but massaging that into CRX seemed, well, daunting. Eventually his curiosity over ODE and a new challenge won him over, and off we went. CRX is one of the only(maybe, the only) Quake based engines that implemented Ragdoll physics, and it worked spectacularly well. Remembering our ordeal, I was hesitant to even bother, after all I had a pretty cool gib system working in Saucermen with all of the body parts flying apart. But still, I wanted ragdolls – they are just too cool not to have.
I figured there was probably already a Bullet tutorial on them, and I was right, so I grabbed one, and got it integrated along with a management system right away. The very first thing I wanted to do was render the ragdoll itself in some fashion, so that I could verify it’s integrity, and overall dimensions, shape, etc. Since I had a gib for every body part, this actually was already there for me to do. I spent much of Superbowl Sunday working on this, and got it to the point of rendering a very simple ragdoll object(head, torso, arms, legs). Some tweaking of dimensions got it correctly aligned for the most part. More will have to be done as I work on the elbows and knees though.
Yes, I know, the pic shows the ragdoll with two left legs 
This is all temporary, those legs and arms will get divided in two(and I’ll add a right leg), so that I can flesh out the knees and elbows. I probably won’t worry about wrists and ankle joints, at least not now. Mostly these worked pretty well, other than getting stuck in stuff because my physics frame rate is too low(I will address that very soon). While watching the very boring game(and this coming from a huge football fan), I got to thinking about the ragdolls and gib systems.
While I already have the code in place to use the ragdoll to animate the entire player model, the fact that I am able to render the ragdoll using the body parts like this is really making me contemplate combining the ragdoll and gib systems into one unit. The concept being that more damage would have various body parts fly off of the ragdoll, and catastrophic damage would throw all 10 gibs out there. The more I think about this, the more I really like the idea. This would require that my future player models be constructed with joints that are more mechanical in design, but that was always the plan anyway. Meanwhile, I have a lot to clean up on that code and it’s operation, but at least I have functioning ragdolls.
The other area of focus is on memory management. With Frenzy I really didn’t have to do a heck of a lot. There was little to no duplicate use of textures, very limited projectiles or other objects to worry about. Leaving much of it in static memory was reasonable and safe. Saucermen on the other hand, well that’s a whole other ballgame. While some things in the rendering pipeline were dynamic, it was clear that really the rest of the game needed to get shifted into that direction. Of course many programmers cringe when the word “pointer” or “linked list” is mentioned (and many programmers these days have no idea what all that really is being sheltered by high level programming languages) – but that stuff is all old hat to me – and pretty much anyone who ever worked on game code like Quake that existed in the days where you had to do crazy stuff to get things to load or run on the computers of the time. I very quickly whipped up a texture management system, and started moving some of the objects like gibs and such there as well. This also allowed me more properly manage and tweak physics objects to their respective entities.