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.

No related posts.

The “I” shaped objects represent doors, while the “O”s with the funny curves are windows. A window is currently selected by the player (the red circle) and a little image shows you how fortified it is. Red arrows mark entry vectors. Oh, and survivors can’t walk through barricaded doors or windows… so keep that in mind!

Still lots to come, so hang tight!

No related posts.

Development is ongoing and I’m getting closer to an alpha release – much closer than the previous incarnation of Zafehouse 2 ever managed. Trying to hit dates, but it really is unpredictable right now. Just know that I’m working hard on the game every chance I get. This is about 2-3 hours a day right now.

PS. Ignore the note text… it’s purely placeholder. ;)

No related posts.

Welcome to the new-look Zafehouse 2, or Zafehouse 2.5 to help separate it from previous efforts. The game is based entirely around manipulation of a dynamic journal. Chapters keep locations, events, supplies and survivor information nicely contained. A special context-sensitive entry system allows you to configure events, lock them in, and then accelerate time. When something occurs, time will stop, allowing you to react however you see fit.

Survivors will report in as they return from their adventures, meaning you must rely entirely on them for information. Figure out who to trust, and you’ll do fine. Piss everyone off, and you’re all doomed.

Expect more shots and info in the coming weeks.

No related posts.

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. :)

No related posts.

A few things, though:

1) It’s a demo! There’s probably 10 minutes of gameplay in this thing, tops. It’s just a taster, a sample. It’s not meant to be a whole game. I desperately wanted to let people know that yes, the game is still in development. The demo is also a platform to deliver feedback on the general feel and direction. Try not to nitpick, but don’t hesitate to offer a comment or two.

2) Read the readme! It contains a list of requirements. Before you start posting that you can’t get it working, make sure you’ve installed all the necessary software and are running the correct operating system. It should go without saying I can’t provide support for anyone running the game under emulation (WINE, VMWare, Mono, etc).

3) Speaking of reading, look at the demo tutorial! If you just jump into the game and are completely lost, be it on your own head. If you read the tutorial and still can’t make heads or tails of things, go ahead and fire some questions.

4) The download is around 8.5MB… just in case that’s going to bust your download limit for the month.

5) Performance. It’s not as fast as it could be, especially when you have a lot of overlapping awareness arcs. Optimising comes much later when the rest of the game is solid.

All I can think of for now. Will probably update this post as I remember stuff.

Download: Zafehouse 2 combat demo

FAQ

When I run Zafehouse 2.exe I get an error about reading game values
Download this replacement executable: http://downloads.zafehouse.com/zafehouse2/z2fix.zip. It should fix the problem.

When I run the game, I get an error about the audio subsystem
To fix this, you’ll need to install the following files:

SlimDX runtime
The latest DirectX 9.0c runtime (note that Windows Vista and Windows 7 do not come with DX9 by default, and having DX10 is not enough!). You can also try the end-user runtime
Microsoft Visual C++ 2008 runtime
Microsoft Visual C++ 2005 runtime

I’m still getting errors!
We can track down the exact problem using Dependency Walker. If you’re not afraid of a little techiness, download DW, run it and then drag the SlimDX.dll in the Zafehouse 2 directory into the program’s open window. It’ll tell you straight away what’s missing!

No related posts.

So, if you’d like to keep abreast of developments, sign up to the Zafehouse Twitter feed: http://twitter.com/Zafehouse. For major features or changes, however, I’ll be writing them up here on the blog where there’s more than 140 characters to play with.

For those who haven’t been following Twitter, I’ve finished implementing the new, saner firing code and am charging ahead with the tutorials and general polish.

Not long now…

No related posts.

The code also did something unexpected but extremely neat – zombies fade into view as they move adjacent to a survivor, so it looks like they’re coming out of a fog to attack you. It’s quite terrifying.

I know a lot of this sounds like gobbledygook as combat has changed so much since the initial video, but I wanted to let everyone know ZH2 is definitely alive. Well, as alive as a zombie game can be. Once you play the combat demo, it’ll all make sense. Trust me!

I’m moving onto the firing code tonight, because it’s been bugging me for a while now. I’m trying to figure out an elegant solution to adding bursts into the existing system, but I’m concerned I’ll need to rewrite it. Which would suck, as I’ve already rewritten it once.

Ah, to refactor or not refactor… that is the question!

No related posts.

Fiddling around with the firing logic too. At the moment, survivors try to guess how many shots it’ll take to kill each zombie in their line of sight, starting with the weakest. I thought it was cool until someone pointed out that it’s not realistic. At all. It’s also annoying when a survivor guesses a zombie should take two shots to kill, they fire those two shots and… one of them misses. Cue unexpected flesh-munching.

What (trained) people usually do when they fire a gun is use bursts. The new firing logic will go “Okay, I’m going to fire x rounds at the closest, weakest zombie I can see. If it dies, move onto something else. Otherwise, fire another burst”. The x is determined by the weapon and experience level of the survivor.

Once the combat demo is out, I’ll be curious to hear how people find the auto target selection/shooting done by survivors. I wanted to add more control, without entirely sacrificing the feel of the first game.

No related posts.

Truth is, I underestimated how long it would take to debug. I managed to get the demo feature-complete, but the polish just wasn’t there. I’m really disappointed I didn’t get it done, but I’m continuing to work hard to get it out as soon as possible.

On the upside, setting a deadline helped me focus on what was important and it’s looking good. It also made me chop and change parts of the design that weren’t working, and combat plays a lot better as a result.

The biggest change is the addition of awareness arcs. Originally, each weapon had a firing arc that would determine bullet spread. As time went on, this arc made less and less sense, and the only weapon it applied to in any significant capacity was the sub-machinegun. I wanted to keep the arcs, but disconnect them from weapons while buffing their usefulness.

The result is the awareness arc. Each survivor can be in a focused, normal or heightened state of awareness. These states determine the width of that survivor’s awareness arc. A focused arc grants increased accuracy, but reduced defenses against zombie attacks. A heightened arc reduces accuracy, but the survivor has a better chance of avoiding zombie attacks.

The other big change is that zombies not inside an awareness arc are hidden from view. Each combat you will have to sweep the room using your survivors’ awareness arcs and set where each one should look. This means the cop can be focused on killing zombies, while civilians can make sure he doesn’t get attacked from behind. It also reflects that a lone survivor is more likely to be attacked than a group. Survivors are always aware of zombies directly next to them.

Obviously, a focused arc doesn’t let you cover as much of a room as the heightened arc. Survivors will have access to different arc states depending on their experience level, with a character like the cop able to select from all three and newbies being stuck to one (the normal state).

Melee combat is implemented and working, but I’m not 100% happy with how it works. I’m likely going to cut it from the demo, but it will be the first thing I put back in for subsequent releases. Really, the combat demo will represent an alpha test of the game.

I hope you guys can tear it apart and make it even more awesome.

No related posts.

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.

No related posts.

Combat’s looking solid right now, as you can see from the above screenshot. Lots of shells, blood and graphical niceties exploding about the place. What’s not so solid is what happens outside of combat. You know, the walking around, searching for gear part of the game.

See, I don’t feel there’s enough going on when you’re not fighting zombies. Sure, you might say, that’s okay – it’s all about putting the undead back to bed – but I don’t think it is. I think there needs to be more going on when the hungry masses aren’t directly in your face.

I can recognise when I’m too close to a project, so I’m putting the call out for some ideas. At the very least, it’ll rejuice my drying creative cogs.

Best to start with a list of things you can do:
1) Move around inside buildings and out
2) Trade items, including ammo, weapons
3) Searching furniture for items
4) Breaking furniture for barricades
5) Barricading. Or yeah, barricading. I meant to show you guys this a lot sooner:

Neat, right?
6) Dispense medicine, break bottles, drink
7) Erm… that’s it, really.

What I believe needs to happen is for more “stuff” involving the survivors themselves. Tweaking personalities or statistics… some element of micromanagment. Something you do on a turn by turn basis to produce… stuff, be it a resources or survivor improvement.

See what I mean? I’m not really churning out the killer ideas here. That’s where you come in.

So, come in!

No related posts.

Whimsical metaphors aside, I decided to do something about my .NET focus and its destructive hold on my game development future. So, I present the above screenshot, a little piece I’m working on in Unity. It’s inspired by polyhedral dice and the excellent Dice Wars.

Unity is really, really good. Not only does it support three scripting languages (including C#, yah!), but you can switch between a “Game” and “Editor” view and examine the properties of objects at runtime. It provides an unprecedented level of debugging power, and problems that’d normally take hours to track down and fix can take minutes or seconds in Unity thanks to its potent visualisation abilities. It could do with a script debugger, but I hear that’s on the cards for Unity 3, due in… August. I think.

Unity also allows publishing to iPhone, PC, Mac, Wii and web. You need to make a few purchases to access the iPhone and Wii functionality, but there’s nothing stopping you from doing the gruntwork in the free version.

As for Zafehouse 2… I’m still keen to get a demo out by the end of July. I can’t say it’ll be fully functional, but it will give you a taste of what the game has become. I’ve reduced the scope and halved the length of the a Z2 day to 12 hours. I didn’t feel the intensity was there for 24, and the systems don’t allow for interesting gameplay for such a lengthy period of time.

Looking back at the code, there are a lot of things I’d have done differently. The one building/multiple floors idea was a good one and I’m not sure why I abandoned it. There’s also a heavy focus on combat, which is not what survival horror is about. The original intent was to make Z2 strategic, not tactical, yet that’s where it’s ended up.

I have some ideas for Z3 (yeah, yeah, finish the second one first, I hear you say) and I think Z2 has helped me focus in on what a strategic survival horror game should be.

No related posts.

But, I’ve been thinking over the last few days that the supply model could be folded into the item system. The result would be that supplies would no longer be counters with maximums, but discrete items, just like guns and furniture. In this way, a survivor could load themselves up with barricades, at the expensive of ammo, medicine and alcohol.

What makes me strongly in favour of this system is that it opens up more choices for a stronghold. If you think the hospital is your best chance at survival, you can now literally drop everything and cart barricades over from other buildings to fortify it, rather than a couple at a time.

The main interface would still keep track of how many of each supply type you have so the information is available at a glance, but the trade window would recognise them as singular items. The system would probably necessitate a weight system, and items like bullets and medicine would need a stacking mechanism… because I can’t see anyone staying sane with the prospect of moving 50 bullets from one inventory to another.

The risk is that trading and collecting supplies might end up with a Diablo-like inventory mini-game, but I believe this can be avoided.

No related posts.

As I mentioned in a previous update, the original combat implementation was ground into a fine, code-tasting dust and packed away, replaced by an infinitely deeper (and juicier) solution that uses firing arcs.

Entering into combat hasn’t changed – you still click on the event in the event window – and the representation of the room is similar too. The difference is that zombies are no longer shown as one large group, they’re now broken up into individual flesh-eating nasties. Weapons have also evolved, the far/close/melee profiles exchanged for variable firing arcs and shot modes. For example, the shotgun has a wide firing arc and shoots pellets in a spread, but it can only fire once per turn and has a short range. A submachine gun on the other hand has a medium firing arc and range, but you can shoot up to six bullets at one or multiple targets. Keep in mind that each bullet fired in the same turn reduces the accuracy of the shot that follows it.

Hit the jump for an additional screenshot which show projectiles in flight. Yes, I said projectiles.

No related posts.

I’m personally a little giddy about how it’ll all play out, and I reckon you’ll be pleasantly surprised yourself with the revamped combat. It has a flavour all its own, one I’m quite proud of. The instant it’s all working, expect a shiny video.

I will be working very, very hard to release the game this year, and extra super hard to squeeze it out a demo before the end of June.

Z2 has benefited enormously from the input of (what I hope are) fans, and it is a better game for those lovingly suggested modifications. In particular, kulik242 seems to have a direct connection to my brain; many of his suggestions adding the final pieces to my own, half-formed ideas. I think it’s wise to listen to those on the outside, the external observers, because distance is a magical thing in the creative realms.

In the meantime, if the survival horror simulation itch just won’t go away, check out Zafehouse: Infection, a user-made mod of the original Zafehouse. It’s got me thinking Z1 could do with a refresh sometime in the future…

Once Z2 is done, of course. :)

No related posts.

I know, sad faces incoming.

I’m going to take this opportunity to relax and recharge so I can come back and redouble my efforts on the game and the 4e Power Toolkit. Speaking of the 4ePT, I’ve started work on a localisation manager that should make it a cinch for people to translate the app into other languages. I’ve done about 40% of the groundwork, and hope to have a new version out in January.

As for Zafehouse 2, I’m in the process of adding perks and rewriting the combat engine. The first one was always going to be a prototype, and now that I have a better idea of the direction the game is heading, I can solidify this aspect of the design. The new combat engine and screen will be more interactive, dynamic and pretty, and will introduce a new concept – firing arcs.

But details can wait until 2010. ;) Until then, happy holidays and enjoy the break!

No related posts.

Twitter also happens to have uncommon letters in common with Twilight, which I hear is about emos vampires or something. And that’s good, right?

Zafehouse [Twitter]

No related posts.

All the thumbnails can be clicked for larger versions, if squinting isn’t your thing, and I can assure you they want to be clicked. By you. Right now.

Zafehouse 2 – Media [Zafehouse]

No related posts.

Everyone knows how a door works; it’s a big hole, usually with some sort of removable hunk of wood or metal, that allows or denies passage between two areas. This pretty much describes the doors in Zafehouse 2… with the exception that you can transform a door in Z2 into a nigh-impenetrable force.

If you watch the first gameplay video, you’ll see doors are barricaded by right-clicking on one and selecting a reinforcement level. I wasn’t entirely happy with the simplicity and non-interactivity of this model, and so it’s evolved significantly in the last month or so. The biggest change is that doors can undergo three types of modification – barricading, narrowing and blocking. These upgrades are applied on a door-by-door basis, so you’ll have fine-grained control of your defenses.

Barricading is the most important mod. Currently you can have up to six barricades in place, and each one increases the amount of punishment the door can take. As a door is attacked by zombies, there’s a chance a barricade will fail. This chance increases each time the door is attacked, and resets once a barricade falls. The higher the barricade level, the longer it takes for each barricade to fail. So, sure, you can have a single barricade on a door, but expect it to fail pretty quickly.

Barricades also reduce the chances of a zombie attack “slipping” through. With six in place, it’s unlikely the survivors defending that door will get hit by a stray undead fist. A single barricade however means there’s a good chance a survivor will get hit. Note a survivor cannot become infected by attacks through doors, unless all the barricades have failed.

Narrowing reduces the number of zombies that can attack a survivor through a door. A door that hasn’t been narrowed at all allows four zombies to have a go at the survivors defending it, while a fully narrowed door halves this number. Narrowing also slightly reduces the strength of zombie attacks against the door.

Finally, blocking a door stems the flow of zombies into a room once the barricades have failed. Normally, eight zombies can shamble into a room each turn, if no survivors are there to stop them. A door that’s been totally blocked reduces this amount to four. As with narrowing, blocking a door shaves a bit off the damage a zombie can do to the barricades each turn.

Modifications can’t be performed on a door that’s under attack, so don’t be scared to barricade the hell out of any door that could face an assault. And you’ll want to make sure you have enough barricades to go round – each modification has a different supply cost, with narrowing being the most expensive and standard barricading the cheapest.

Expect screenshots of this feature soon!

No related posts.