A long-standing bug which had me stumped for a bit has been solved. This was an issue with the view vector and how I was calculating it. It affected both aim and movement (though the movement was insignificant to notice). That really gave me a nice sense of accomplishment. I also made the changes to the weapon skins and I really like how the game feels visually in that regard.
Two of the levels, IMO, are pretty great in their look, though the layouts are incomplete. The third, Saucer, is kind of an eye-cancer mess. A lot has to do, as I previously mentioned, with creating a ton of assets from scratch all at once. Some things kinda got re-used, some techniques got overused, and some of it was just not really seeing the forest for the trees. I spent a few days looking at some other games, and some older ones, as well as some really great texture sets, like PhillipK’s stuff. Now I 100% am not going to go the route of using a canned texture set for Saucer. Look, we already have Alien Arena and Xonotic, and quite a few other FPS games using PhillipK’s textures, and to me we have enough similarity going on there.
However, looking at some of the nicer texture sets really illustrate some of what I’m doing wrong in Saucer. I have way too much color. Much of the level has this peeling, scratched paint look. Its overdone. There’s simply too much of it, and I need to fix that up. I’ve spent a good deal of my free time taking a look at the existing Saucermen screenshots of that level, and I see where I need to revamp a number of spots/items and do it in a way that makes the level not seem so repetitive visually as well.
Some areas just needed to have the colors moved around a bit. For example, this hallway that has too much red, and needed some variation:
It’s definitely improved from what it was originally, but a year of not looking at it, I see it’s just bland, and too red.Same hallway, with all of the new color/gfx changes. Feels a bit more varied, and less red.
This level has proven to be difficult to make attractive to me, but I do think it’s heading in the right direction. There’s probably room for some details to eliminate the repetition. Some trash, equipment, etc.
The robot room got some needed updates too. That one really bugged me, and I was able to improve it significantly.
Before…And after…Another after view.
The floor is a huge improvement, the other changes are far more subtle. I worked on changing on other areas of the level as well, and I’m definitely feeling better about things overall.
Good example of how the updated weapon palette and level textures feel now.
I’ll need to review my past blog posts to see what my plans “were”, regarding the overall scope of the game. My current thinking is that I’ll create six maps. Perhaps three, or four even, will be remakes of Alien Arena maps. I know I’ve mentioned Violator as one, and I’ve been thinking lately about Invasion as another. In the case of Invasion, I believe I have all of the assets I need to pull that off. This iteration would be a far more intricate design that would allow for a bit more vertical game play, using many of the buildings and structures of Ground Zero. Violator would require importing a number of existing Alien Arena assets to complete, and probably use some of Saucer’s as well. As for the final map, I’ve had some various thoughts. Perhaps Babel. That could be a map that really shines using this engine.
I have recently polished up, added a few minor things to the game play, and should be able to wrap most of that up and get back to the maps and rendering features.
Much of the Summer has been spent racing RC’s, fishing, boating, you know, doing things outdoors instead of sitting indoors behind a computer screen (which is what I do all day at work). Of course being Summer in the Appalachians, there’s always gonna be a bad stretch of weather, and with that I got the itch to work on Saucermen some, and tie up a few loose ends that I’d started earlier and wanted to finish up.
Items!
Working items.
The items are now in the game, and all over the maps. Bots go after them, though there’s some more work to do there to make them more intelligent.
Well, I had some armor, and it saved me here!
I also got colored lighting finished! Not terribly hard, but something that I had been putting off and needed to finish. I’ll be going back into Saucer and doing some things there. I think I need a bit more work on the fade off, but that’ll be done in the shader. For now I have just uniformly applied the color without consideration of distance from the light, but I’ll fix that shortly.
It was great jumping back into the code and game. This thing is really smooth and fun to play, and super immersive with the VR. As the weather cools and I won’t be as involved with racing, I’ll certainly spend more time on this project. The major plus with this new project is that it’s so simplified and organized that I had no issues getting my feet wet.
Dating myself with that movie reference, but I was at a loss for a title of this entry. I have finished up the weaponry in Saucermen – the as of now planned three weapons. Each is a different type – a moving projectile, a physics projectile, and a hitscan. The one type that is notably missing is a rapid fire weapon. At this time I don’t have plans for one. I have reasons – mostly based on game play and how it would work with what I am expecting to be a crowd that is either using VR, or just new to arena shooters in general. Time may change this decision, but for now the weapons are finished, functional, and will get tweaked as I get the game closer to something that is testable by a small group.
The last weapon I’ve added is the disruptor, a single shot hitscan weapon that deals out a lot of damage. I will begin tweaking once I get everything else about it (such as rendering the beam it shoots) finished. For now it’s working, and a ton of fun. Here is a pic of it in game before I updated the skin a bit after being unhappy with the rear portion of the weapon.
This enforcer is about to find out just how nasty a disruptor shot to the face is.
The disruptor is styled similarly to the blaster and grenade launcher, with a bright, distinctive paint that is chipped and worn. In Saucermen I am placing a premium on visibility, so you can see from this shot it’s easy to tell what weapon your opponent is wielding. Each of these weapons will get some cool animated shaders once I’ve added that capability to the engine. Usefulness is also something that I am really looking to achieve with each weapon, so that while balanced, there is a reason to want to switch to another weapon, and not just have a “favorite” that you’re used to. Weapon balance has often been both the thing that fans clamor for, but in a sense it’s been a bit of a downfall of the genre. There should be a reason to go after ammo for a specific weapon, and not this equity among them. With that in mind, ammo placement is nearly a science – correction – scratch “nearly”, it IS a science.
Now that all of the weapons are finished, here’s the rundown:
Photon Blaster
The photon blaster.
This weapon fires a single photon ball that explodes on impact. It has a small amount of splash damage, and the projectile travels roughly the same speed as your typical rocket launcher in Quake based games. It is great for mid range, and close fighting, as it’s splash damage does not injure the player firing it. It will(eventually) be useful for trick jumping.
Grenade Launcher
The grenade launcher.
Packing a major wallop, but lacking range, this one is good for close shots that are direct hits, or for just throwing down into a crowd. It’s lack of range will discourage rampant spamming, and keep it more of a close-up tool.
Disruptor
The disruptor.
The big kahuna. Massive damage, but you gotta be accurate. Refiring rate is likely going to be slower, we’ll see. Similar to a railgun in Quake, it really is just impossible to not have this type of weapon in an arena shooter.
Now it’s time to start getting on the items, ammo system, and the armor. This is gonna be some fun stuff!
At the stage now of “I made too much stuff, it’s using up way too much memory, and it’s time to get a little dynamic”. I new that was coming fast, especially while making the newest level “Ground Zero”. I simply got sick of waiting for the game to load up all of the meshes instead of what it just needed…so…it was time to start doing some flushing and re-loading. It took a bit of time, and tracking down some weird things with the IQM models, but it’s working. It’s also now only flushing anything if the map changes, and instead resetting various data that needs resetting in those cases. While tracking all of that down, a couple of other intertwined bugs were solved, at least in some fashion. The one that is still bizarre is the case of the ragdolls. Everything is fine when they are deleted “naturally” during the game, as they time out, but if there are some active ones and it runs through the list and clears them when switching maps – boom – crash. It’s odd, given it uses the identical methods. Has to be some kind of weird timing issue with Bullet. This really only happened when manually switching a map in the midst of a game, when it sits in it’s 10 second intermission between maps, and everything clears out during that time, it’s fine. So, in my “infinite” wisdom, haha, ok, let’s be honest – sometimes you just gotta go the “hack” route, I have the game go into an intermission when switching the maps manually. Sometimes it’s the simplest answers.
This all lead to the multiplayer side of things, and special care had to be taken there, not to mention the map editing aspect. Largely this is all completed now, with a little more brute force testing to confirm it is 100% stable. So far, so good! I am really excited to start testing and developing the more complicated aspects of online multiplayer. I love the base framework that’s in place, and this will be something that will be a lot more easy to deal with than ancient Quake based engines.
I’m also still working on content, and will soon have some updates there. Meanwhile, a bit of minor work continues on Ground Zero, so here is a screenshot(though this one doesn’t show anything new, just thought it was a cool shot!).
Jump, you bastard, jump!
I will add a few things more to GZ this week, some car and flying saucer wreckage, a few more detail meshes here and there. It won’t be long before these maps are populated with items like ammo, heath, and armor.
Sometimes I really long for the classic arena shooter days. Not necessarily the peak of Q3 and UT, but more the years in the mid 2000’s when the open sourced shooters arrived. It’s a little known factoid that Alien Arena was the first of the Quake based aFPS games to arrive. It was overshadowed by another, rival title – Nexuiz. Much of this had to do with the fully open source nature of the project, as well as it using the most advanced Quake based engine of the time, Darkplaces. With Forest “Lordhavoc” Hale involved, people paid attention. While Alien Arena’s parent game, CodeRED had received pretty significant attention, including being featured in various gaming magazine print, Alien Arena flew under the radar initially. When Nexuiz was released, it was instantly popular, with over 100 concurrent players much of the time, despite it being fairly buggy, and really poor performing. I still recall downloading the first release, finding it unplayable, and being upset that it was receiving so much attention, and being billed as the “first”. I probably let that affect my perspective for years to come.
Nexuiz(the original), featuring some pretty unique art in it’s early years.
Looking back, Nexuiz was actually a really darn good game – once they got the performance issues sorted, which they did. I remember playing those early releases, loving the level designs, and truly falling in love with the soundtrack. To this day I have that soundtrack on my computers to listen to while I work once in a while. While there was indeed some artistic inconsistency, and some of it(the weapons in particular) were downright ugly, it had some really great artistic aspects as well. The Aneurysm map, always stood out to to me(and it was a great layout). I loved Basement, Slime Factory, and some of the other early maps. It’s heavy use of EvilLair’s textures didn’t hurt either, and many of the characters were well done, and just cool. It didn’t have much of a unified theme, but it was a lot like UT in that regard.
Nexuiz, at it’s peak, around 2009. Beautiful.
By 2005, many other titles have arrived, Warsow, Open Arena, Sauerbraten, and Tremulous. The field was crowded, but all of these games had followings, including Alien Arena. Nexuiz, with the force of LordHavoc driving engine development began to move forward at a rapid pace. With the advent of GLSL, it really came to life, and it led the pack in graphical rendering beauty with it’s real time shadows, per-pixel lighting and other effects. It was also quite popular, and fairly universally praised, especially among the Linux crowd and media, such as Phoronix. While a part of me was always feeling Alien Arena didn’t get it’s due recognition(or whenever it did, it received equal backlash), the other part really admired Nexuiz. I often found myself playing it, usually just as a break from working on Alien Arena, and really enjoying the experience. It drove me to improve the CRX engine that powered my own game. By 2008, I was slowly starting to catch up…but it was a lot of trial and error. My early attempts at per-pixel lighting (using fixed functions) were truly wrong and awful.
Early attempts using fixed functions, and poor light data were simply awful.
By late 2008, and early 2009 though, I started learning GLSL, via the famous Orange Book, and finally, at last, had a breakthrough. In all of my game designing life, that was one of my all-time favorite moments (ragdoll physics working was the other).
The very first screenshot of Alien Arena with working GLSL (on the alien only).
I was so happy with this, and it opened up a wave of design. Pretty soon I had everything in the game using it.
All surfaces using per pixel lighting.
More GLSL came, such as Parallax mapping, shadowmapping, various lighting effects. Eventually the entire game was using it to render. During this time came the switch to the IQM model format that LordHavoc and Lee Salzman developed with input from myself and others in the Quake community.
The improvements using the IQM format were wonderful. Parallax mapping on the floor texture gives it the illusion of depth.
To this day I use IQM, as do many others, and am forever grateful for the work that went into developing it. It’s amazing to me the progress that took place in those days. At long last, our CRX engine had mostly caught up to Darkplaces, and then surged ahead with new tech such as ragdoll physics, and various shadowing/lighting changes.
Back to Nexuiz though. That game was evolving, getting new, usually better weapon models, some player models dropped or replaced, and maps constantly added/rebuilt, and some removed(much to my chagrin). The game play, much like the other open source games of the time also evolved, for the better. It was a glorious time for sure. I would either build copies from the Git repo, or anxiously await a new release, always eager to see the updates and changes. I felt though towards the latter part of the decade, that the game had lost a little of it’s charm for me. It was certainly a better game, but I missed those early maps, and the overall mood. In those days, the open sourced shooters were at their peak of popularity. However, things would soon change, and the Golden Era would begin a very rapid decline.
First, and probably foremost, Quake Live, a free, browser run version of Quake III was announced and then a beta that was free to play released, instantly siphoning hundreds of players from the open sourced alternatives. While this didn’t last long before QL began charging a subscription, the damage had been done. It also didn’t help that many of the news sources that would provide a huge boost to open source projects releases were either dying off, or losing popularity due to a glut in gaming news outlets, and a shifting dynamic. By the 2010’s, things were turning downward, though the games carried on with their diminishing fanbases.
It was March 2010 when an announcement was made that a commercial version of Nexuiz using the Crytek 3 engine and development spearheaded by none other than LordHavoc himself working for a small company called Illfonic would shatter it’s community, and bring a very abrupt end to the classic version of Nexuiz. This was indeed a dark day…
The community was enraged, heartbroken, but very quickly regrouped and formulated plans to keep the classic version alive. Oddly, I believe they were given permission to keep the Nexuiz name(as “Nexuiz Classic”), but chose to give the game a rebirth with a new name and new content. Their log was that of a phoenix. Very fitting. Other forks came about as well, but the main project was now known as Xonotic. I really don’t know the meaning or origin of the name, but I was honestly not a fan. The game however was really re-inventing itself, with new weapon and player models, new maps. These were mostly better on a technical level – though the player models I am not fond of at all, especially the skins, but the game truly had lost it’s charm for me. Pity. The commercial Nexuiz came out, and was predictably hated by fans of the original, but I thought it was certainly a beautiful looking game, though the engine was beseiged with glitches and artifacts, and poor performance. Nexuiz died a very quick, painful death unfortunately.
Beautiful, perhaps strange, commercial Nexuiz was doomed from the start.
Xonotic carried on, despite having little to no player base. It’s development seemed to catch a spark when a very talented modeler, Morphed began making weapon models. He stayed on long enough to produce new ones for most, but it’s a shame he didn’t create new player models, as those are the biggest drawback, at least visually. The maps were varied in terms of visual appeal, but most were good playing affairs.
Demo of some of the new weapons in Xonotic created by Morphed. Also shown, the “tron” styled skins of the player models.
I still follow Xonotic development, and play new releases. It’s still a good game, though I still have a much greater fondness for those early Nexuiz releases. Maybe it was the era, and the nostalgic factors. Maybe it was the maps, the atmosphere…aww heck…who am I kidding? It was the sound track! Hey Xonotic devs, bring back that eerie soundtrack, ditch those “tron” skins, and get Morphed to finish his weapon models.
I hope you’ve enjoyed a trip down memory lane, and that the current state of arena shooters isn’t too depressing. I believe there are brighter days ahead, these games have managed to mostly carry on in some fashion, with a few exceptions such as Warsow and Tremulous. Others have had a rebirth, and of course Quake still carries on in the form of Quake Champions – maybe one day they’ll actually finish it.
Alien Arena has a long history of so-called “urban decay”, post-apocalyptic style maps. While this wasn’t the prevailing theme(maybe it should have been), they found their way into the game in increasing numbers of the years. Map such as DM4, Invasion, Annihilation, Extermination, and Impact became staples of the game, and maybe some of the very best layouts. Each one of these became more intricate than the next, larger, more detailed, and more fun. At the end of this post I will reveal my latest map in this theme, that will be built for Saucermen. First, a trip down memory lane…
DM4(2003)
Downtown 2003.
In the very first release of Alien Arena (CodeRED: Alien Arena, 2003), this map was at least visually, the “star”, and inspired the very first community built maps (built by the legendary Japanese player, Whitelipper). It really wasn’t up to the standards of games of that era(none of my maps really were in those days), but it had photo textures, and a simple, flat, city block layout that serious aFPS players loathed, but casual players loved. It lasted a couple of releases before my mapping skills improved enough that it was deemed expendable. However, at least a dozen or more similar maps were created by fans of the game using these textures and layout style, with many of them improving the vertical aspects of the game play.
Invasion(2008)
A return to roots.
Quite a long time went by without another urban decal style map, as the game had really moved in the Q3, then UT2k4 style both visually and otherwise. Invasion came about during a time of major engine changes, that saw per pixel lighting, soft shadows, and a host of other GLSL implementations. The map was somewhat intended as a demo for some of the new effects, especially with vegetation, so the layout was fairly simple, with two tiers connected by a rocky hill, and littered with debris. Despite it’s simplicity, it became arguably Alien Arena’s most popular map for many years to come, and like DM4, it inspired countless fan maps.
Annihilation(2010)
Mass destruction.
Annihilation was a map inspired by a UT3 map, of which name I cannot recall. This used the same texture set as Invasion, but took a major leap in terms of the “destroyed” look of the level, and more importantly the layout was far more vertical and intricate. This level would receive updates over the years, replacing brushes with terrain, as well as various details added, and altered, though it remained mostly the same in terms of appearance and layout. I will fondly remember this map forever as the test bed for ragdoll physics, spending many nights racking my brain along with Lee Salzman as we negotiated some uncharted ODE territories with BSP and IQM formats.
Impact(2011)
Impact, showing shadowmapping from vegetation in 2011.
At this point in Alien Arena’s development, I was pushing harder than ever in terms of realism, and the post apocalyptic imagery. The theme was now becoming more prevalent throughout the game, which coincided with the “Tactical” mode being added. Impact was directly inspired by the original DM4, as a couple of city blocks in scope, but with many of the more vertical elements of newer designs, as well as the destruction level. This, like others before it, quickly became among the most popular Alien Arena maps in the game’s history. During the creation of the Tactical mode the decision was made to merge Impact with Annihilation, creating one of the largest of all Alien Arena maps. Both maps received massive updates in terms of texture, details, and lighting, creating a much more modern appearance as the CRX engine was now allowing more possibilities.
Extermination(2012)
Extermination, the final frontier.
My all-time favorite map design for Alien Arena was the final interior urban decay map I created for it. This map was gory, decayed, and creepy, with a complex layout that had the best gameplay of any of that style map. It was medium sized, a bit larger than the predecessors(other than the combined Impact-Annihilation map). There were elements of verticality throughout, circular design, and sneak paths. Extermination eventually got a CTF version as well, courtesy of the CTF map master, Rigel. This map received some refreshes once terrain tech was added to the engine, but largely remained intact.
Wasteland(2017)
The Wasteland, massive and uncompromising.
The most visual stunning and hi-tech Alien Arena map was the first map using our new terrain technology that Max Eliaser developed in 2014. This map spent some years in development, and officially was completed in 2017 for the first Steam release of the game. Unlike other Alien Arena maps to that point, it used the terrain is it’s main structure, with everything else added in afterwards. It slowly evolved from an open canyon with a few remote structures to one with a section of city within it, and wild post apocalyptic imagery, reminiscent of Rage, a game that I had been playing at that time when the map was first conceived. It’s massive size and multiple tiers of height gave it some really cool game play elements. Sadly problems with the engine’s physics have hurt the popularity of the map in the game, and the other two terrain based maps as well.
Ground Zero(2021 – Saucermen)
The bleak wasteland of Ground Zero.
Ground Zero represents somewhat of an amalgam of Wasteland, DM4, and Impact, with elements of each featuring prominently. Now unfettered by the limitations of CRX’s bsp tech, I was able to pretty much just make whatever I wanted. Like Wasteland, it’s situated in a dry, arid setting, though with some foliage mixed with grass and cacti to create spectacular lighting and shadowing effects, much as I did with Temple Of Blood. Using far more detailed models GZ has a vastly more modern look, and while it doesn’t feature the canyon style of Wasteland, it delivers the verticality of Annihilation and Extermination with various rubble and structures connecting the buildings together.
The perpetrator of the destruction.
As this map started coming together, my excitement amped up – this was really starting to look like the game I had envisioned, with rich, realistic, and terrifying elements that draw you in, especially in VR.
Looks like a scene from Full Metal Jacket.
The atmosphere really took off once I added the sky(it’s the same sky from Wasteland in Alien Arena) and tweaked the fog levels to match.
Up on a broken building.
The layout is fairly simple – it’s a decimated area of a few city blocks, with a broken highway, demolished buildings, and piles of rubble everywhere. It’s overgrown, windy, and surreal.
Lost Highway.
Spawn points are at various elevations in the level, and there are ways to get to those elevations as well. It should be interesting to see the type of fighting that takes place given the amount of cover, and hiding places.
A good place to take cover, behind a pile of rubble.
To some this probably has the look of CS or some other military shooter, but make no mistake, this is an arena – it’s small, confined, and fast. While this level is far from done, and I haven’t even begun to optimize it yet, I had no issues with framerates, it held steady at 60 with no drops of any kind. I will update some more with some more complete shots soon, and I will also announce the launching of the website in the coming days. I now have three of the map types I have planned, and will move on to the fourth (which is a snow map, with accumulating snow effects). I also will start working on the third weapon, as well as the ammo, health, and armor powerups. It’s still incredibly early in development, but it feels like a lot of things are coming together and a lot of hurdles being crossed off the list.
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:
Looking like limbo dancers with that much pitch!
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.
Ragdolls just hanging around.
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.
Given the original purpose and design of the CORTech engine, which was an underwater aquarium game, there was no question in my mind that it would be well suited to large outdoor maps. Much of the work I’d done for Saucermen was gearing towards being able to handle indoor settings with multiple (many at times) light sources. It was time to revisit the outdoor mode, so this weekend I have spent quite a bit of time on that.
I’d had an idea for a demo of this, that could also be a pretty fun map. It was to be an area with some old ruins, in a rocky, rugged landscape with a lot of trees, sunlight and shadows. The area would be littered with wrecked flying saucers, tanks, and other signs of an epic battle from long ago. Structurally, I wanted there so be a little bit of a “king of the hill” type layout, with several tiers of sloped verticality, and something that was mostly pretty open. In the end, I came up with this:
At the bottom of the big hill.In the top level dais. Many lights and shadows from foliage.Pretty good example of foliage shadows on most everything in this area.More shadow examples. It should be noted that the blur resolution is a bit low for this, and I will tweak some for a smoother appearance if possible without hurting performance.At the lower dais. There is a lot of open space in the map, though once I add grass vegetation, it will probably feel a little less open.
So now I have two “demos” of two different types of maps for the game, I can work on effects and making things work for both scenarios. There was already a good bit of tweaking that I needed to do, and without breaking things. During this time, I was also able to fix a few nagging artifacts.
How many times have I posted over the past months saying “I’ve got it!”, only to discover later that I really didn’t? Man…it’s been a few to be sure. It’s weird how that happens to be honest…sometimes you know in the back of your head that something is just not quite right, but you’re caught up in the euphoria of having made a solid improvement or breakthrough, and you get ahead of yourself. I am the king of that, haha.
In my last post I threw up a bunch of screenshots of the “saucer”, and while I was reviewing my post, I noticed something was a little off on the player models lighting. I had also noticed that the new dynamic lighting seemed off in much the same way. At various times I yet again noticed that certain map objects, especially larger ones, seemed a little weirdly lit in places. I really couldn’t put my finger on it, but I knew…oh I knew…
Let’s look at a shot that really shows the problem:
Do you see the problem here?
Well, at first I really thought this was a great example of the lighting and shadowing in the engine, but there is actually something a little off on the player models. Their left sides show a decent amount of shadow, when it actually should be brightly lit. I started noticing that most every screenshot of player models had the same issue. Also, further back, the wall near the ceiling is quite brightly lit. That is also wrong. Now maybe you think, ok, maybe it’s the shadows that are wrong, but that is not the case. The shadows are generated prior to translating anything, but the lighting is generated on another pass that is post translation(there are reasons for that, trust me!). Knowing where my light sources are, and how the shadows are, I realized that the lighting was off. This really aligned up with what I was seeing in dynamic lighting – that when shooting a lit projectile down a hall, that one side of the hall seemed lit up more than the other.
There was no doubt in my mind that I was not translating the light sources in concert with the meshes. In fact, it seemed obvious now that everything was 90 degrees off on one axis. I looked at my code and saw the problem immediately. DOH! I literally had the wrong X axis translation, I think I was experimenting and never put it back. Well now, that was a quick and easy fix! I fired the game up…and well, things looked quite a bit different! I made some fixes to the maps lighting, fog, atmosphere, and got it tweaked to have a good mix between the diffuse and ambient light values (which when a map is made of a bunch of large meshes, it’s pretty crucial). Now I saw a vastly improved lighting, and all of the weird lighting artifacts? GONE. WOOHOO!
Look at a similar shot and how the lighting looks –
Now we’re talkin’!
As you can see compared to the previous shot, the light on the left/front side of the model is much brighter, and the shadow matches what you’d expect. The walls in the rear now seem to blend more with the ceiling as well. The objects hanging from the ceiling, they also blend in better with the ceiling. These things may seem subtle, but believe me when moving around in the world, it’s a massive difference and really makes the renderer feel accurate and smooth.
You may also note that the tone looks a little warmer and more alive. This shot also exemplifies the more natural look –
Main room, with the lighting fixes and updates. Note how the ceiling is evenly lit, where as in previous similar shots there would always be some panel that seem bright and out of place. I believe I have the atmosphere and lighting more appropriate for the theme of the level as well. This feels right – and notice how the scene now “pops” with the updated/fixed light bloom effect.
The main reason for this is, that I fixed a long standing bug with the light bloom code. This was another major DOH! The idea is that you sample the bright pixels, blur them vertically, then horizontally, and then blend them over the scene. Well, I did, but made a really dumb mistake. Like really, really dumb! I was sampling, then blurring vertically, blending over the scene, then taking the sample, blurring horizontally, and blending over the scene again. But wait…what? Of course that’s not right. You have to blur vertically, then blur the BLURRED image horizontally, then blend. Now that is fixed, and what a huge difference it made! WOOHOO!
By now you’re probably thinking hey, what’s that weapon in the last screen shot? Well yes indeed, there is a new weapon, and it’s fully functioning! This would be the grenade launcher, a weapon that flings out a grenade with a big punch. Took a while to get all of the physics right, but it works really well, and I’ve gotten the bots using it effectively too. Doing all of this led to me cleaning house on a number of unused items, and it will lead to further consolidation. It’s getting close to the point where I will add the final weapon, and then the various ammo/armor/item entities. I should also add that the map editor is getting improved as I go along, and I also will soon (very, like next) add a new map test of an outdoor area. This will also lead to me refactoring how map objects are loaded at some point, which will mean a lot more management of assets and physics. Yuck – but a necessity. It’s been fun just being all irresponsible and carefree with assets and memory but I guess it’s time to get serious.
Meanwhile, here are some new and some updated screenshots of the Saucer with all of the lighting changes:
Things that should be lit, are lit.Compare this with the previous posts where I have taken this exact shot! This is a striking difference.Lighting is definitely more even, warm, and glowy.No room shows the drastic fix in lighting more than the Giant Robot Room. While the previous shot had a different model for the ceiling, even the new model couldn’t fix the bad lighting. Now everything looks lit as it’s supposed to be. This shot really shows the improvement to the light bloom effect compared to the previous post. The glow around the brain in the jar is dramatic in comparison.Lighting and shadows – all handled real time, dynamically. There are no lightmaps used in this engine.
The last thing to write about here will be the third weapon. I believe previously I had discarded the idea of a hit scan weapon, but I’m leaning more in that direction. Not set in stone, and a part of me really wants to deviate from the normal aFPS weapon set, but it’s hard to picture this game without some sort of raygun beam weapon. I know the color I want it, and the overall look/size/feel. What it’ll do is still up in the air though…
I now have some more of the layout roughly down, and tweaked some textures/colors, added new bits and structural parts. I won’t add the more “micro” details until the entire layout is complete to see where I can keep it under reasonable limits. Of course during this process, found some more bugs, fixed them, and ran into more problems, coded around those. Of significant note, I really improved the bot AI, and also fixed my issue with particles finally. I have a minor issue with alpha entity sorting to figure out, one way or the other. I know what the issue is(very large alpha ents need to be accounted for).
So far, as I mentioned, the lighting of the level is much more like the 2007 version of the map, with a good amount of ambient light, and a lot of light sources to keep it pretty brightly lit overall. I wrestled with the idea of making it dark and moody like the 2009 and 2003 versions, but I really like the visibility factor of the brighter versions, and it’s going to have quite a bit of blood, gore, and shiny stuff to set the mood. I am particularly excited to get started on putting in the gore…shiny blood puddles, blood spatters, and bits of flesh and bone everywhere. These aliens are sadistic and ruthless, and their lair will be representative of that fact.
Meanwhile, here’s some progress shots…
Lower floor in “lab” area. Note the texture change of floor and ceiling panels to light blue/orange(lit), with circles instead of (too) busy tiles and dividers. Note the trash pile to the left. When the level begins to get closer to completion, there will be more “destruction/grit” like this added, along with the gore.Also from lower “lab” floor, view of the staircase and passages out. There are 3 passages out on the lower level, and 3 out on the top level. Needless to say, much like previous iterations of the level(the 2007 and 2009 versions) the “lab” will be the area players gravitate to for battle. It is the center of the map, and all paths lead to it. Bottom of “power core” room. This room will probably get some different/more objects in it, just threw some electrodes in for now. This is a good example of the shadowing effects too.On the stairs in the “power core” room. This is divergent from the original designs which had the halls under/over one another and going in the same direction, with only the top going back to the lab, and the bottom was going to the “giant robot” room, and being very, very long. Having the lab in two tiers really changes everything about the map, and how circular/connective it all is now. There will be a lot of piping and weird alien power devices added soon to this room.
I have the “helm” room laid out in Blender, and will add those sections next. It’s the smallest of the rooms, and more irregular in shape. This will house the pilot controls, navigation, and of course the alien that controls it all. It also will reveal the “secrets” of the story – guaranteed to shock the long-time Alien Arena fans! I also fabbed the “giant robot” room, which completes the layout. This will require several new art pieces – the robots, and another ceiling piece, and stairs.
Layout mostly complete – few missing pieces here, but I do have the parts made. The only “dead end” is the “helm” area – which will have something valuable to pick up, but risky to do so. The robot will set in the circle at bottom left. Not sure yet how the stairs in that room will be configured.
The main layout change that should be obvious to long-time fans of the map, is that the lab room is much larger than before, and the robot room is more snug to it. In fact, all of the rooms are much larger, and the hallways shorter and compact.
Just for reference/nostalgia again, here are more pics I dug up of the older version of the map:
Super old-school, looking down on the “lab” area in 2003. This level was so dark, but it really did have a mysterious atmosphere.I had to search long and hard for this image, but this is The Saucer in 2007. Most players considered this their favorite iteration, despite the 2009 version being basically the identical layout.The “giant robot” room in the 2009 version. While the layout was identical to the 2007 map, players didn’t seem to like this one as much, to my chagrin.
With each passing evening, I add a little more to this map, and discover that algorithms that worked at one stage need to be re-factored, or worse, completely re-thunk(is that a word?). The good news is that I believe that I at least have most of the data I need, it’s just a matter of using that data and translating it to the game engine in a meaningful and visually appealing way. Along the way I’ve also discovered serious needs to optimize things, and make it much more flexible and dynamic. A lot of this engine and game code was written for a limited, tiny game (Frenzy) and needs to be expanded and rebuilt to accommodate the much more intricate environments of Saucermen.
With that said, I have found that in order to make this thing look right, light placement is paramount, and that more light sources provides a more accurate lighting model. It’s nice(and so very helpful) that the map editor I wrote allows me to see everything in real-time as I place it. I have modified and tweaked a lot of things in the past week here, including coming up with a way to better control shadows, especially from static map objects that can often be problematic. The solution isn’t perfect, but it’s very efficient and looks nice. Overall, I feel like it has come a long way…
The beginnings of lighting/shadowing. It’s pretty mucked up at this stage, though at the time I felt I was close. I was not.Same view – a month later. Much has changed.More shadows, both world and player.
It bears repeating – shadows are all done in ONE pass. My algorithm seamlessly fades from one light source to the next. When you move away from one light source and towards the next one, the shadows slowly fade down to zero at the halfway mark, and then the next light source shadows begin to fade up. In larger, open maps, this isn’t very noticeable, but in a tight map such as this with many light sources it certainly is, but it’s not annoying or abrupt. At some point I may expand this to use multiple shadow maps, but for now I will wait and stick with this until I get closer to a finished renderer to see what the performance differences would be.
The map itself is roughly at the halfway mark of the “layout” stage. It’s currently at 170 entities and 21 lights. The entity count is actually decreasing as I have been combining meshes that make sense (like a hallway section was previously 3 entities – 1 each for ceiling, floor, wall – and is now 1). I should have it down to around 150 before adding the other sections. In the end, along with additional detail pieces, I think it will push around 400 total. This would be an extreme example of a map for this game, which is the intention here, to push it to it’s limits. There are about 120k faces(quads) to this point – which really isn’t a lot. I’m currently working on the power-core room, just to get enough of a circular layout to play around more with AI. I’ll jump back on the lab and add the other bits such as the giant robotic arms, light fixtures and lab tables with gruesome things on them.
Confessions of a serial game designer 