Stable Build: 41.78.16 | IWBUMS Beta: 41.78.16 | Version history | Wiki
Follow us


News & Dev
February 16, 2023

Play Your Cardz Right

Hey all, let’s chime in with some of the feverish work being done in the musty basements and damp holes in the ground of the Knox Event. First off, some scribbles from the engine room


To catch up and recap, the main highlights of engine improvements for build 42 are as follows:

  • Basements and underground things!
  • A flexible per chunk 32 height that can be different in each chunk, allowing parts of the map to be at 32 level height, where others in theory go from -31 to ground floor.
  • New lighting propagation system that has light bounce off walls and leak through windows, doors and other spaces more realistically – allowing for more natural ambient light effects and getting rid of those room based lighting issues.
  • The ability to have negative coordinates on x and y, thus opening up map expansion directions in the three previously missing directions.
  • New chunk based rendering using a depth map to vastly optimise drawing of the game.

It’s this last item that we’re going to discuss today.

How 2D games have historically worked is like a deck of cards being dealt: each image is placed on top of the other to construct the scene. 

This is terribly inefficient, especially in terms of an isometric game like us with a crap-ton of tiles, tile overlays and so on. The rigid order that the sprites are dealt (so closer ones obscure further away ones,  leaving the closest one on top) means that your GPU is unable to optimize how it’s all drawn.

Not only this, but every time you deal a card on top of another card (a zombie in front of a wall for example) then that wall is forever ruined by the zombie’s pixels: the only option is to draw the entire thing again, tile by tile, for the next frame.

Can I shock you? In the past, people have complained about PZ’s fps.

A common thing we hear is: ‘“Well, my PC runs Skyrim/Witcher 3 just fine” but sadly this generally overlooks the fact that GPUs are built and optimized for 3d rendering. A game with this much detail that doesn’t utilize 3D rendering has actually got a tougher time ahead of it than Skyrim or Witcher in terms of making your GPU happy.

We also, on top of this, have extremely expensive scene construction CPU time too. End result: a really big bag of nightmares.

Now, in a 3D game you have a depth buffer. This is an offscreen rendering of the scene that tells it all how far from 0->1 each pixel is:

This is really handy, since the deck of cards goes out of the window. You’re no longer having to draw everything from the furthermost thing to the closest.

With a depth buffer you can choose whatever order you want: draw all brick walls first, then all characters hairs, then all grass, then all… you get the idea.

Outside transparency, which causes issues, you can draw anything in whatever order is most convenient and most optimized for the GPU. Not only this, but you don’t have to put together the 3D scene polygon by polygon every frame: you have a cached mesh probably already on your GPU memory sat waiting for the next frame, and even if the character turns or moves that mesh is still valid to use.

Zomboid? Not so much. We have to draw every individual godforsaken goddamned tile: every bit of lighting, every bit of grass, completely from scratch, every frame, every time. And when you zoom out? Wuh-woh shaggy. You’re now asking for trouble.

So for B42 we decided to implement a depth buffer! 

This was a bold proposition since we have no 3D (outside the characters and items, of course). Our ‘3D’ is otherwise a faked perspective drawn by the artists drawing the tile: it’s an illusion.

However, with some perseverance, we managed to generate a serviceable depth map of our usual faked isometric tiles:

Note here that when you look carefully at the floors and walls in this, they are not completely smooth. Each tile is still just ‘a certain distance away’ and it all behaves just as it does now: a deck of cards being dealt every frame, where one thing is either below or on top of another. However we no longer have to draw them back to front.

We’ve all seen this faked isometric drawn into the tiles cause weird visual glitches too many times to count, where the illusion of the 2d tiled world just breaks in ugly ways.

So we went a step further and calculated the fake 3dness for floors and walls, thereby making the depth map peachy smooth:

So where does that leave us?

We’re dealing the self-same deck of cards we always have been (these are still faked 2d isometric tiles and always will be) however we can now say ‘the left hand bit of this card is actually further back than the right hand side of this card’ and objects placed on them will represent this as if they had actual 3d depth. 

For walls and floors, at least, from this fixed perspective we suddenly service them with the GPU as if they are 3D objects: which means that not only do we get rid of the issues with the fixed tile ordering, but we can say ‘this specific part of this tile is further back or further forward than the rest of it’. So we can choose to put that part of the tile in front of / behind the character differently to other parts of the same tile. 

This will make a big difference to immersion on its own, but then we went a step further. With the new depth map, we opened up access to that amazing optimization trick we mentioned before.

On the dev branch for this work, we can now just draw a chunk like this tile by tile on one single occasion.

All those hundreds of draw calls as the cards get slammed down from the deck now only need to happen once as we ‘construct’ the chunk and it becomes its very own ‘tile’.

Within this we bake the depth information into the depth buffer. So, despite this just being a single picture, we already have all the information hidden behind it that’s required to correctly place any player, zombie or placed inventory item anywhere on this chunk (even inside the building, or partially obscured by any part of it) – and this can be done AFTER drawing the chunk itself too. We can effectively slide things behind stuff we’ve already drawn intelligently.

The only times we will ever need to update this chunk and redraw those tiles is if the lighting from time of day changes, or if a naughty zombie dies on it or a player picks up an item, drops one, opens a door or otherwise.

(And oh yes, zombie bodies and dropped inventory items will be cached on the chunk too! With depth! So in terms of performance this current resource-hog will be near enough completely free)

So now for every frame the chunk above, the charming apartment balconies, becomes the equivalent of a single current tile. One single draw that’s not that much slower than drawing that one single tile in the current build, in which we have 8x8x4 gridsquares getting drawn, potentially with 4-5 tiles on each. All for near the price on CPU and GPU of a single tile draw. 

The work needed to draw each tile on that chunk only needs to occur every so often when it’s updated in a way that invalidates the depth or changes the tiles visually, or when it first becomes visible. And if anything invalidates that chunk that it requires drawing in full, it’s only that chunk that needs redrawing, and only once. It’ll hardly be noticed by your CPU and GPU.

On top of this we have that depth buffer still for every tile drawn, and beyond that the walls and floor tiles have additional faked smooth depth applied to them.

That’s where the magic happens: weirdly not only is the above long-haired hippy character drawn AFTER the fence tiles are, but the fence and the gravel floor that’s visible behind it are just part of the same single image and are not separated whatsoever. Due to the magic of the new system we happened to have the extra depth information and were able to throw away pixels of them being drawn seeing as there was something ‘closer’. 

As a cumulative effect of all the above: this is how we accomplished 4k res, max zoom, 300-500 fps, with over 1000 when zoomed in in this video we posted a long while back when we were prototyping all this.

(Though please note we expect, in practice, it won’t be this high: the lack of zombies and various other factors make it not completely representative of the full game – but it’s still a good indicator of how vast this optimization will be.)

Next Steps

So the big issue here is that walls and floors are the easy part.

It’s relatively simpler to calculate how ‘deep’ a particular pixel of a wall should be, use a shader to put that depth in, and get smooth continuous depth that the player won’t clip through like it’s a 2D billboard facing the screen. Anything more complex than a flat wall or floor though is a problem.

EP, however, has recently been experimenting with some stuff that’s pretty cool.

We must make a big disclaimer there that this is very much, as stated, experimenting, and we can’t say for certain what is shown here will be in b42 as shown.

He made us promise we made that clear before we speak of it at all, but it’ll give you an idea of what we’re trying to do and the cool ideas he’s been playing with on his travels.

So he’s been working on a cool editor for creating simple 3d shapes, positioning them on the tiles, and baking out the depth texture for use when rendering.

None of the 3d shapes will end up in the game world while playing, but the resultant extra depth texture (seen in the bottom left) can be used with the depth map system to make the characters interact with it as if those 3d shapes were there.

As you can see, here the character intersects with the (remember, completely 2D) tile as if it were a 3d object itself, with full gradual depth.

And yes, this is the main thing that’s been holding us back from sitting in chairs, lying in beds etc. Modders have done great things providing this in the capacity that’s feasible in the current engine, but are still limited from sitting properly in chairs that obscure the character or face in different directions. We want a proper solution that’ll work 100% when it comes to the main game.

Finally, another caveat.

There’s no way in hell we’d ever be able to do this for every tile in the game, especially the more complicated ones or ones that were drawn (by hand) by the artists that may not actually follow strict laws of isometric in actuality.

While this tech can be used for some nice stuff in future its primary and only feasible short to medium term use is as described above.

Before we start seeing the inevitable “omg PZ will be able to rotate camera RTX mode when??” this is still a complete MASSIVE gulf from anything resembling true 3D.

Trust us: we’ve already ummed and ahhed and experimented with all this tech for a long while now to firmly to know where our limits are and put our boot down on those kinda thoughts.

But this does mean that we should be able to deal with all the main simpler structural tiles that make up the main geometry of the maps, and will provide a much more solid feeling world despite it looking very much the same as it always has – however, with the new lighting propagation system it shall look that bit better of course!

We now return to your scheduled programming.


Next, over to the redoubtable Blair Algol for the latest on agricultural matters.

“The current state of the farming rework is that the current dev phase of new plants, vegetables, herbs, houseplants and associated changes to farming mechanics, are nearly finished. I’m now on fine tuning and polish.”

“The sticky matter in the fine tuning and polish, however, is that my mission has not only been in a more realistic and better balanced farming experience – but also to provide a more folksy, relaxing and productive-feeling gameplay loop that fully utilizes the new animation capabilities of modern Zomboid. So this is actually the part where I need to roll up my sleeves and do the heavy lifting.”

“I had been waiting for Aiteron’s splendid fishing rework to get into a state where it was possible to build off it, so that both the interface, and interactions would be as consistent as possible; as well as with the RJ’s animal rework, and Eris’ foraging interface. We’re really trying to make the systems and experiences in PZ more consistent as a whole.”

“But the goal is that farming should serve as a fun, peaceful minigame, albeit with challenges as we are making a survival game, but that can be an oasis of calm in the chaos and death of the PZ apocalypse. One fun little feature that I’m adding in that regard is using Ladybugs (EUROPEAN TRANSLATION: ‘Mister Ladybirds’) as pest control.”

“I should point out that, in testing, even with the longer growing seasons, and new pests/maintenance, the majority of plants would still survive until harvest without any major issues. Yields, however, might vary.”

To summarize the changes to farming, we have already implemented the following:

  • Crops now take a realistic amount of time to grow before they can be harvested; this can be adjusted to suit the player or server in the sandbox options.
  • Crops also feature realistic growing seasons, where there’s optimal months to plant your crops, as well as ones where they are doomed to failure; this can be disabled in the sandbox options.
  • Attempting to grow anything other than houseplants indoors will also be doomed to failure; this also can be disabled in the sandbox options, and, when the new lighting systems are implemented, then a realistic greenhouse system could be explored, but don’t take that as a guarantee.
  • Slugs and snails are new garden pests, that can be dealt with using commercial slug and snail killer, or by learning how to make a slug trap out of an empty beer or pop can and some beer. Rosemary plants, and chickens, also serve as means to control slug infestations.
  • Plants will also benefit from regular weedings.
  • We have herbs, which have shorter growing seasons, and can be repeatedly harvested, and you can also propagate new herb patches with fresh herbs.
  • You can use potatoes, onions and garlic as seeds to plant new patches of vegetables.
  • I have added contextual actions using the combat stance in combination with the action key. When you have a hoe equipped, and are in the stance, you can use the action key to dig a furrow. Likewise, if you have seeds in your hand, are in the stance, and are facing a furrow you can use the action key to plant seeds. Likewise for watering plots. I plan on expanding this contextual action to include stuff like chopping down trees when an axe is equipped; removing barricade planks when a crowbar is equipped; etc. as well, for consistency.

There’s other cool, fun stuff that’s either being worked on, or being planned, but we don’t want to spoil everything.


A visual update from the Aiteron keep net!


Back to the Blair hothouse!

“One of the other things I’ve been doing for Build 42 is adding a slew of new items – both functional and decorative – along with addressing inconsistencies and missing functionality with existing items.”

“One of the issues we’re attempting to address is ‘Bottleneck Items’. These are items such as Generator Magazines, Sledgehammers, Lighters/Matches etc. that, when a player has difficulty finding them, can make them feel like they’re soft-locked out of parts of the game. While we don’t want to remove the challenge of finding these items, we want to ensure that there are adequate opportunities for a player to find these items, even if they may involve some dangerous excursions.”

“In addition to ensuring that these items spawn in varied appropriate circumstances as loot, including in vehicles, we are ensuring that special circumstances such as the randomized stories and annotated map stash houses can spawn these items, and appropriate items will also be able to be foraged. As an aside, the loot tables themselves are in the process of being scrupulously revised and glowed-up, and should provide more fun and depth for the looting aspects of the game.”

“We made a couple of tools to collect data and feedback regarding this. I had already made LootLog, a tool similar to Aiteron’s LootZed, except that this one, when activated, logs all loot that spawns to the console.txt with details including the exact location where the loot spawns.”

“Fenris then took this concept to the next level, and now we are working with a tool that tracks and logs exactly how many items of each type spawn for each savegame; a permanent record showing exactly how many items spawn. Not only does this allow us to collect concrete data regarding item spawning, if you are worried that Sledgehammers, Generator Magazines, or Rubber Hoses aren’t spawning, you can check this record and see if they are.”

“In regards to Generator Magazines, with a high enough Electrical skill in Build 42, your character will be able connect and repair Generators without needing that magazine. We are also adding additional varieties of lighter and matches, as well as Lighter Fluid for refilling the classic lighters, and you will be able to use a vehicle lighter, open flame, or an appropriate stove to light cigarettes. There are also alternate means for players with the Smoker trait to feed their addiction to nicotine.”

“You can currently use many bottles other than the Gas Cans to hold fuel, which was one way we addressed that particular bottleneck (and yes, we are making sure that hoses for siphoning fuel are common), and we are also adding a new, larger, fuel container, alongside some other military-themed items.”

“We know that many players, especially roleplayers, like having themed items, and so some more themed bags, like the military duffelbag in build 41, are on the way. The new entrenching tool serves as a weapon and a shovel, and is folded when placed on the ground or attached to a belt. Several of the new knives such as the Switchblade and Butterfly Knife also have that feature.”

“The new canteen item can be attached to the belt, and will also showcase another new item feature that modders can make good use of: items with varying icons and models from their standard base ones. This allows us to add cosmetic variants without having to actually add new items, similar to how clothing works. I believe there are 4-6 variants of this style of canteen. All of this military loot spawns in appropriate circumstances, so if you want this new gear be prepared to have to go out and get it.”

“Another alternative Bottleneck Item is a P38 Can-Opener that you can keep on your Key Ring. Additionally, your character will be able to use a knife to open cans of food, although that will damage the knife and has the risk of injuring your hand. We also have fancy, expensive imported beer that requires a bottle opener, and the better wines, aside from Champagne of course, will need a corkscrew, or one of the better pocket knives to open.” 

“There are many other new items and features: you can use a Pickaxe to remove annoying stumps and boulders; we added various vanity/prestige items and collectibles; players worried about having enough Garbage Bags for water collectors (another Bottleneck Item) will be happy to be able to find a box of them; and we made garbage loot a lot more fun and gross.”


Next a quick update for modders.

Something else we’re endeavouring to do for Build 42 is to use Tags for item interactions whenever possible. This should make it easy for modders to add new items that work smoothly with a lot of the fun new stuff, and older stuff as well.

As mentioned above, for both mods and our own usage, we now have it so that modified item icons and models are “persistent”; when changed they stay that way when after quitting and reloading and we have made sure to have straightforward function names for ease of use.

We added some new events for mods to use, including: – OnZombieCreate and – LoadChunk

OnZombieCreate will allow modders to directly access zombies when they first spawn. Currently for many mods, using the LoadGridSquare event is the only feasible way to accomplish some goals. However, this often has an annoying impact on performance. What LoadChunk does is allow mods to access the chunks of the world map, which are a 10 x 10 grid of map squares (though as discussed above will be 8 x 8 when b42 launches), after they stream in. Afterwards, if the mod needs to access a square in that chunk, it can use code such as chunk:getGridSquare(x,y,z) to access said square. Practically speaking this means that the mod can use ~1% of the previous event calls to accomplish the same goals, for many of the purposes in which LoadGridSquare is utilized.

We have also moved around the order of operations when sandbox options are loaded and the loot tables are parsed, to make it easier for mods that use sandbox options to set loot spawn values.


Finally, a quick video built from clips from the ongoing animals testing.

Tara for now, chucks.

This week’s hellscape from Stonmo. A changelist of all our pre-release and post-release patches since the 41 beta began can be found here. The Centralized Block of Italicised Text would like to direct your attention to the PZ Wiki should you feel like editing or amending something, and the PZ Mailing List that can send you update notifications once builds get released. We also live on Twitter right here! Our Discord is open for chat and hijinks too. Experienced gameplay coder and want to join Team Awesome? Jobs page here. Apologies for the lack of blog last week, the blog writer had a fever and for much of Thursday was hallucinating that he was stuck in a Mexican hotel and GOG kept on phoning the switchboard to demand that we change the Knox Event lore.


My Zeds is on Fire

News & Dev | 26 January 2023



News & Dev | 02 March 2023
Stable Build: 41.78.16 | IWBUMS Beta: 41.78.16 | Version history | Wiki
Follow us