Gawbad

Hello everyone, we’ve had a rather wonderful weekend of Steam saleage, and are feeling in very high spirits. We’ve also concocted a plan for our advance to the ever elusive 1.0 and graduation from Early Access, as well as beyond, which we would like to share with you all!
Fear Not, For It Is Not The End
Firstly we need to stress that any talk of 1.0 is not talk of us hanging up our Zomboid boots. This needs to be stressed with underlines and bold, so I will go back and do that right now.
Now there is part of us that always gets a bit confused when some people complain about ‘how long the game is in alpha’ as if perpetual updates were a bad thing, however it does feel at this point that PZ being an alpha in-development game is becoming increasingly a burden on the game in terms of popular opinion, and we’re eager to free it from those shackles.
It’s also about drawing a line under our promises when we started PZ. Right now there are several things outstanding that underline Project Zomboid’s incomplete state:
1) NPCS
2) Vehicles
3) Map Completion
These are the things that we promised going into the game that have not yet been fulfilled. There is also one gaping hole in the survivalist gameplay which needs to be addressed:
4) Hunting
NPCs
Yeah, they are coming. Lemmy has made some awesome progress this weekend in particular, and while they aren’t imminent we feel very confident in their recent progress and Lemmy has ceased waking up in cold sweats about them. Due to the evolution of the game the old in-development NPC system needed a lot of ripping apart and transplanting / revising since the last batch of videos, and its been a very stressful and arduous task.
However things are running at full steam again, and we are currently planning a way to deal with releasing NPCs in stages, starting with Kate and Baldspot, then a release of sandbox NPCs with a smattering of meta-game / group mechanics, followed by a fully functional release, and finally multiplayer support. Holding back it all until completion is starting to feel like a bottleneck and while we may get a few who don’t read the Mondoids throwing their shoulders up and ‘is this it?’ at the early release stages, if it gets NPCs out there sooner and eases development it’ll be worth it.
There is a massive body of code and behaviour scripts and in entirety the is still a bunch to be done before it all works in harmony, truth be told months and months still likely remain before the entire system is ready for release. But it is relatively trivial for us to pluck the still flaky chunks out to stablise it for a Kate/Baldspot release, and a phased release of NPCs where the behaviours and meta-events can then slot in in subsequent updates.
That said we’ve still got some work to bring Kate and Bob up to speed and finish off a few things, so don’t take that as ‘KATE AND BOB TOMORROWS’!
VEHICLES
These are on their way too. EasyPickins has taken up the work while Lemmy cracks on with NPCs. They will use bullet physics which means a few challenges for the map streaming, in constructing a physics world along with the PZ game world, and there may be some multiplayer challenges to meet, but it’s on its way! More details when we have them.
Oh and what’s this?

 
HUNTING
Since he’s done such an awesome job with trapping, fishing and the like, Romain will head up the hunting development. Finally you’ll be able to wander around the countryside trying to shoot rabbits with a shotgun. Hurrah! This will round off the survivalist gameplay and make the game feel much more complete as a survival sim.
MAP
Right now there are a bunch of areas of the map that are highly undeveloped. Big rectangular chunks of forest, road layouts with no buildings, and of course no lovely Louisville. In line with our plans to stride toward the 1.0 line, Mash, Binky and RingoD will all join forces to really put the map expansion into overdrive.  Louisville, or at least the part on the Kentucky side of the river, Brandenburg, and of course Fort Knox will all be on the agenda, though the latter may need to wait for NPCs to drop so we can get the military in there.
AND BEYOND!
At this point, after sufficient bug releases and polish, we will be at a place we’d be comfortable calling it PZ 1.0. However, as we underlined above, that is not the end of the road. There is so so much more that can be done with the game, and we see no reason to stop until, to be frank about it, the amount it costs to support development outweighs the amount of money it makes (and even then you can be sure we’d find it difficult to let go)
If there’s a feature you’ve been hoping for that isn’t on the 1.0 list, then you can probably expect that feature as a free DLC styley update on the ‘completed’ game. Nothing will really change in terms of updates, at least for a long while after the 1.0, but we can sit back and feel proud that we delivered everything we initially set out to do and everything from that point on is a lovely bonus. We’re very excited to see where it goes!
So that’s the situation, hope you’ve enjoyed reading, and now back to trying to make those damn NPCs understand that smashing a window right next to an open door is just not cool.

Update !
 
[NEWSTUFF]
FISHING, YAY ! (info thread coming soon) Axe will lose condition when used to chop trees. Sledgehammer will lose condition when used to destroy things. [MP] Password will now be hashed in the data base. (yeah, HASHED and not encrypted, damn me... Thanks Kirrus for the highlight )

2 days to read a book is not realistic ? You're right, it should take 1 week or so, go grab a 500+ pages books, start a zombie apocalypse and read it...

Hello everyone,

No Dragons this time... Damn, they'll never let me dev the Dragons....
 

Please note there's a bug with the Mac version where some people's game world may appear as a big jumbled mess. This should be fixed within the next 24 hours.
 
[PERFORMANCE]
Big improvements to multithreaded rendering performance. [bUGFIX]
Fixed a bug in the thunder : The system roll a dice each day, and you have 1/20 chance of having a "thunder day", though a bug made every day is a thunder day ! So yeah, I know some of you loves thunder, but you'll have much less of them now.. Fixed some farming bugs (mainly plant disapear though you could still water them etc. Thanks Twiggy for the saved game ! ). If you have an item equipped in both hands (e.g. baseball bat) and unequip it, the BOTH hands will now be unequipped. Light switches and lamps should Just Work ™ now. Whether a light switch is on or off is now saved (which required the world version to be bumped). Plus, turning a lamp on or off in a room will no longer turn all the room's lights on/off. Light switches have a higher priority than other objects so they're easier to click on (I figure that's ok since they're so tiny, they won't block you clicking on important stuff usually). Also street lights don't mysteriously shut off after you leave an area or reload your game. And Mash has been busy adding missing switches and lamps to the map. Fixed not being able to click the scrollbar in the options screen when scrolled down. Fixed the Reload difficulty combobox getting repositioned after clicking (it's position was getting restricted to the screen size even though it is in a scrolling parent widget). Made a few attempts to fix weapon-related bugs. The timed action queue would sometimes get broken when firing/reloading while other actions were in progress. Fixed hovering the mouse over the moodles at non-100% zoom. Fixed multiple attacks per attack animation while holding down the left mouse button. This doesn't fix the pistol shooting too quickly, it has a very short attack animation. Fixed the shotgun sprite not rendering while aiming it. Fixed the mousewheel not working in the character-creation screens. The main options screen was getting the mousewheel events even though it was hidden. Fixed the traits list in character creation not scrolling properly after removing traits from it. Fixed dragging tabs out of the character info window. Now when you drag a tab out to a separate window, that window will be toggled by the hotkey. So if you drag the health tab out, 'h' will hide/show just that window. Ditto for the skills and traits tabs. Squares along chunk boundaries were all marked as blocked in the NE or SW directions. Tracked this down after I saw some weird lighting on the ground near a streetlight. Probably affected pathfinding too. Light switches were using 30 days as the electricity cuttoff date when they should have been using the sandbox option (14 days in survival). Ambient light from outside buildings shines through windows and doors so rooms aren't quite as dark at night. The code for this was already in there but got broken at some point. UIElement no longer creates a double-click if the mouse moved more than 5 pixels in any direction from the initial click. Fire fixes:MIssing sprites. Still some missing smoke sprites due to a naming issue in the pack file. The same fire added twice to the global list of fires. Fire objects not getting removed from the square they were on after they burned out. NullPointerException due to fires getting added where they weren't allowed. Characters that were burning when saving the game weren't given fire sprites or light after loading. When a real zombie was turned into a virtual one the fire sprites and light were not removed from it, so when it got turned into a real zombie later it looked like it was burning. Got the molotov weapon working pretty well. No idea if they can be crafted or not. You can see the molotov flying through the air when thrown (It was using a sprite that didn't exist). After throwing, another molotov will be chosen as the current weapon if the player has one rather than switching to some other weapon. The throw physics needs work. Currently, the closer the target, the lower the throw velocity. Crafting stairs bugs fixed. There was a field not being saved that caused crafted stairs to become blocked when trying to use them. There was also a bigger issue that put new grid squares into the wrong location, so when you went up the stairs there was no floor tile at the top and you ended up floating on z=1. The fix for that might break other stuff though. This : http://theindiestone.com/forums/index.php/topic/4571-possible-to-refill-a-bowl-of-water-infinitely/ fixed Fixed crafted items in a bag not being transferred to the main inventory before crafting begins. This is the reason your clothes get ripped when you click on an item in one of your bags to make bandages for example. Fixed farming actions causing the player to walk right onto the plant's square instead of stopping next to the square. Fixed the inventory tooltip being invisible after unpausing the game if the mouse was hovering over the inventory window. Also, hide the inventory tooltip when mousing over the Category column, otherwise it obscures the grab/drop buttons and stays stuck on the last item it was over. Fixed right-clicking on windows with containers behind them. Items in equpped bags show 'unpack' instead of 'grab' buttons. There was a save/load bug that broke this. Fixed glitches with clicking/dragging tabs in the character info window. Fixed the inventory/loot windows sometimes getting "stuck" following the mouse. Fixed the -Game Paused- text being off-center. Fixed the player sometimes getting drawn overtop of objects after coming down a staircase. Fixed skill-book reading times. If you increased the game speed while reading, the book would get read much more quickly. Now every page takes 2 game-world minutes to read no matter the game speed. The player now remembers how many pages of each type of book have been read. In the old system, each book recorded the number of pages read in itself only. That was a problem if you started a new character from an old savefile, the new character couldn't read already-read books. Fixed DrainableComboItem rate of depletion. Candles would not be drained at 60 fps. Unequip items (such as candles) when depleted. The item selection is cleared when switching containers in the inventory/loot windows. Fixed inventory item text being drawn more than once when dragging. Fixed not being able to unequip clothes from the primary/secondary slots. Damage from fire to the player wasn't affected by the speed setting. Fixed mysterious burnt wall tiles sometimes appearing where fires had been after sleeping. FIxed mod resources and savegame thumbnails not loading on MacOSX. Food starts cooking when its internal temperature reaches a certain point, not just when the stove it is in is at a certain temperature. A side effect of this is that food will continue to cook for a short time when removed from a stove. The 'Skill points available' display was changed to handle double-digit skill points better. Fixed an exception when placing a farming plot while it was raining. Also fixed sprites from previously-built items showing up when rotating a farming plot with the 'R' key. Fixed Lua timed action update() method not seeing the 100% job delta. Fixed Lua debugger not centering the source window on a breakpoint. Screen resolutions are now sorted by increasing width and height in the options. Fixed o/p keys in Last Stand challenge 2 working in challenge 1. Fixed the on/off state of building alarms not being restored properly.  The game would correctly save whether an alarm was on/off, but would only set it to 'on' when reloading a game.  Because of this and because the on/off state is initially randomized every time a game starts, over time more and more buildings would get alarmed.  When loading an old savefile, the status of alarms will be reset to a reasonable amount.  This should only affect buildings that haven't been explored yet.  You'll see the total number of alarmed buildings printed to the console. Clicking the 'inventory' button will toggle the loot window in sync with the inventory window, in case one was visible and the other was not. Fixed multiple raindrops and rain splashes on single tiles. Fixed randomly seeing through walls.  If you ran right along a wall, you could sometimes see inside the building.  This also seemed to happen when climbing through a window. Fixed animation issue with zombies climbing through windows, they would appear to teleport forward for 1 frame. Fixed the text-entry box drawing text when it's parent was collapsed.  If you use the NecroForge mod you'll know what I mean. [NEW STUFF]
Added mouse-over highlighting to combobox choices. Added 'walk to' timed actions before using a water source, using a stove, or grabbing items off the ground. No more refilling your bottles from across the room. When clicking on a container in the world, that container will be highlighted in the loot window, but only if the container is in the loot window. Previously, some other container (or none) would be highlighted even though the clicked container's contents were in the list. Added a 'layout manager' to remember the size/position/visibility/pinned state of the various game windows. It remembers this at each different resolution. All the info is saved to layout.ini in the user's Zomboid folder whenever the game exits during the new OnPostSave event. Added mouse-over highlighting to combobox choices. Restored the old pulsing read damage indicators in the health panel. Made the character-trait tooltips easier to read in the tabbed character window. You can now build light sources, for now only one : some planks, some nails + a torchlight and here you go, a 4 directions torchlight on a wooden pillar, don't forget to turn it off when you leave your base as it drain energy ! Also don't forget to change the battery some times.. Note : This is fully moddable, you can do light source with everything you want, including fuel you want (or no fuel but just a life, like for candle, but those are planned already ), don't hesitate if you have some question on it ! Campfire context menu now has submenus for "Add Fuel" and "Light" so you can choose exactly which inventory item to use. You already could choose the item for "Add Fuel". When pausing the game, all the in-game windows are hidden so you can't click on them while using the option screen. Less clutter too. A progress bar shows how long until food is cooked, and how long before it is burned after cooking. You need to expand the food item in the inventory window to see the progress bar. When filling dirt/gravel/sand bags from the ground, only 1/4 of the bag is filled each time. Submenus let you choose exactly which bag to use. Also, the player must walk next to the spot when filling a bag. Campfires are a bit nicer. They have an actual animated fire sprite and will set the player/zombies on fire if stepped on. Light cast by the fire goes on/off as it should.  Adding fuel to a campfire increases the amount of time it will burn as well as the light radius.  A new file camping_fuel.lua lists the different fuel types and how much burn-time each is worth. For modder's, nested Lua tables in mod data are now supported:Keys may be either number or string.  Only string was allowed before. Values may be boolean, number, string or table.  Only number and string were allowed before. The game will write all of its console output to a text file ~/Zomboid/pzlog.txt in addition to the console. A new OnResolutionChange event fires when the screen size changes.  This is used to update the layout of the various option screens gracefully.  The option screens are not so small on 1024-pixels-wide or smaller screens. Zombies will (usually) wander away from a window they just climbed through.  This was done to fix the jumping in/out of a window repeatedly, although that still happens sometimes. Any item that can store water will now show a 'Pour on ground' context menu option.  This means that bottles of Mayonnaise, bowls of soup, etc, can be emptied out. Custom maps now supported.  You can create a mod, put one or more custom world maps into the media/maps directory, and they will show up in the map selector screen when creating a new character.  They will only show up for enabled mods.  Savefiles remember which map directory the world came from, so if the mod gets uninstalled or disabled, you won't be able to play that savefile. [bALANCE]
Changed things in the torch lighting, first all light source are a bit stronger (candles, lighter and torch light), plus the torch flicker is now much more realistic. [EASTER EGGS]
Only a real Sir know how to moonwalk... [TRANSLATIONS]
Fixed Turkish translation. [OS X Changes]
OS X now uses Java 7, meaning you'll need OS X 10.7 or later to play. Sorry for the inconvenience, but we needed the OS X package updated to work with recent Java and OS X 10.6 and below uses Java 6. Contact Rathlord if you're using an older OS, he may be able to show you a workaround. Java is now packaged with the game for OS X. Java version on computer is no longer relevant. OS X can now use the Launcher Mod posters now function on OS X Mod sprites now function on OS X

Anyone else waiting for this release to start a new game  ?

GUTROT ISLAND

http://theindiestone.com/forums/index.php/topic/12359-vacation-islands-pre-alpha-1/
 



Preview:

Been pushed for time lately, so apologies if these are too late or of no use.... but here are some clips I quickly grabbed this morning before work
 
Chopping wood
http://www.youtube.com/watch?v=K9sUn40whPg
 
Dropbox - https://dl.dropboxusercontent.com/u/7891477/chopping.mp4
 
-----------------------------------
 
Basic walls
http://www.youtube.com/watch?v=JxmPUdPjpqo
 
Dropbox - https://dl.dropboxusercontent.com/u/7891477/carpentry01.mp4
 
-----------------------------------
 
Basic table
http://www.youtube.com/watch?v=WvdUEEKwCuM
 
Dropbox - https://dl.dropboxusercontent.com/u/7891477/carpentry02.mp4
 
-----------------------------------
 
Building a crate
http://www.youtube.com/watch?v=zZOJQPGgSPA
 
Dropbox - https://dl.dropboxusercontent.com/u/7891477/carpentry03.mp4
 
-----------------------------------
 
Farming
http://www.youtube.com/watch?v=6_OJPnn6eXQ
 
Dropbox - https://dl.dropboxusercontent.com/u/7891477/farming01.mp4
 
----------------------------------- Sowing seedshttp://www.youtube.com/watch?v=IWKet2-QSck Dropbox - https://dl.dropboxusercontent.com/u/7891477/farming02.mp4 ----------------------------------- Destroying a wall with sledgehammerhttp://www.youtube.com/watch?v=pYmdKN9l6MI Dropbox - https://dl.dropboxusercontent.com/u/7891477/destroy.mp4 ----------------------------------- Lootinghttp://www.youtube.com/watch?v=yHQEz9Gg4J0 Dropbox - https://dl.dropboxusercontent.com/u/7891477/looting.mp4 ----------------------------------- Indoor combathttp://www.youtube.com/watch?v=IFmx4A375zE Dropbox - https://dl.dropboxusercontent.com/u/7891477/combat.mp4 ----------------------------------- Escape routehttp://www.youtube.com/watch?v=bJljARy4zs4 Dropbox - https://dl.dropboxusercontent.com/u/7891477/escape.mp4 

Hello everyone! To save the Mondoid being a million miles long, we thought we'd post the details here and link them on the blog.
 
So we've made some big changes to the rendering engine. While the effects of this change may be somewhat subtle in the short term, it will have dramatic effects to the future of the game, and opens up many many exciting doors that were previously closed to us.
 
Last Wednesday, we were concerned to discover the game’s memory usage had once again bloated to the point the game would no longer function on many lower end PCs. We had one more quite dramatic card up our sleeve. As is usually the case, necessity is the mother of invention, or rather necessity made us do something rather dramatic that we’ve wanted to do for a long long while, and while the timing of such upheaval couldn’t have been worse, now we’re at the back end of it and everything looks set to work smoothly, we’re immensely happy and excited to be able to share.
 
To explain, and since the Isometric blog post we wrote way way back in time (with now defunct missing images due to the various server moves over the past few years) we’re going to have a revisit to the subject. The TL;DR version is on the blog here.
 
THE GENESIS OF ZOMBOID
 
As many who have been around since the start may know, while Zomboid is a game we’d wanted to do for many years, as an actual project it was born out of myself and Binky realising we couldn’t afford to pay the rent on the flat, and panickedly having to get something out there with a rather pleading blog post and paypal button. This was in a time before Kickstarter was a ‘thing’ in terms of game development, and inspired by what Minecraft showed was possible, we figured it would be our best shot at keeping the landlord at bay.
 
The decision to make the game isometric came from a few angles. One, we realised that with a topdown 2D perspective would mean making zombies visible at windows would be really difficult. Secondly was a certain obsession with XCOM and the ambition to make something that had a similar look. Thirdly, we found this awesome program http://www.mapeditor.org/, Tiled, that would one day be taken and expanded in exciting ways by the awesome EasyPickins.
 
In its basic form, Tiled supported the isometric perspective. So we started making a few isometric tiles that we could use to construct maps in Tiled. This is what we ended up with:
 

 
As you can see, the tiles have been drawn directly in a faked iso perspective, so when they are assembled, they create the illusion of a 3D. This fit our needs perfectly, and meant we could get a working isometric engine up and running in a matter of days. Within a few more days, we had a basic prototype of character running around being hunted by zombies:
http://www.youtube.com/watch?v=dg2zpd747FA
 
Tiled was key to getting stuff where it was so quickly. Writing an entire map editor and not getting the game up and running ASAP was not really an option.
 
Of course, alpha-funding being what it is, the momentum is always behind you to get results, and we had no idea where Zomboid would one day end up. Smooth character animation, real-time lighting of the world, and many thousands of tiles. Also in our naivety to Java, OpenGL and engine development in general, as well as the degradative effect of the pressure to make visible strides forward, or of course all the roadblocks that lay ahead of us, we didn’t then realise how much trouble this would cause us later down the road.
 
THE PROBLEMS
 
2D doesn’t always mean ‘fast’. Our assumption at the time, just like everyone who has ever complained of the FPS of Zomboid with comparisons to Crysis or Left4Dead, that drawing a few low resolution sprites on the screen for walls, floors and zombies, would never lead to issues with performance. However, we didn’t realise at the time quite what a nightmare the isometric perspective is when approached this way.
 
First of all, if you look at those walls again, you can see quite how wasteful they are in principle.
 

 
That’s one set of walls, and there is a lot of repetition there. Also, because of the iso perspective, it means there is a ton of wasted blank space around those walls. While when you’re dealing with one or two set of walls this doesn’t seem like an issue, once you’re dealing with 50 sets, or 100 sets, or 200 sets of walls, suddenly that begins to bloat. Same with the floors.
 
Second comes the problem with the isometric draw order. Imagine you have a deck of cards, and place them around on the surface of a table. Each card will end up obscuring cards under them, and this is the principle of drawing 2D scenes. You draw the stuff furthest away first, then progressively draw stuff closer and closer to the ‘camera’ until you’ve drawn everything. This will ensure that everything appears correctly, and you don’t see objects that should be obscured by walls.
 
Draw order in top down 2D games generally isn’t that big a deal. If you look at Dwarf Fortress, for example:
 

 
Nothing overlaps, so it makes no difference what order any of those tiles are drawn. The only time it matters is if one tile is on top of another, a character stood on top of an object for example.
 
For this reason, 2D games can usually sort their drawing into any order they like, and end up with the same scene.
 
Other perspectives, such as the orthographic viewpoint used in RPG Maker style games, have the requirement that stuff be drawn back to front, but again, like our game, they tend to have rather small requirements when it comes to rendering (assuming of course PC and not a mobile device with very limited rendering speed)
 
What we had is literally the worst of all worlds. Not only does stuff have to be drawn back to front, but also side to side. And then down to up. We might have a screen in 1920x1080 where the player can see thousands of tiles, and all of them, even the characters on the tiles, have to be drawn in a very strict order, otherwise it all falls apart.
 
This would be okay, if graphics cards didn’t suck so badly at doing this.
 
The key issue is that graphics cards deal best with doing ‘a bunch of similar stuff’. They can do ‘a bunch of similar stuff’ very very fast indeed, but as soon as you get into the realm of them doing ‘lots of individual different things’ they perform woefully bad, to the point that (setting aside java, a small development team and limited time)  a 2D isometric game like Zomboid can have severe bottlenecks that a much grander and more impressive 3D game would not.
 
Imagine Far Cry 3, for example, in the midst of a jungle scene. It would be crazy to suggest for a second that Zomboid had more on its plate to deal with than Far Cry 3 graphically, so the assumption is that if Far Cry 3 runs well on your machine, then it’s shockingly poor of Zomboid to have even a slight hiccup.
 
However, 3D games have a few tricks up their sleeves which give them huge advantages.
 
So we have a jungle scene, and logic would suggest that, like I have described, you would need to draw everything from furthest away to closest, so that you don’t draw a tiny distant radio tower over a tree right next to the player.
 
In this case it would involve a very very intensive sort, taking everything in the world and ordering it by distance. On top of that, as I said, graphic cards deal very well with drawing ‘lots of the same kinda stuff’ and very badly at drawing ‘individual different stuff’. So drawing a radio tower, then a bit of hill, then a tree trunk, then a leaf, then a branch, then a fence, then a branch, then a leaf, then a tree trunk, would leave even the most powerful PCs in the world crawling at less than 1FPS.
 
Z-BUFFER
 
However this is not necessary due to something called a ‘z-buffer’. A z-buffer, or depth buffer, is like an invisible canvas on which the graphic card automatically draws to as it draws anything in the scene. Imagine it is a greyscale black to white image. Every pixel it draws in the screen, it will also draw a value into the z-buffer where stuff far away is black, and stuff right next to the camera is white. Or vice versa, it’s not really a colour, this is just to ease visualisation.
 
Then when it draws another thing, it can test the value in the z buffer for each pixel it tries to draw, and if the value in the buffer shows what is there is already closer than the thing you’re drawing, then it simply ignores that pixel. As such, this allows you to draw the scene in pretty much any order you like, and it will magically construct itself in back to front. It’s frightfully clever.
 
As such, you can leverage the ‘same kinda stuff’ power of the video card, and perhaps draw every single leaf in the scene first, all using the leaf texture and perhaps the leaf 3D geometry. Then you could draw all the tree trunks, then all the branches, then all the ground, then all the radio towers, then all the characters, and then all the birds. As such you can basically send a massive list of things to the graphic card that it can burn through at a magically impressive pace, instead of sending individual things, one by one.. And so you get super fast drawing and much faster FPS.
 
So therein lay the problem for Zomboid. While technically it is perfectly possible to use z-buffers on 2D games, due to the nature of the engine, the tiles, and everything else this was never an option for us. As such drawing the world is ‘draw a wall, draw a fridge, draw a floor, draw a wall, draw a zombie, draw a wall. And this took a heavy toll on the best case speed we could ever strive for.
 
Add onto that the smooth lighting. I think everyone will agree the emersion and graphical improvement of the smooth lighting adds a lot to the game, but it massively exacerbated our problem. 3D games do lighting via tinting each vertex of a 3D model to different colours (actually this is not strictly true, lighting has moved on dramatically and is more likely to use shaders and normal maps and things these days, but this is certainly how all 3D games used to do it) however due to our isometric tiles being ‘faked’ by being drawn by the artist directly in the isometric perspective, we never have the corner vertices to do the lighting this way.
 
Instead, we had to draw a polygon over the top of the unlit tiles, using something called a blend mode (basically changing the way the texture is drawn to do funky effects not unlike photoshop blend modes for example). The state changes required to change blend modes, as well as the fact that these had to be drawn immediately after the wall / floor piece, and then the blend mode being switched BACK to draw the next tile, only served to make the problem worse.
 
And at the same time, the memory requirements for the graphic cards increased and increased, due to the increasing numbers of tiles, and the smooth character animations. The price of progress, huh?
 
TEXTURE SPACE
 
Then came surprise number 2. It turned out many lower end graphic cards, particularly integrated cards such as our (now nemesis) Intel, either did not have any dedicated memory of their own, or worse did but still for some reason required that they mirrored the contents of that memory within the main memory of the PC. Worse still, that used memory would be within the same process as the game, and on 32bit systems particularly, there is a limit to how much memory each process can use before it bombs out with an out of memory error.
 
This struck a few months back and took us a while to track down, and was a rather worrying moment when we realised quite how much memory the characters and tiles were using, and how that memory had been masked by most graphic cards taking care of it in their own internal memory chips.
 
The most obvious answer to remedy this problem would seem to be ‘make them all jpegs’ or something, however the problem is that the actual file format is not at all relevant in this case, since whatever format the texture is stored as on a hard disc, once it gets into opengl memory it’s the very same 32bit RGBA texture. However, there is one compression format that pretty much any graphic card these days support. S3 Texture Compression (S3TC). It’s used very heavily in games, or at least was when we were making PS2/XBox games. DXT textures, while bigger on your hard drive than a PNG or JPEG, can be loaded into openGL in their compressed format, and even drawn directly in their compressed format, so take up much less space in memory (potentially a 16th). However, like MP3s or JPEGs, it is a ‘lossy’ format, which means the quality of the texture is irreparably reduced by the compression.
 
For something like a 1024x1024 dirt texture, this is annoying but more or less trivial, since the artifacts would barely be noticeable unless you had the textures side by side (though I’m sure most texture artists would strongly disagree). On a small sprite, this is another thing altogether, so we didn’t really think this was an option.
 
Even so, we attempted to compress all the character sprites with DXT5 and, somehow, remarkably, the results weren’t bad at all. There was a very noticeable drop in their quality, but we totally got away with it and to this day haven’t read one comment pointing this out. Furthermore we shrank the total size of the character textures to about a fifth. That was a good day.
 
However, due to the frequent complaints about the FPS of the game, and knowing the limitations imposed upon us we’ve described, we’d started to run out of ways to dramatically speed up the game, and with more features being added, more tiles, more things for the game to deal with, the problem was only going to get worse. Profilers (special programs that let you measure how much time is being spent in every part of the code) were yielding less and less ways to speed the game up, beyond caching things.
 
Caching in terms of optimization basically involves creating extra data in memory to save you repeatedly redoing the same CPU expensive things, and as you might guess, these kind of optimizations may speed the game up, but also take it’s toll on the memory. The two things are entwined, and once you’ve sped up all the inefficient code you can, its hard to make any savings without bloating the memory requirements. An eternal tug of war ensues.
 
In the meantime with West Point under construction, crawling zombies, and various other things then memory starts creeping back up. Of course it creeps up to pretty safe levels on most machines, but then in the frantic climb up Steam mountain it’s easy to miss that malicious demon sneaking back in. So we got to last Wednesday, when it became apparent that the test team members with problem GPUs were having problems with the game again.
 
So we whip out the S3TC again, this time our target is the tile sprites. We push them through, and have a look at the file size. Hurrah! We’ve done it again, DXT to the rescue. The Shadows are gone and will not return for another 1000 years.
 
Then we run the game, run around and wonder what all those blotches are around the world, and the colour drains from our faces. To make sure, we load the DDS files and look at them.
 

 
Oh no, what are those? They aren’t supposed to be there!
 
Looking through more and more files and it only gets worse, and we realise what a colossal fluke it was getting away with compressing the character sprites. Massive blocks of colour, horrible lighting artifacts. In a game where we had just reintroduced zoom back into the game, they were just awful to the point of being unusable.
 
So there we are, in a Newcastle centre coffee shop, at a mass mocha/latte quaffing session of the Indie Stone crisis management panel: Lemmy and Binky rolling off ideas on new ways to lower the memory usage of the game.
 
“We could always….?”
 
“What?”
 
“You know what. Is this the time to do it?”
 
“My God, you can’t possibly mean… but we’re dialing up for Steam, now is not the time.”
 
“Now is exactly the time.”
 
And so we made some rather dramatic steps, or rather we decided to explore the possibility of doing something we’ve wanted to do for about a year and a half but were too scared to entertain the possibility.
 
Ladies and Gentlemen, say goodbye to the walls of yesteryear.
 

 
...and say hello to the walls of the future:
 

 
So we went back to our prospective PCs, and Binky cracked out C# and tackled the projection of the iso tiles into 3D (which frankly hurt my brain to even think about) as well as developing a tool that would automatically convert every floor and wall into flat textures. Meanwhile I set about adding support into the PZ engine to render 3D polygons in an iso perspective, and creating a system for ‘prefabs’ to allow us to make walls, windows and doors with any of those textures, and for those to be automatically created from the isometric tile data.
 
Yes, in a rather remarkably sudden move, Project Zomboid is now, TECHNICALLY, in 3D. Madness!
 
BUT WAIT, THIS DOESN’T MEAN WHAT YOU THINK IT DOES.
 
It’s worth putting that as a header by itself. You are NOT going to get a first person view, and you are NOT going to get a rotatable world. This can’t be expressed strongly enough.
 
We still have hundreds of fridges, sofas, cabinets, trees, characters all in bonafide 2D with fake isometric drawn directly into the tiles. This isn’t going to change (though who knows for the next game in the PZ engine, or perhaps post-multiplayer, years down the line, we’ll get some hair brained ambition to do it, so it’s always a tantalising possibility where prior was a literal impossibility)
 
However, in very real terms, the PZ you will see from the next version going forward, is doing all the same things a 3D game does. The only difference is it’ll have a cast-iron fixed isometric orthographic viewport of the 3D world, so all the furniture, trees, tall grass and characters, still in 2D, can be drawn into the world as pixel perfect camera facing billboards and match the perspective perfectly.
 
SO WHAT DOES THIS MEAN?
 
It means many things.
 
- Primarily, it means that if you compare the two different sets of walls above in terms of space, a single 1024x1024 texture will now be able to hold every single wall, floor, wall overlay and floor overlay in the entire game onto one single texture, with room to spare. For each single texture, we could perhaps get another 200 different wall designs, Instead of, perhaps 5-10. This is obviously huge in term of memory saving.
 
- Just as primarily, it also means that we can finally use a z-buffer in our game. We therefore are no longer confined to the isometric draw order, the single most wasteful and restrictive thing we’ve had to deal with since day 1. We could draw every wall visible on-screen, all at once. Then we could draw all the zombie hairs, then all the clothes, then all the furniture. In any order we like. The potential difference this will make to our FPS is, hopefully, the most significant optimization we could make to the game, and dwarfs everything we’ve been able to do before. We suddenly have every tool in the 3D toolbox available to all those games doing a lot more intensive stuff than we are. We’re free, liberated finally, and it feels gooooooood.
 
It should be noted however, that these FPS savings may not come straight away. It will be gradual. We still have a version to get out, and Steam to get ourselves on, and so our first implementation of this will unlikely get the full benefit, and will likely offset the FPS increase with sufficient slowdowns in the immature first version of the system. Don’t expect huge things straight away. However, now finally there is a whole pile of things we could do that could have a dramatic effect, instead of us having to claw back little bits here and there with one giant immovable bottleneck.
 
We would have done this sooner, but please understand that this was a bold move that we only dared tackle now of all times because we felt we had no alternative, and we could have gotten a few days into it and discovered another month of work ahead to get it finished. If that was the case we’d have had to find a plan B, and we’re immensely glad that won’t be necessary, since it’s difficult to imagine what that plan B could have possibly been. However, the last hurdle in the ‘is this even possible?’ category is behind us, and while it may delay the release a bit further (we’re talking days, or a week, or a couple if we’re dramatically unlucky, and not weeks or months)
 
So if memory savings, and FPS aren’t exciting to you, here is an insight into those ‘new doors opened’ beyond that. Things that were not possible but now are. Please note some, or all of these, may not appear for months or even years from now, and some may be trivial to add in the short term, and this is just an indication of what is now on the table.
 
- Cutaway walls. Yes. Sims style cutaway walls becomes trivial, and is a certain addition in the near future. As a bonus this means no more reliance on the stencil buffer, which means lower end users may be able to play the screen with smooth lighting, shaders, split screen and zoom, where they were once unable to.
 
- Terrain heightmap and freeform texturing. Imagine running through the wilderness over hills and into ditches, falling off cliffs, digging the ground out for construction, natural cave systems. We’re no longer shackled to the isometric flatness and 90 degree roads. The potential for making the wilderness an infinitely more exciting place to be is very exciting.
 
- Proper lighting - Imagine shining a flashlight around a room and seeing the light on the wall, the filament of the bulb, seeing the tall shadow of a zombies cast through a backlit doorway.
 
- Fog / Particles - The iso walls always had the potential to make particles clip through the walls in an ugly way without the zbuffer. Now we could use 3D fogging on the map, as well as look into more atmospheric particle effects, think of ground hugging fog drifting about the place.

Steam codes, anyone? Yes, Steam codes are now available to anyone who has purchased the game. To make it clear, we are NOT on Early Access, and are just giving those who already own the game an option to get on Steam now. We're posting this just here for now, to get any serious kinks out the system before we shout too much about it.

 

Important things to read first

 

1) The version that's on Steam is effectively build 17, since the only build possible to use was one with Steam integration we couldn't upload the last Desura build, or forum test 16. However, there may well be some bugs still in this build that need sorting out, and some of Romain's stuff like translations is not present in this branch of the game. So please don't consider this an official release. This is about getting people on Steam who want to be, primarily, so we're not cramming it all in last-minute and risking any delays. That said, a few issues aside, will give you a chance to play with the new stuff in the build!

 

2) There is currently no 'install script' for auto installing java and whatnot on the three platforms. This will come within the next day or two. If you can already run the game, then you should be golden. 64bit OS users who used to run the game in 64bit may need to get Java 32bit (x86) JVM installed if they do not. This will obviously be automated soon

 

We could have waited on distributing keys until build 17 came out proper, however its in everyone's best interests we get people's transition to Steam sorted gradually but ASAP, well in preparation for going on Early Access proper. As such, please excuse any features advertised for build 17 not present, or any issues in this immediate release. It will be auto updated routinely over the next few days to patch out any remaining issues.

 

3) At this time the only way to obtain a key is through Project Zomboid on a Desura account. The ever awesome Desura have offered to help us distribute keys to everyone, even those who did not purchase the game on Desura. To do this ourselves would likely have absorbed a whole chunk of our time that could be spent working on getting the game ready, so this is wonderful of them.

 

We would very much appreciate anyone who hasn't bought the game through Desura to look through the games when they convert, and consider sticking around the community, because there are many gems in there including many ungreenlit games that deserve more attention. And as evidenced for doing this, Desura themselves deserve endless support!

 

Converting to Desura for Google Checkout / Paypal purchasers

 

To convert to Desura, input your Project Zomboid username and password (game log-in details emailed to you when you bought from Google Checkout, NOT your forum user/pass) into this form:

 

http://www.desura.com/games/project-zomboid/activate

 

Finding your Steam key

 

When logged onto Desura's website, go to this page:

 

http://www.desura.com/collection

 

Click on the 'Keys' link, and you'll find the Steam redeemable code listed there. "Activate a Product on Steam..." in the Steam game menu. Alternatively, go here:

http://www.desura.com/games/project-zomboid/keys

 

Simple as that.

Question for Mondoid: Will you be adding a feature in which you can move furniture to act as a barricade?

Question for Mondoid: Will you be adding a feature in which you can move furniture to act as a barricade?

Question for Mondoid: Will you be adding a feature in which you can move furniture to act as a barricade?

Question for Mondoid: Will you be adding a feature in which you can move furniture to act as a barricade?

Question for Mondoid: Will you be adding a feature in which you can move furniture to act as a barricade?

Question for Mondoid: Will you be adding a feature in which you can move furniture to act as a barricade?

Question for Mondoid: Will you be adding a feature in which you can move furniture to act as a barricade?

How is the Dragon Implementation going and will they be as OP as expected?
 
Serious question: While I know multiplayer is a ways off, but will NPC's still be in the game if you're playing in Multiplayer and will they be easily distinguishable from other players or could a player potentially hide himself amongst NPC's if he role plays well enough?