Well it’s been over a year since the last alpha so I’m not really sure we’re sticking to any conventional system here! We’re getting close to a public early-access release now as most major gameplay elements are working and ready to be balanced and tweaked.
So here’s what we’ve added and (at the end)subtracted from the game in the last year or so:
Added bloom pass.
Bloom gives the level a soft glow, where we want it. the classic example of this is at night with a neon sign. Your eyes add a halo around the neon light. Here is the Stanford Bunny without bloom on the left and with bloom on the right.
Cleaned up the shadow pass.
General improvements to the renderer allowed us to throw more at the shadow pass. Shadows are really a total PITA. We optimized the forward renderer in general and cleaned up the clipping so that objects that aren’t rendered in any color pass can still cast shadows in the shadow pass. In general our shadow buffers are 4096x4096 which gives much more accuracy and means the blur pass doesn’t add too much noise to the final shadows. Here you can see the shadows at normal distance and VERY close. You can see that close up the blur is adding artifacts. These atrifacts wobble as the camera moves. They are undetectable when the camera is far away though.
Cleaned up the Depth of Field pass.
Depth of field, unsuprisingly, gives the player a much greater sense of depth in the scene. We were overusing it in the previous alpha to hide some of the artifacrts from the shadows. We’ve cleaned it up now and it looks a lot more subtle.
Better clipping to speed up rendering of shadows and color pass.
Clipping is pretty easy, you’ve got a view frustum and things that are outside of the frustum are clippped… unless they need to cast a shadow, then well you’ve got to fudge it a bit. For the shadow pass we just add a “grace” value. So if an object is outside the view frustum by say within 10 meters we render it’s shadows. This isn’t the most efficient way of doing it but it’s all we’ve got time for at the moment.
At the beggining of the project I made the mistake of using Axis Aligned Bounded Boxes for the clipping (everything is a cube right!). I wish I’d stuck with spheres. Much cleaner and simpler.
We’ve still got bugs with animating objects not correctly updating their AABB when bones move far from their bind position. Gotta make some time to fix that.
Dropped custom UI code for nuklear
I really resisted throwing away our old HUD code. Especially in favour of immediate mode UI systems like Nuklear or ImGUI. I still don’t particularly like immediate mode HUDs but having used Nuklear for a week or so it is indeed very fast to work with and relatively easy to integrate in to Lua. It’s true that the lack of state does make it easy to create an interesting GUI. Nuklear’s code is very interesting to read as well. I do love looking at well written pure C code. It’s a lot easier to decipher than C++. There is a rawness and elegance to it. What I didn’t like is it’s dependence on asserts within the code for debugging. An error logging API would be better IMHO.
Total rewrite of the Bullet Character Controller to be more efficient
Bullet’s character controller support is pretty poor compared to Havok. I think everyone knows that. We moved away from their btKinmaticController and toward a custom btRigidBody with a few ray casts. It’s a lot LOT cheaper, especially when there are 10-15 enemies on screen all bumping along. It also gave us an opportunity to implement pushing in a more pleasant way.
Added locale support to the App and Editor
Like it or not, not everyone speaks English! Shock news. So we’ve added locale support via SDL, an Excel speadsheet of faux translations, utf8-cpp and nuklear’s font rendering.
Heat have is a pretty simple fullscreen pass where you record how perturbed a pixel is during normal rendering and then before presenting the frame you wobble the pixels around dedpending on how perturbed they are. Nice and simple. You can see it in the crash site in the Alpha 5 video (at the top of the page)
Added Decision Trees.
We don’t have super complex AI in Smith and Winston but the state machines we were using were getting really messy. So we switched to decision trees. We took some sample code from one of the AI Wisdom Books, jiggled it about a bit, exposed it to lua and now we can build simple trees. What I like is you can build simple predicates such as “can I see player”, “can I shoot” or “have I been hit” and fashion a tree of action and reactions that are easy to follow and because the predicates are easy to debug it speeds up the whole process.
.. and now for the bad news
Dropped the Mac/Linux version for now
This is not a descision that we took lightly. I really miss being able to turn to clang and the excellent debugging tools that XCode offers. However my iMac is getting a little long in the tooth and Smith and Winston was starting to push it’s little embedded ATI graphics card too far. Combined with my general lack of time and a need to make more progress on at least one front meant we had to take the tough decision to cut. We’ll be porting later though if all goes well.
Did a VR version of the game for a publisher but it didn’t stick.
We spent three months working with a publisher on and off on a VR version of Smith and Winston. We approached them with the idea and they were very keen. In the end the demo was really, really good and great fun but we couldn’t make the numbers stick.
VR takes a lot of time to test and you need more audio resources and time devoted to creating an interesting sound enviroment. This translates to more costs and we had to agree to disagree in the end. We understood their position, after all we’re a small team and it would havew been our first VR game… but if you’re gonna do it NO point in half arsing it… it’s full arse or nothing where we’re concerned!
By the end of the process we REALLY wanted to make the game but we dusted ourselves off and moved on. At least the engine got a lot of optimisations appled to it so the 3D version still benifits.