Featured Post

Some Twaddle about VR

I don’t want to get all pretentious and cite the vast array of literature I read so that I come across as some kind of intellectual, because to be honest I don’t read that sort of stuff and I’m not clever enough to fake it. Most of what I read is non-fiction sciencey stuff and the...

Read More

Even more (!) musing on Alpha-Funding

Posted by CaptainBinky | Posted in Games, Project Zomboid, Useless Advice | Posted on 21-03-2016


* Narrow-slice view of the industry incoming. I do not claim to speak for all (or most/many/any other/whatever) indie developers.

Before Minecraft invented/popularised alpha-funding as a viable way to make videogames, here is how you’d make an ambitious large-in-scope indie game:

  1. Make a small indie game in your spare time
  2. Repeat 1 until the pittance you earn from all these small indie games affords you some capital to invest in a larger project
  3. Make a slightly bigger indie game, pay someone to make the graphics swanky, spend some money on marketting
  4. Repeat 3 until you’ve got a pretty hefty chunk of profit or return to 1 if it was a commercial failure
  5. Gamble horribly, quit your job, pump all that money and a truck-load of time into your magnum opus, hope that Valve let you have it on Steam
  6. Profit, hopefully

You’d have to be pretty bonkers, really, to even go down the road of step 5. You’d be much better off just pumping out a tonne of smaller games and having the cumulative sales they generate sustain you and hopefully give you a reasonable standard of living.

But Alpha-Funding / Kickstarter (and then Early Access) changed that. It meant that step 1 could be the large-in-scope magnum opus. If you can get people interested in your project in its infancy, you can be sustained all through the game’s development. That almighty step 5 risk is hugely reduced (at the cost of putting a comparatively tiny amount of risk on a lot of individuals who support your game). It is simultaneously the most liberating and the most dangerous method of making videogames. It comes with costs far beyond the paltry sum that you are usually asked for to buy the thing early in development – costs which affect customers and developers alike.

Costs exclusively concerning customers

  1. The ambitious-sounding project may just end up being too ambitious. Game never gets finished, your £1 / £5 / £10 is effectively wasted
  2. The project may have been perfectly realistic in scope, but due to simply never managing to attract sufficient interest it is never finished, your £1 / £5 / £10 is effectively wasted
  3. The game may not end up being what you expected it to be, you consider your £1 / £5 / £10 to be wasted
  4. It places an impossible burden of responsibility onto the customer. While publishers have the experience to recognise a game design horribly out of touch with what is practical, or a tech-demo with terrible foundations, your average customer does not – yet they’re the ones who, when upset when things do not turn out as they expected, are shrugged off with the, “well you should have done better research” argument
  5. If you were expecting the game to get better in good faith, and it didn’t, you’ve probably already blown your chance of getting a refund (this applies less if you bought it on GOG, of course)

Costs which affect both customers and developers

  1. The game will eventually cease to have support / updates. There will be a large number of people who will be unhappy – regardless of how complete the developer considers the game to be at that point
  2. To excite people into giving you money at the point you’ve barely started is… difficult. Your project needs to stand out. There is huge danger here in inflating your game’s scope beyond ‘ambitious but do-able’ to ‘ambitious to the point of insanity’ in order to be noticed
  3. You need not demonstrate any ability to finish a game in order to attract the money to start one – unlike every single other way of getting funding. While there is no ethical problem with simply releasing a crap game, having it review terribly, and having those that buy it refund it within an hour – those ethics become questionable when you’re taking money for a project you cannot know that you can complete. A horribly misguided sense of ability can be endearing if you merely output awful games no-one buys, but there’s nothing endearing about misleading people into buying in to those delusions, intentionally or otherwise
  4. The skills required to pitch a concept fall far below the skills required to successfully create that concept. This development method enables those who both lack the skills to complete what they’ve pitched and also those skills required to recognise that they can’t complete what they’ve pitched. From a consumer perspective, these pitches are often indistinguishable from realistic pitches.

Costs exclusively concerning developers

  1. You’re potentially throwing away the chance to build-up your skills and experience slowly if your project ends as a high-profile disaster




I’m not suggesting, then, that no-one should make an alpha-funded game, or that our own game is some sort of shining beacon of this method. Alpha-funding, to us, was a necessity – and we considered our chances of finishing what we started to be pretty damn certain. But, of course, everyone who isn’t actually trying to pull-off deception would say that, but it doesn’t mean that we or they would ultimately be correct. I do think that, in general, those indie developers who create many smaller projects are the smart ones – all our eggs are currently in one basket and, while we’ve been successful with Zomboid in terms of sales, we were pretty lucky that the DayZ mod appeared shortly after we released our first build and ignited interest in the survival genre. Thanks Dean!

I also think critics can serve tremendous good in this context. We can’t expect an average gamer to be necessarily able to recognise the difference between those concepts likely to succeed and those likely to fail. Critics, however, are more familiar with games development and can distinguish between the two and spot-light the former. Kickstarter pitches often overlook including a “risks and challenges” section and sometimes when it is included exists in a sort of, “my greatest weakness is sometimes I care too much” way. I’d like to see more prominence of those articles which really look into early game builds / pitches in-depth.

Mesh Enshrinkulation

Posted by CaptainBinky | Posted in Project Zomboid | Posted on 26-11-2012


We’ve had a few people contact us for specifics on the process we’re using to translate the 3D source models for Zomboid into 2D sprites. So I thought it’d be a good thing to go into here.


The Goal

The result we’re striving for is all the advantages of being 3D (ease of creating animations in all directions, simplicity in terms of adding new costumes, hair, accessories, props, etc) without the look straying too far from our original hand-drawn sprite look.


The Process

The models are built and animated in 3D, and were we just to render the frames directly, they’d look something like this:

…which is not particularly great. Even shrunk down to the size it would appear in-game, it would obviously be a 3D model and stick out like a sore-thumb. So what we have, then, is a  two-stage process.

Firstly, we render the model to a render target that’s twice the size that it would need to be in-game. We apply a shader which applies some basic lighting (using hard edge, cartoon-style lighting) and uses Point sampling to preserve the crispness of the source texture.

We then render the contents of our double-sized render target to a game-resolution quad and apply a second shader process. During this stage, we allow anti-aliasing (we’re basically doing super-sampling here, since our source is twice the resolution of the destination) and then in the shader we clean up the image data.

The cleanup involves several layers of quantizing.

First, we ‘snap’ the colour value to the closest available colour in the source palette (the palette is passed in as a parameter to the shader, and is calculated once per model processed).

Next, we quantize the intensity (the length of the colour vector) to one of 5 possible values (0.0, 0.25, 0.5, 0.75, 1.0)

Then we quantize the pixel alpha to one of 3 possible values (0.0, 0.5, 1.0)

Finally, the colour is re-constituted from those parts, and spat out of the shader.

It’s a little difficult to show a fair comparison between the first version of this system and the current system, because a few things have changed with the source (an obvious example being that hair is now a separate overlay rather than being drawn onto the texture), but this should give a reasonable idea:

While there’s definitely a ‘personal preference’ aspect to which you prefer (and the new system is still work-in-progress at this stage), the new sprites are considerably cleaner, and much more closely match the original sprites.

There’s still work to be done in terms of finding that ideal sweet-spot for the lighting which will help add definition needed particularly on the side-on frame.

But one of the tremendous advantages of the new system is the speed that we’re able to convert the 3D data to sprites. Almost all the work of the process is now done on the graphics card, which means you can spit out all the frames for all the animations in all directions for one model in a matter of seconds. Beforehand, the process would be something we would leave running overnight.

What’s Next? Tools & Art in Project Zomboid

Posted by CaptainBinky | Posted in Project Zomboid | Posted on 13-02-2012


Now that the first version of Costume-Ed has been released, it’s full-steam ahead on female sprites for Project Zomboid. There’s still a little bit of work to do getting all the base sprites cut out and imported into the tool, but once this is done I’ll be migrating my workflow from D-Paint Animation to Costume-Ed.

This will hopefully result in a speed increase in costume production as well as ensuring I’m on the case as far as bug-fixing the tool, and adding improvements here and there.

Features which I would like in Costume-Ed include:

o Various brush sizes
o Line tool
o Dither brushes
o Separation of hair onto a new layer (instead of being part of the head)

There’s no fixed timescale on when those features will be added because, in the grand scheme of things, they’re not terribly high priority.

Sorry that something as fundamental as “female characters” has taken so long to add to the game – hopefully anyone who’s had a squizz at Costume-Ed can appreciate the amount of work involved in adding just a single new costume, let alone doing all the base frames. Almost there now, though 🙂

Tools and That and Things

Posted by CaptainBinky | Posted in Project Zomboid | Posted on 24-12-2011


Hello. Merry Christmas for tomorrow, and all that.

If you’ve not been following the, frankly, obscene amount of Tweeting I’ve been doing over the last few weeks (who could blame you – I’d have unfollowed me by now if it were possible), you may have missed a couple of screens I posted. These will mostly be interesting (or at the very least, relevant) for those of you into the whole modding thingy – and in particular, visual modding.

Firstly, there’s Costume-Ed – which is a tool we announced a while back, but which was one of the casualties of The Event. It’s now been almost (because it’s not quite done yet) entirely re-written, and is much better than it was before.

And next, because half the code for it could be ripped straight out of Costume-Ed and plonked straight into this, is a little tool for making isometric floor tiles called Iso-Edit. Draw (or import) them in conventional face-on 2D, and have them squidged automagically into annoying isometric 2D in real-time as you draw.

You can paint in both windows so any little errors that happen as things get squidged can be tweaked. So, for example, squidging the word “hello” resulted in some wiggly rogue pixels, so I cleaned them up and those rogue pixels can now be seen in the original window which we don’t care about because that won’t be going into the game.

So there we go. That’s the tools stuff which will be coming to a PC near you shortly after the update is released.

(And yes, it’s all backed up. Off-site.)

Cosmetic Character Customisation

Posted by CaptainBinky | Posted in Pictures of things, Project Zomboid | Posted on 17-07-2011


Currently in production (as seen in my last blog post) is an “underpants man” version of the character sprites. What does this mean, besides confirmation that the survivors in the apocalypse do indeed still wear underpants..? Well, the screen posted before was the first pass of the anims, the second pass takes it one level further:

Oh dear, no head. The final pass will involve slicing his legs off too. This means that the final “characters” in the game will be assembled from a head, a torso, and legs and clothing will be sliced up similarly. Shirts, trousers, heads, hair, etc. will all be overlaid on these base elements meaning that not only will NPC costumes/look be randomised from these components, but that the player himself will be able to wear any clothing which he finds. And not only that, but he’d be able to have his head lopped off.

These components will also represent “final” character sprite layouts, so any custom mods produced after these have gone into the build which conform to this layout will be “future-proofed” for any further updates. And combined with the modding support currently being added, instead of replacing Baldspot’s permanent look, new costumes can instead be loaded in addition to whatever we put into the game.

Once these are complete, a similar pass will be worked on for the zombies so that any survivor who turns will be a zombiefied version of their human look instead of swapping to a preset “zombie sprite”, and then after that, a set of female equivalents will be produced so that you can choose your gender and meet female survivors in the world.

Work in Progress

Posted by CaptainBinky | Posted in Pictures of things, Project Zomboid | Posted on 25-06-2011


I tweeted this pic for #ScreenshotSaturday so I figured I may as well post it here as well.

What are the implications of this? Well, I alluded to what this is for in the discussion I had on Bulletproof Radio last Tuesday (hint: the question the Geordie chap phones in to ask).

And on the subject of “that Geordie chap”, you should definitely check out Ringod123’s awesome play-throughs of PZ on Youtube!

Also, if you like Welsh accents (hint: yes you do), you should also check out this one!

Have a Project Zomboid Login? Then play!

Posted by CaptainBinky | Posted in Project Zomboid | Posted on 28-05-2011


Oh. My. Word.

This is a bit scary. It’s been a bit of a weird few months – we’ve gone from living off bread and beans, to announcing a game that got spread so far the traffic broke our servers. We’ve had wibbles with payment systems, HAD A CAR EXPLODE near us causing total evacuation, and finally this… the release of our pre-alpha tech-demo.

So yeah, it’s an early build. There are bugs to fix before we go completely public, of course, but its onwards and upwards from here 🙂


Countdown until Project Zomboid Demo Launch!

Posted by CaptainBinky | Posted in Project Zomboid | Posted on 11-05-2011


Over in our forums, we’ve added a countdown of remaining tasks that need completing before we make the demo live.

Note: The above is a picture and not the live countdown 😉

So head on over to our forum to keep up-to-date: Link.

So yes, okay? You can run in Project Zomboid.

Posted by CaptainBinky | Posted in Project Zomboid | Posted on 01-05-2011


Player RunningA while back when we released the videos of Project Zomboid in action, we didn’t have any player running frames. Instead, the walking animation was sped up depending on how fast you were moving.

This, as I’m sure you can imagine, looks very silly when you’re moving relatively quickly. So instead of ruining the video by having “Benny Hill”-style comedy walking, we elected instead to only walk while we were capturing the footage.

This resulted in far too many reactions like, “I think it’s a little rubbish that you can’t run. Why can’t you run? Seems like poor design to me”, etc.

The same logic applies to everything else a human ought to be able to do, and the same answer applies to nearly all of them:

“How come you can’t climb out of windows?”
Answer: Because the art hasn’t been done yet.

“How come you can’t climb over obstacles?”
Answer: Because the art hasn’t been done yet.

“Why are the zombies bald?”
Answer: Because the art hasn’t been done yet.

Actually, this last one requires a slightly longer answer. Characters in the game will ultimately be assembled out of component parts – head, headwear, shirt, trousers, etc. So you’ll be able to customise your character to your heart’s content. The same goes for the NPCs which will use the same system. And since any NPC or, indeed, you the player can become a zombie, the zombies need to reflect the look of the character from which they turned.

So the zombies will have a head that matches the character. Because there are no other heads in the game yet, rather than having all the zombies use a head that looks like the player, I instead made them completely generic and bald – a template, essentially, to work on top of – adding hair, gruesome zombie effects, and whatnot as relevant. But since you can only work on one thing at a time, all this stuff has been left for post demo.

There we go then – now that I’ve finished the sprite frames, in the demo release you will be able to run. The zombies can’t though. 😉

Project Zomboid gets new interface!

Posted by CaptainBinky | Posted in Project Zomboid | Posted on 14-04-2011


These last couple of days we’ve been doing a fair bit of work replacing the placeholder UI we’ve had since the start (that we all hated), with something swankier and easier to use.

It’s work-in-progress, so there’s a few things not in the correct place or unlabelled – there’s no scroll buttons for the inventory or any indication of capacity for a start, but we thought you’d all like to see it anyway.

So here it is:

We’ve dropped the concept of literal left and right hands in favour of the more general main and secondary hand slots because otherwise things get a little confusing depending on whether you’re left or right handed.

The inventory panel swishes in from the left-hand side which means that there’s much less screen-space obstructed when running in lower resolutions. We’ve also tidied up the mechanic of actually transferring items between containers and your inventory so that there’s less clicking and dragging required.

You can also see the crafting panel here (currently without a title in its title bar). This is only on-screen during the actual crafting process, but we kept it as small as we could without it becoming cumbersome.

In a game where you need to scavenge for supplies pretty often, having a nice tactile and easy to use interface is of primary importance, so it was definitely something to improve before we go live with the demo taster version.

Please continue to discuss this (or anything else) in our forums, just as long as you don’t hate the new interface 😉