Indie Stone logo

News & Dev

On optimization and time…

February 22, 2012

Knox County evacuees, your attention please. The situation is now under control. Soon you’ll be able to return to your homes, eat delicious Spiffo burgers, sip hot beverages in the local Seahorse cafe and walk through Muldraugh’s verdant woodland. The Knox County incident is now under strict governmental control. The outbreak is contained.

Well, sort of. Thanks for your ongoing patience everyone, we’re now down to five tasks that must be completed before release, and some nightmare pathfinding issues have been resolved with the help of countless gallons of coffee.

Another task that’s now pretty much mission accomplished has been optimization. There’s much more complicated stuff going on in the world now: making it more persistent with hordes that persist as real zombies instead of virtualised versions, and who always collide with each other to prevent stacking problems, had been pushing up the minimum spec of the game far too much. When you factor in NPCs capable of navigating to any point in a more substantial map and new features like pushable furniture there was a real danger that we’d start to lose a large chunk of the bottom end of our current customers.

While we’ve warned that this may happen, it felt like we were in a danger zone: too sudden a change for the customers who’ve waited so patiently for us to sort our shit out and get them their much awaited new dose of Zomboid.

So in the recent parts of the task-list some heavy duty optimization offensive went into effect. The thing is that, as any programmer will tell you, optimizations are a mixed blessing. Sure, they speed the game up a lot – but on the flipside making odd changes to the code to eke out extra performance can lead to obscure and messed up bugs. In the recent tasklist slowdown we fell victim to this: new and deadly bugs had to be fixed. Stuff that was working perfectly well in our demonstration videos as CPU hogs subsequently needed more attention.

We’ve now pretty much broken through this barrier. A massive part of the tasklist has been these bugs: some taking days of head-scratching to sort out. Still, optimization has been an ongoing concern. With a lot of people complaining of lagging in the current version, in all honesty it’s been borderline terrifying.

In recent days, however, we’ve had an epiphany. We’ve realised exactly why speed and CPU power have been such an issue, and with it has come a solution.

See, unlike most games, PZ has been more taxing on your computer for one reason alone: fast forward. Having to process the entire world 3,600 times each frame to achieve the required speed to wile away the long nights barricaded in your safe house meant that even one CPU hungry process could knock the fast forward speed down to depressing levels. THIS is why we’ve had such a problem (more so than many other games of our ilk) so instead of breaking the code with optimizations that would be dangerous to our stability we’ve decided to approach it from a new angle.

You know in Skyrim where you choose to ‘wait’? The task we’ve almost completed is us doing that. Instead of processing the world a million times a millisecond, we’re going to cheat massively** and hopefully achieve a comparable effect. Let’s say you’ve snuck back to your safehouse and hammered up a plank of wood, you’re not tired and you’ve decided to sit it out until morning. Clicking the new ‘wait’ icon and the game will go into ‘ULTRAWAITSUPERMODE’ (TM),

‘ULTRAWAITSUPERMODE’ (TM) will persist until you unclick it, or you make visual contact with a member of the living dead. In this mode we’ll only draw the frame once per hour or so, speeding up the clock and day to night cycle essentially fast-forwarding time. We’ll make people get hungrier or sleepier faster, we’ll make zombies and NPCs walk and run much faster, and basically supercharge everything in the game. In terms of you playing the game time will be perceived as being sped up, when in actual fact its just things in the world moving at ridiculous speeds, while the computations required are still only happening as they do at normal speed, massively reducing the strain on the CPU. This won’t be a perfect simulation by a long shot and may have some side-effects in itself, but will hopefully (as early tests indicate) be¬†imperceptibly¬†different to actually fast-forwarding time properly as it currently does.

Yes, it’s technically a massive cheat **, since per hour technically the AI is capable of doing a fraction of what they would be able to normally. But they’ll do it all at ridiculous superman speeds to compensate, and that will massively free us up from the shackles of optimization for this update, and all updates to come.

While this is technically an ‘extra task’, one of those other remaining tasks is ‘optimization’, and trust us when we say that task has taken about 100x the time of any other task and probably would continue to do so without this solution.

On a decent spec PC we can now fastforward through an entire night in about 20 seconds, compared to the couple of minutes it previously took (yes, eek indeed). This has been a massive part of our tasklist, and we’re overwhelmingly relieved that we’ve worked out a way to keep the low-end PCs of PZ players happily infected when the update comes around

Thanks for reading everyone! We’ll make some new videos as soon as this part of the code has been beaten into shape!

** We should clarify at this point that the word ‘cheat’ should not be confused with it being a hacky crappy way of doing things unique to our game. All games ‘cheat’ massively at every possible opportunity. For example, it’s highly unlikely that Skyrim’s wait mechanic runs the game at 1000x speed while you’re waiting. Just fast forwarding time was never initially intended in the game, and the way the feature was added and evolved meant this approach didn’t happen from the get go, as it perhaps would have done if the feature was pre-planned before development.