Multithreading and more…

Posted in Procedural world, Zombox on January 30th, 2015 by Tyson Ibele

So since the very inception of Zombox, I’ve always been fighting with Unity, trying to get it to pump out as many polygons as possible without getting too many slowdowns on mobile devices. Zombox features a huge open world, so this has always been a massive challenge.

When I first started working on the game, I made sure everything was super low poly. Then I learned that Unity can batch geometry to the GPU if it’s low-poly and shares the same material — so I made sure all the geometry in the city used only one material with a large texture atlas. Then when that wasn’t enough, I simplified the geometry on everything further. After that, I developed a seamless world-culling system so that the only geometry that would ever be loaded is what would be on-screen at the time. Even then, I was always treading a very fine line with regards to performance. I had to be very careful not to group too many objects together in the city or draw calls would get too high and the game would chug.

In December I described my custom batching solution to the draw call problem. However, while my batching system greatly reduced draw calls, it created another problem that was still lingering: the batching system itself has a pretty high CPU overhead. It’s not high enough to negate its positive effect on overall performance, but it’s still high enough to be a pretty serious problem. After all, nobody wants to experience annoying framerate hits every few seconds as they walk around the game world.

This week I realized that basically all mobile devices I’m targeting have at least 2 cores in their main CPU (iPhone 4S and above). So with that in mind, I decided to try multithreading the batching system I developed. One of the downsides of Unity is that you cannot access any UnityEngine classes from secondary threads (thereby making multithreading for all built-in Unity objects impossible). But, one of the upsides of my new batching system is that it doesn’t actually rely on any UnityEngine classes! So with that in mind, I was able to quickly and easily shift all mesh calculations (besides those that actually assign the final vert/uv/color/triangles sets to the Unity Mesh objects) to a second thread.

And voila! This idea turned out to work almost like magic! I can now pump *tons* of geometry at my batching system with almost no impact on the core thread of the game — meaning that no matter how complicated the city’s geometry is (within reason), it will never cause the game to stutter or slow down. The game actually runs faster now, with *twice* the amount of on-screen geometry, than it did before with half that geometry!

So this has allowed me to add some stuff to the game that I’ve been wanting to add for years, but never knew how I could do it without killing performance — namely, grass, twigs, stones, debris, and all sorts of other ground details! For years the game has consisted of nothing more than buildings and props on top of completely flat textured planes. There were a few minor ground details scattered throughout, but they were very limited in their distribution to keep them from lagging the game. But not anymore! Check out this before/after animation and take note of all the extra ground detail:

All of this is now easily possible, without any impact on the game’s overall performance! It has been an exciting week for sure.

Now, multithreading my batching system was only one half of what was accomplished this last week. The other half was figuring out a simple, memory-efficient way of being able to quickly identify what type of substance each point of the city’s ground surface consists of. In order to add grass, and other details throughout the world, I need to know where those details should go. After all, we don’t want grass growing inside houses or on the road, for example.

My solution was to define a grid in 3d space, in 3d studio max, that uses material IDs to specify different types of ground substances. The grid system is resolution-independent so that some ground tiles can have less dense grids than others (after all, we don’t need hundreds of grid cells to tell us that the middle of the ocean is composed of water, but we might need hundreds of cells to differentiate between grass patches, mud patches, concrete patches and other substances within the city). This grid is then exported from 3dsmax into a pre-built C# file that auto-loads this substance information into Zombox without any extra computations/loading required. The result is very fast grid->substance lookups that give the game quick access to all the information it needs about what is under the player’s fee, with very little memory overhead.

And the added benefit of this system is that being able to identify ground substances means I can allow the player to do things like…dig! We wouldn’t want the player to be able to dig dirt out of the sidewalk or the road…but if we can find out that the player is standing on some dirt…well, it would make sense to allow for some digging there! This substance lookup system is perfect for that. As you can see, when the player steps onto dirt, the shovel icon appears and he can dig for dirt/clay, which can then be used in various crafting recipes. The substance information is also useful for other purposes as well….it’s an easy way for me to perform checks that prevent players from being able to craft over water, or it allows me to do things like add particle effects for when the player is running through tall grass, etc. Eventually it might lead to the inclusion of other easter eggs…like the ability to dig up treasure?….We’ll see!

Here’s an animation of the player digging up dirt items, which can later be collected and used for crafting:

Apologies for the long post, hopefully some people find it informative!



Crafting – final touches…

Posted in Items, Zombox on January 23rd, 2015 by Tyson Ibele

So I think the crafting system is finally “done”. There will be new craftable items I’ll add in the future I’m sure, but the overall mechanics of the system on the whole are finally finished.

Last week I talked about the different types of craftable objects and the way in which certain constructable props can help you craft. This week I implemented the main crafting catalog, which exists to help the player quickly locate crafting recipes to use in game.

To access the menu, a player just has to click the little “?” button in the crafting panel, and it’ll pop up.

The menu is tailored to show all of the possible recipes that each crafter can produce. Just walk up to a crafter, pop open your inventory window, click the blue “?” button in the crafting panel and you can see all of that particular crafter’s recipes. The crafting window also shows you the name of each ingredient, and whether or not it is currently in your inventory. Recipes are separated into various categories, which can be selected from the tabs on the far left (weapons, items, foods, medicines, etc).

I also tweaked and added a few of the constructable resource gatherers/generators. For example, here is a sped-up .gif of the ‘energy bike’, which can be ridden to generate electricity ammo for weapons like the taser or chainsaw.

Now that the crafting system is fully in place, I can concentrate on a lot of the other loose strings that exist in the overall game’s design. I’m pushing really hard right now to get this game out as soon as possible! Stay tuned for more updates soon!

Crafting continued…

Posted in GUI, Items, Zombox on January 18th, 2015 by Tyson Ibele

So with the successful release of my mobile game Bean Boy (get it on iOS or Android), I’ve been putting all of my efforts into Zombox again, getting all of the kinks worked out of the crafting system.

Last time I discussed the method I’m using to greatly reduce draw calls in the game world, and this time I’d like to talk about the actual implementation of the crafting system in general.

There are currently three ways to craft items in Zombox:

* Static crafts – these are your basic player-made crafts, as well as crafts created by constructable objects whose crafted results appear instantaneously. A static craft is just a craft that allows you to input ingredients, for an immediate output result. Ie, drag your ingredients into the crafting window and *voila*, your resulting item appears instantly.

*Dynamic crafts – these crafts take time to produce their result. Imagine if you planted a seed in the ground — the tree would not appear instantly! The same goes for these crafts. They have a measurable time it takes between inputting your ingredients, and getting an output result. Usually these crafts involve the production/cooking of food.

*Automatic crafts – these crafts are produced by constructable objects that generate resources automatically. Water collectors, solar panels, etc…basically anything that doesn’t require input ingredients in order to produce a result. Like the dynamic crafts, they take time to appear. They also have certain stipulations. For example, solar panels will not generate electricity at night, a water collector won’t collect water when it’s not raining, etc.

It’s taken a lot of work to iron out the bugs, but I’m *nearly* done working out all of the different crafting systems, methods and objects. Right now there are currently *hundreds* of things to craft in-game, and many of the crafting stations are upgradable, allowing players to craft increasingly awesome stuff!

Here are some example .gifs showing the basic interfaces…

To craft, you click the move/rotate icons to place your object, then click the checkmark to build it:

Grilling some fish and growing some plants….note the progress bars that appear on these dynamic crafts letting you know how long it’ll be before it’s done:

Here we see the fish finish cooking…time to eat!:

Here’s a water collector gathering some dirty rain water, which can then be filtered and used for cooking:


World generation and crafting…

Posted in Procedural world, Zombox on December 8th, 2014 by Tyson Ibele

Hey everyone! This is my first official Zombox update in a long, long time.

Since Jungle Moose is out, and Bean Boy is 99% done, I’ve been back working on Zombox.

I left off in March, having finished modelling most of the craftable structures in the game. But one big thing was looming pretty far over my head….

If any of you are game developers yourselves, you’ll know that ‘draw calls’ are the bane of many developers existences (especially those targeting mobile platforms). A draw call is basically an instruction sent to a device’s video card, that tells it to render some geometry to the screen. So, for example, if you have five separate objects you’d like to render, then that will require five separate draw calls (assuming the game engine doesn’t implement any type of batching system). Draw calls are ‘expensive’, which means that they take a lot of processing time to send to the graphics card, and for that reason you always want as few draw calls as possible.

Unity’s rendering pipeline includes a batching system, that can group objects and send them together as a single draw call. The batching system has many quirks, the biggest one being that it can only attach a very small amount of geometry together for each ‘batch’. Up until now it was what I was relying on to render the Zombox world.

However, with the addition of the crafting system into Zombox….I was presented with a pretty major problem: if the user is able to create objects anywhere in the world, then there is nothing stopping them from creating tons of different objects on screen in the same area. Typically, any location within the city in Zombox (where the user hasn’t crafted anything) takes about 30-40 draw calls to render (that’s excluding draw calls for the GUI). That’s already pretty heavy….but if the user were to craft a bunch of objects in that area, that number could increase way past what most mobile devices could handle at an acceptable framerate (even with built-in batching). We’re talking possibly over a hundred draw calls just to render the scene geometry alone! That’s not including zombies or NPCs or even the main character! That’s totally unacceptable and has been a major roadblock in the game’s development.

Earlier in the year I attended a Unity meetup in Toronto where Jim McGinley spoke about procedural generation in his game Endlight. He presented a novel solution for quickly updating meshes in Unity with thousands of changing vertices and arbitrary vertex counts (a process that is normally very slow when vertex counts change): at the start of the game, he generated a separate mesh for each possible vertex count, up to a max vertex count (so if he knew his biggest mesh would have 1000 vertices, he generated 1000 meshes and set their vertex counts from 1 to 1000, respectively). Then when he quickly needed to generate a mesh with, say, 874 vertices, he would grab the pre-generated mesh with 874 vertices, pop his new vertices into it, and hide all the other meshes. This prevented him from having to re-send new meshes to the GPU each frame because all of those pre-generated meshes were already in the GPU, just waiting for their vertex lists to be updated. And the whole thing would only take 1 draw call to render.

Now, that solution worked great for him, but it is also quite memory intensive — and Zombox needs to conserve memory to make room for all of the other procedural content that gets loaded. So generating 1000 meshes isn’t a viable option for me….but it did lead me to come up with the solution I’m using now. Here’s how my current solution works:

  • The scene geometry is imported with a custom tool to automatically cache all base city meshes for quick reading of their vertex/triangle lists
  • When the game starts, I generate about a dozen meshes in a mesh pool, each with a few thousand triangles/verts. The lower the vertex count of each mesh, the less processing time required to update it. However, the more meshes in the pool, the higher the resulting draw call count will be. So, setting the total triangle/vert count to a few thousand is a good balance.
  • Each of the triangles in the mesh are added to a pool of “free” triangles
  • When the city begins to load, instead of displaying each object with an individual MeshRenderer component (which would then be batched and sent to the GPU when it’s time to render), each object instead grabs however many triangles it needs from the pool, and positions the vertices of those triangles to match all of the vertices in its cached mesh. It does the same for its texture verts (UVs). Any triangles used to generate the object are then removed from the “free” triangle pool
  • If, at any point, the “free” triangle pool ever gets used up before all base city meshes are displayed, I simply add a new mesh to the mesh pool and pop its triangles into the triangle pool, and keep going. No matter how many objects a user crafts on-screen, I’ll never need more than about 20 pooled meshes to draw them all, considering that on-screen vertex counts can only ever get so high before there’s no more room to craft things in screen-space
  • Any time an object is unloaded from the game, its pool triangles are added back to the “free” triangle pool, and all of the verts that were used are set to be degenerate (which causes them not to render anymore)
  • Any time an object is updated, I cycle through its pool triangles and just update their vertex locations

Now, that’s a pretty big mouthful of information — what does it entail? Well it means that I can render the entire Zombox world, no matter how many objects the user crafts, in about 12-20 draw calls….which is pretty amazing!

That said, there is a performance hit that occurs by doing all my custom batching/pooling operations. But, by spreading those operations out over a few frames and not doing all of the geometry calculations at once, the hit is small enough that it doesn’t affect the game’s framerate. So it’s a pretty great solution to a pretty massive problem! Caching all of my mesh data beforehand also means that I don’t need to do any allocations per frame in order to read mesh triangle/vertex data. The downside to caching is that it means you have to create a duplicate of your mesh data in memory, on top of what Unity already caches under the hood. My solution to that was to scrap FBX import of the city geometry all together and write my own mesh import system, which means I’m only ever holding 1 copy of each city mesh in memory at once, and I still don’t need to do any extra allocations to read geometry data.

So, as you can see, I’ve been busy despite my silence! But the results have been worth it.

Not everything I’ve been working on has been under the hood, though. I’ve also been working on the crafting interface and getting all the new craftable structures implemented into the game! The crafting interface (that allows you to place and rotate objects you want to craft) is still a work in progress, but you can see a result of some construction in the image at the top of this post.

Thanks to everyone for you continued support, and look forward to more Zombox updates soon!

Jungle Moose released…

Posted in Zombox on November 5th, 2014 by Tyson Ibele

Jungle Moose has been officially released for iOS and Android! …Now back onto Zombox development! :)

App Store

Google Play


Posted in Press, Zombox on October 8th, 2014 by Tyson Ibele

Ok, it’s here….the full update to what’s been happening with Zombox….

Near the beginning of this year I was feeling very burned out on Zombox. As a pure hobby project that I can only work on in my limited free time, it was still far from complete even after years of development. The thought of being an indie game developer for several years and having zero finished games was depressing. I felt I needed a break from Zombox — but not from game development in general…

I decided that I needed to pause Zombox development and create a different game with a much smaller scope. One that would give me valuable app store experience, Android device experience, user acquisition/management experience, and the gratification that comes with finally pushing out a finished, polished product.

This was around the time that Flappy Bird was in the spotlight, and it inspired me to try and come up with a super simple concept that would be fun, challenging, and ideal for mobile devices. It’s not easy to come up with an engaging, original concept that fulfills those goals, but then I had a dream one night about a hippo wearing moose antlers and a lightbulb flicked on in my head.

So, to make a long story short, I’ve spent the last few months creating a game called Jungle Moose. It’s about a hippo with an identity crisis who wants to cross a river full of piranhas.

It has no crafting, or zombies, or procedurally generated content. It’s just a simple, challenging, addictive game meant for casual mobile users who want some quick, hilarious fun. It has a wonderful music score by James Watkins (my composer for Zombox as well), and it has my signature over-the-top violence and gore, while maintaining a pleasing, whimsical aesthetic. I’m quite happy with how it’s turned out, and it’s completely finished at this point — just sitting in the App Store review queue. We’ll have to wait and see what Apple thinks of the blood and gore that is generated when the piranhas attack, but that can all be easily toned down for iOS if they decide it’s too intense. Regardless, it’s a finished product that will be released very soon for free on both Apple and Android, and it’s exactly what I needed to do in order to revitalize my energy for Zombox.

So….that’s it. It’s been all quiet on the Zombox front for the last few months because I was busy mud-wrestling with a cute, blue hippo. Once Jungle Moose is approved for the app store and released, it’ll be full steam ahead again on Zombox. I can’t wait to get back into it!

Thanks to those who continue to support Zombox and my game-developing efforts. Below are some video clips from Jungle Moose. The Jungle Moose website is still under construction (it’s just a simple landing page and it might not scale properly in certain browsers), but you can check it for updates if you want to find out when the game is released. I also re-designed my own website, which will now function as the main hub for all of my active projects.

Here’s a semi-outdated gameplay teaser (some of the menus were re-designed since this was posted):

There are lots of different unlockable game modes (hats) to choose from. Each one changes gameplay in a unique way. Click to play the video (no sound).

For example, the baby moose hat requires a lot more precision to kill fish, making the game much more difficult. Click to play the video (with sound).

With the magnet hat, explosive depth charges get pulled up to the surface. Accidentally swipe over one and it’ll explode! Click to play the video (with sound).

With the turret hat, instead of bouncing fish off your antlers you have to toss them in front of an automated machine gun. Click to play the video (with sound).

Here’s a clip of an unlockable boss fight. Click to play the video (with sound).

That’s all! Once Jungle Moose is released, look forward to more Zombox updates soon after!

Crafting stations…

Posted in Items, Zombox on February 26th, 2014 by Tyson Ibele

Here’s a teaser of some of the new crafting stations you’ll be able to build in Zombox. After you build or upgrade each one, you’ll be able to craft many new items.

Can you guess what some of these will be used for?

Items on the ground…

Posted in Items, Zombox on February 21st, 2014 by Tyson Ibele

So, since the inception of Zombox 3 years ago I’ve wanted to make it possible for items to lie on the ground, outside of any particular container they could be stored in. This is a standard element of many RPGs like Diablo, Torchlight, Minecraft, etc.

The reason that this was never possible in Zombox (up until now) is due to the sheer number of resources required to have an implementation of this idea work. If the actual item geometry is to be displayed on the ground, that’s a lot of extra polygons that an iOS device just wouldn’t be able to handle. If a graphical representation of the item is to be displayed (like, its GUI icon), it would require a lot of draw calls to display each and every icon that is dropped…and every draw call is another hit on the GPU, which would quickly slow the game to a crawl. Batching wouldn’t work on those icons unless they were using a texture atlas, and updating UV/vert lists on a mesh to match icon/world coordinates would be slow.

But then I realized that I could use a particle system to do all of this quickly, and in only 1 draw call. The solution is a bit of a hack that requires “freezing” particles at particular frames on a texture. To elaborate, Unity allows you to tell a particle system to cycle through cells on a texture sheet. This is how animated particles are created — you create a texture sheet with a grid of cells, each containing a different frame of animation. Then you tell Unity’s particle system to cycle through the cells at a given rate, which results in an animated particle texture.

Well, if I create a texture sheet that contains all of my icon textures, and then tell a particle system to advance to a particular cell of that texture sheet and freeze there, I am able to achieve the effect of individual sub-textures of a texture sheet displaying properly on individual particles. Once that’s done, the rest is easy.

So…as a result of this new system, several new things in Zombox are possible:

  • items can be dropped or picked up, anywhere in the game world
  • objects that contain items drop their items on the ground when they are destroyed. The dropped items will be degraded in the process, though
  • when a player approaches an item on the ground, the item will hover around the player, alerting the player that they can examine the item
  • zombies and npcs will now drop their items/weapons when they die. Thus, their items/weapons can be retrieved by the player following their death

Click here to see a scaled-down image of the particle texture sheet I created, which stores all item icons within it. This is the texture that the particle system which displays all dropped items references.

Here are some animations showing various player interactions with dropped items:




Always backup your data…

Posted in AI, Press, Zombox on January 25th, 2014 by Tyson Ibele

Some of you might remember the story from a couple of years ago where the creators of Project Zomboid had their laptops stolen, causing a major setback in the game’s development at the time.

Well, yesterday the house I live in was burglarized and (among many other things) 2 of my laptops and my main iOS development testing phone were stolen. I haven’t lost any Zombox code because it’s all backed up off-site…but losing the devices (especially the iPhone 4S) still stings. Had I not been careful to keep the game code backup up elsewhere, the ending to this story might have been much worse.

So this is a reminder to everyone: keep your data backed up off-site!

In other news, I’ve transitioned over to using UnityVS as my IDE instead of relying solely on Notepad++ to write code and in the process I’ve converted all Zombox code to C#. So…no more JavaScript! Compile time is now faster, code is cleaner, etc…having worked with it enough I now much prefer C# over JS.

I hope to have some more substantial Zombox updates to post soon…currently working on fixing some annoying AI bugs that are proving very difficult to solve, so I don’t have much to show for that yet.

AI update…

Posted in AI, Characters, Zombox on December 27th, 2013 by Tyson Ibele

So now that the old navgrid pathfinding system has been replaced by the new navmesh system, I’ve gone in and re-written all of the AI code for npcs and zombies.

The old code was messy and relied on too many navgrid functions to simply adapt to the new system, so I started fresh. I’ve now unified all AI-related aspects of the zombies and NPCs (rather than have separate AI code for each), and optimized things like the flocking system and Line-of-Sight checking (using kd-trees and BVH trees, respectively). This allows the game to run faster with more zombies on screen at once.

While the iOS version of the game will typically have around 50 zombies visible at a time max, I benchmarked the new code with 650 zombies at once and it still runs at +30fps. Keep in mind the old code could handle around 200-250 before getting too laggy. So it’s quite an improvement!

Here’s an animated gif showing part of a group of 500 zombies crowing around the player/environment, using the new AI system (keep in mind for illustration purposes, their attacks have been disabled):