He’s published his work on the Zafehouse forums so if you feel like playing the game in Russian, or translating it into a language more compatible with your brain, please check it out!

Link: Zafehouse (multilingual) [Zafehouse forums]

No related posts.

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.

This series of interactive YouTube videos straight from New Zealand puts you in the shoes of a pizza delivery dude stuck in a zombie-infested city. I’ve seen it described as “Zombieland meets Beached As” and, having watched a few clips, it’s a darn accurate assessment.

Could my homeland be any more awesome? Probably, but not by much.

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.

A shakycam trailer of The Walking Dead from Comic-Con 2010. Colour me excited, or whatever palette you feel strongly signifies happy.

Is This Zombie TV Show Tipping Its Hat To Dead Rising? [Kotaku AU]

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.

Zombie marches are held everywhere, but Melbourne’s own undead shuffle is taking place this weekend on May 1. The horde will start at the Carlton Gardens north of the city at 1PM, and shamble its way to the metro core, bringing all the fake corpulent skin you could ever want with it. Even if the only shooting will be done with cameras, I’m sure it’ll be fun for everyone who doesn’t instantly drop a potato in their underdaks. If the photos from previous years are anything to go by, it should be a blast.

And, despite being an amateur affair, some of the makeup and effects are quite good… more than good enough to find their way into a certain zombie survival simulator…

Melbourne Zombie Shuffle 2010 [that's melbourne]

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.

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.