Back when I started writing this little engine for Frenzy, a friend in the industry asked me why bother, just use Unity, it already has everything you want, and it’s VR ready. I replied to him – “Because I love doing this stuff”.
He’s right you know. I could have simply done all of this in Unity, so easily, and have it done very quickly. But what fun is that? Personally for me, writing an engine from scratch was always a dream, or goal, after I had gotten my hands on the Quake source code back in the day. Once I started upgrading the rendering side of things in OpenGL, I knew at some point I would begin such a project. The Quake source, especially Quake 1 and 2, is archaic, and quite bloated in many areas due to much of it being pioneering as well as having to deal with the architecture and infrastructure of the hardware and OS of those times. My goal was to simplify EVERYTHING as much as possible, and use modern shaders and techniques.
Eventually I had my engine working, the renderer, net code, and game code, and it was simple, elegant, and very easy for me to look at and pick back up after time away from it. I have gotten to the point now where I’m stripping it down and removing things I won’t ever use, and cleaning up things that I veered down the wrong path on. Currently I am focusing on lighting and shadowing, and while I have an idea of how I want to handle these things, I am not totally certain how it will end. There are still some things that aren’t working 100% correctly that need to be addressed, but it is definitely getting closer to how I want it. This piece is really the major piece I need to get completed to push the renderer beyond what I did in CRX. Most of the CRX features are already there, as well as some that CRX does not have, or some that have been improved upon.
The animation system is working much better now, and more fully featured as I’ve added the jumping and pain animations, also in correlation with improving the bot AI. The bot AI is definitely one of my favorite things to tackle, and theoretically it will likely resemble some things in Alien Arena, but on the whole it’s new, and has to be.
I’ve also been working on improving the test map section, changing the palette slightly, and adding some details. It’s getting there, but far from where I want, or it will be in the end.
The biggest breakthrough is however, that I have shadowmaps working! I have for the better part of two decades always been on a mission when it comes to gaming and shadows and building a better mousetrap. In the mid-2000’s I sort of pioneered a soft stencil shadow technique that was really cool – although taxing on CPU’s. I later worked heavily on shadowmapping, and I believe I had the first working version of that in any Quake-based engine. Max Eliaser later came in and refined my original designs, which worked quite well. This time around I have been taking a fresh approach, though some of the logistics to work out required me revisiting my old CRX engine to see a few things that I had done to “solve the puzzle”.
So far these work really well, with my single light source in this test scene. This is of course the conundrum of every game engine developer – doing this in a way that doesn’t kill performance. I believe I have a methodology that will work. Unlike CRX, which allowed for some BSP trickery to achieve things, CORTech is “mesh soup”. The ideal way to handle shadow mapping is to render a shadow map for every light source – which is often a lot of light sources. You can mitigate this a bit by only doing it for light sources that are relevant to the player’s position, but you’re introducing the possibility of odd artifacts, like shadows jumping on or off when you move. One way to make this less obvious would be to fade the shadow based on the player’s distance from the light source – which makes sense on a number of levels anyway.
This theory can be taken a step further. Assuming we are not going to get crazy with light sources and shadows(this is a game, not a ray-traced rendered still scene) – we really can keep this down to rendering one shadowmap, for the light source the player is closest too. Since I’ve already decided to keep light sources to say 16, or 32, at most in any map(this is an arena shooter, maps aren’t typically going to have so many sources, they are small by nature), we could base that fade factor on how close the next nearest light is (that the player is between) – and have a very smooth shadow transition for when the shadowmap is switched to generating from a different light source. This would help with maps that have light sources closer together – though it’s still incumbent upon map designers to properly set their maps up – luckily the map editor is real-time, and you can easily see how it will look and behave.
The other issue is filtering out what objects cast and receive shadows. Some of this can be automatically done, other items I will leave up to the map designer to set the flags. For example, you probably don’t want walls, ceilings or floors casting a shadow, but objects laying on the floor, or against the wall, or hanging from the ceiling, you would want casting shadows. This is all the easy programming stuff though – the hard part is of the way.
My light source management will allow for color, amplitude, and direction, which is something that CRX really didn’t handle as well. There will also be ambient and other settings that are global and handled in the map. This is all rendered real-time in the map editor, so map design is really intuitive and fast. At this time, I have no plan for lightmaps or anything similar to that, as the normal mapping handles a lot of the shadowing of faces that are not facing the light sources.