The custom occupation editor has been expanded on, making it more flexible than ever and we’ve even implemented weather effects to keep things interesting.

The Overwhelmed dilemma has a chance to occur when your group faces staggering odds after breaching a location. You’ll be able to retreat to, hopefully, a safe location or, if you’re feeling lucky, try your hand at more heroic options.

Getting around during a zombie apocalypse is not the cleanest affair, so your survivors will accumulate grime and if left idle, will now occasionally wash themselves. Doing so will provide them with a small morale boost.

We felt the towns of Zafehouse: Diaries were drier than they should be, so now it’ll occasionally rain and storm. As you’d expect, noise doesn’t travel as far under these conditions, so be sure to take advantage of the weather when you can!

Several dilemmas, including the Lynch Mob, Moby Dick and the Girl Scout Family, now feature an assessment of your survivors’ chances if you decide to fight. As a result, it should be easier to make more informed, strategic decisions regarding these encounters.

Finally, for users with high-resolution displays, a scaling option is now included so that game takes up most the screen. It is currently experimental, so if it doesn’t work as expected, let us know so we can tweak it!

The update includes several other tweaks, fixes and improvements, all of which are mentioned in the patch notes on our forums.

Direct purchasers and GamersGate customers, the patch can be downloaded from our support page. For Desura and GOG users, please use the facilities provided by these services to update the game. Note that updates from these distributors may be delayed while the patch is approved.

On the gameplay side, v1.1.7 features a new dilemma, called “The Believers”, as well as the Priest occupation to accompany it. A new ranged weapon and ammunition type has been added — the crossbow and quarrels respectively. While the crossbow has a slow rate of fire, it makes up for it by being extreme powerful and very quiet. There’s also the possibility of retrieving fired quarrels when cleaning corpses after a fight, making it more economical than the bullet-based ranged weapons.

Barricading has been reworked significantly. Secured and fortified locations will now impart meaty bonuses to spotting and resilience; noise levels inside will be reduced and survivors will sometimes automatically attack zombies through barricades. Barricades now also last longer against zombie attacks.

We’ve also made a thrilling change to the Infection dilemma. Along with the usual “Let them live” and “Kill” options, there will sometimes be a third option with the potential to save the survivor and rid them of the infection. The price, however, may be too great…

These are the biggest changes in v1.1.7, but we’ve added a bunch of visual tweaks, balance changes and bug fixes we’re sure you’ll appreciate, so check out the full patch notes on the forums.

Direct purchasers and GamersGate customers, the patch can be downloaded from our support page. For Desura users, please use the Desura client to update the game.

The most exciting addition is an entirely new game mode, called “Road Kill”. Search the town and scavenge for parts for a broken-down vehicle. Your survivors will then have to fix the vehicle before they can drive themselves to safety. To support this new mode, we’ve not only added new content, but modified existing dilemmas and events to reflect the altered objective.

The best thing about Road Kill is that rescue is now entirely in your hands — the game won’t end unless you drive out… or die. Even if you do make it out alive, relationships and the supplies you’ve gathered play an important role in just how well you do. How these affect the end result, well, you’ll have to play and find out!

Road Kill represents the largest addition to the game since its release; it really changes the way you approach the game. You’ll have to re-examine those rock-solid strategies that served you well in Classic mode and try different tactics if you want to succeed.

For players who like to share their games, you can now enable sharing functionality via the options menu. When active, hovering over diary entries will show a “copy to clipboard” button. This should make it easier to quickly paste text into forum posts or documents. We hope to expand this feature in the future to support popular social media sites.

As usual, a complete list of fixes, changes and improvements can be found on the forums.

Direct purchasers and GamersGate customers, the patch can be downloaded from our support page. For Desura users, please use the Desura client to update the game.

Note that the game is in heavy development and the game’s features and design are not yet final.

Head on over to sign up for updates, follow us on Twitter or just drop by the forums and say hi.

Well, except when I use native GDI calls to paint instead. Actually, now that I think about it, GDI+ doesn’t do a heck of a lot for Zafehouse 2 anymore.

Now, this change raises a number of questions: Why not use Direct3D for the entire process? Why change APIs in the first place? Isn’t the Direct2D API in DirectX 10+ basically what you’re describing?

These are all fair questions, and I’m going to try to answer them.

Why not use Direct3D for the whole shebang?

Because I’ve already done a lot of groundwork for image rendering that replacing the engine wholesale would add a lot of time to the development process. Considering the game is already years overdue, I doubt anyone would be excited about the news of me delaying the game just to rewrite a chunk of code that doesn’t need to be rewritten. It all works fine, I just needed something more powerful than GDI+ to get the heavy lifting done.

Why move to Direct3D in the first place?

Primarily, it was a question of speed. Secondarily, I wanted to improve my knowledge of the DirectX API, having already implemented my own xWMA audio engine, which relies on the XAudio2 API. So the game already depended on DirectX, through the managed SlimDX wrapper.

Isn’t what you’ve described basically Direct2D?

It kind of is, and I could have just used the Direct2D API to quickly accomplish the GDI/GDI+/Direct3D fusion. Except Direct2D is a god-awful API. That, and Direct2D requires a DirectX 10-compliant graphics card to run, as well as Vista or Windows 7. It’s bad enough Z2 needs a DirectX 9.0c-compliant card now, and I didn’t want the make the situation worse. By writing my own routines, Z2 remains compatible with Windows XP and graphics cards circa 2005. Which is pretty good, all things considered.

How does it work?

In technical terms, Zafehouse 2 generates a couple of D3D-compatible textures from PNGs for compositing purposes at startup. This takes a couple of milliseconds. We also create some device independent bitmaps for direct blitting, but we don’t have to worry about that.

Whenever compositing is required, the game sends the textures to the D3D renderer, paints them to an off-screen surface, downloads the data into system memory, and then blits it directly to the GDI+ graphics object using GDI calls. In the case of Intel chips, we lock the surface and perform the blit directly. In the case of NVIDIA/AMD cards (which use dedicated video RAM), we copy the surface to another surface in system RAM using GetRenderTargetData, and then blit directly from that surface.

The reason for the two different paths is because it’s faster to copy directly on Intel GPUs as they don’t have dedicated video RAM so, essentially, locking the rendering surface is like locking another chunk of system RAM and doing a direct copy which, as you can imagine, is faster than copying it to another surface in system RAM and copying from that.

For cards with dedicated RAM, locking the video surface directly is actually slower. GetRenderTargetData is heavily optimised for these chips, so doing a surface to surface copy followed by a blit is actually pretty fast, even on crappy low-end NVIDIA/AMD cards.

The result is a GDI/GDI+ based graphics engine that offloads compositing (so alpha-blending and overlays) to video hardware. This means we can make use of hardware acceleration, as GDI+ is completely software driven.

It’s true that copying data from video RAM to system RAM is a bit of a performance hog (and I’m sure there are more than a few coders out there shaking their heads), but in practice it’s much, much faster than even the most heavily-optimised GDI+ routines.

What is GDI+ good for then?

Rendering text. My god, it’s great at that. I actually implemented text rendering via D3D in my renderer, but it looked like garbage. GDI+, on the other hand, looks amazing, as it supports a number of quality features D3D’s Font class does not (hinting, gamma correction, etc). So, I’m happy to take a minor performance hit to keep text rendering in software.

GDI+ also makes alpha-blending images easy, but the performance hit is quite nasty, even with double-buffering and razor-accurate dirty rectangles. Credit where credit’s due – it’s simple to use but not at all a great performer.

First, history. The original Zafehouse lacked many elements one normally expects from a game. Graphics. A proper tutorial. Sound. These are slowly being rectified in the sequel. Graphics are being taken care of handily, and a tutorial will be implemented once, well, the game is.

Sound… sound was an interesting one. There are many ways to play sounds in Windows and .NET. You can use the basic, in-built functionality in My.Computer. Or you can venture into the slighly more complex world of System.Media.SoundPlayer.

Both, sadly, are kind of garbage if you’re trying to make a game. That is, a game with more than one or two sounds playing at once. There’s also the problem of being limited to PCM as an audio file format. Hey, if I was willing to have Z2 weigh in at a couple of hundred megabytes, then PCM would be fine. Hilariously so.

But I think my download server (and everyone downloading from said server) would be upset. So upset they might convert from downloadees to “I-hate-you-Logan-for-wasting-my-download”…. ees.

So I started investigating Managed DirectX. MDX is a wrapper around the standard DirectX libraries so you can use them in C# and VB .NET, among other languages. DirectSound under MDX didn’t look too foreboding, and I went ahead and implemented a basic audio engine capable of playing multiple sounds and background music.

Now MDX will play anything that resembles a RIFF. Well, anything that resembles a RIFF and contains a PCM or ADPCM stream. Anything else and it will spit at you like a pretentious hydra being served broiled heads instead of boiled ones. Because hydras like boiled heads.

ADPCM isn’t really a compressed stream. It’s just PCM reduced from 16 to 4-bits. Other stuff happens to maintain sound quality, but essentially you end up with something many times smaller than the original PCM. The only problem is, to (barely) match the compression ratio of MP3, Vorbis or WMA, you have to cut out a channel.

Stereo to mono. Which ain’t so bad. Truly, it’s not. And, in some cases, ADPCM can produce audio that sounds better than what a psychoacoustic codec can crank out. As long as you don’t mind a bit of hissing.

But I wasn’t satisifed. I knew I could do better. I was particularly certain of this betterness when I read that Microsoft was encouraging developers to move from MDX to XNA. It gently encouraged this by flipping the bird to MDX.

Yes, I had just written an audio engine in an API no longer supported by MS. Sweet, I thought, and began searching for alternatives.

There are a bunch of free audio engines that work in .NET, but if you ever want to commercialise your product, then you have to fork out megabucks. And I didn’t want to lock myself into that sort of situation. The idea of using a pre-packaged solution didn’t tickle me the right way either.

I fiddled around with Vorbis, but had trouble tracking down a native implementation in VB .NET or C#. I did find one in the Mono repository, and even got it working. Problem was it was slow (Vorbis-to-PCM conversion, specifically), and it still relied on MDX.

Sucky? You bet. Extra sucky because I know squat about the inner workings of Vorbis and had no idea how to optimise. I didn’t really want to spend time doing it. I have a game to finish, after all.

XNA appeared my only option. After getting the libraries loaded, I realised it was too high level. Which means it didn’t give me enough control over what it was doing. Much sighing occurred.

Then… I found XAudio2. Its documentation was hidden away in MSDN, but there it was. XAudio2 is Microsoft’s replacement for DirectSound, and it’s the underlying tech for XNA’s audio stuff. XAudio2 is nifty. It would have been even more nifty if all the documentation wasn’t as verbose as a mute sports announcer. Oh, the documentation is for C++ only, so make that a mute sports announcer who only speaks Esperanto.

But XAudio2 supports xWMA out of the box. xWMA is a stripped-down version of WMA encased in a RIFF container. Yay! It was exactly what I was after. I grabbed SlimDX, which allows you to access XAudio2 (and other multimedia-related libraries) via a managed wrapper, and buried myself to the armpits in code for a weekend.

Eventually, I came up with something – dare I say it – sound. An audio engine blindingly superior to what I’d previously concocted. It plays up to 64 xWMA-encoded sounds flawlessly and with only a minor hit to memory consumption (much less than the MDX monster I was working with).

Only now I need to include SlimDX with Zafehouse 2. I went from a 9MB audio package encoded in ADPCM, to a 7MB xWMA one with a 3MB DLL. To be fair, the new audio is all stereo (which makes the music sound that much better), but I still feel like I’ve run in a giant circle.

The circle does crack out some fine dual-speaker tunes, though.

It grew, exponentially, until it wasn’t what it needed to be – a successor to Zafehouse. It became its own game, a game I didn’t want to make.

Consider it the first prototype.

A little side project – a 2D map generator – I’d been working on while hacking away at Deadshed suddenly became the new Zafehouse 2. It was closer to the game’s original vision, just with more stuff. Lots of neat features were added to this generator, until it started turning into a game.

And then I got suckered into building three combat engines, which culminated in a solid tactical 2D game. I’m actually happy with the result, and I have no doubt a fun game of some description could come of this project.

But again, it wouldn’t be Zafehouse.

After spending weeks contemplating the future of the game, I decided to follow my gut. As painful as it was to do, I shelved the Zafehouse 2 codebase and accepted it as the second prototype.

I then started on Zafehouse 2.5, scavenging a couple of chunks from Zafehouse 2 – the audio engine, random name generator and a few miscellaneous bits and bobs.

Yes, I’m essentially starting Zafehouse’s sequel from scratch, again. But the clarity of thought, purity of design, experience and elegance I’m bringing from Deadshed and Z2 are worth their weight in blood-stained gold. I’m finally happy, completely, with the direction the latest incarnation is taking and, for the first time in at least a year, I’m really enjoying working on the game. The inspiration and passion have returned, and these are by far the most potent qualities a developer can bring to a title.

So there you have it – an honest assessment and lowdown of the current state of the project. For everyone who’s stayed with the game, I can’t begin to thank you for putting up with the sparodic updates and procrastination. This year’s been hard on the game industry, particularly in Australia, both emotionally and financially. It’s good to be able to once again take a firm grasp of the fundamentals, the primal drive for doing this thing, and wield like a dwarven berserker would a mangled hatchet in the face of a stalwart, somewhat insane orc army.

As for tangibles, expect screenshots and gameplay details in the New Year. Until then, enjoy the holidays.