- \n
- weapons now have durability<\/li>\n
- individual items can now have perks<\/li>\n
- the ailment system (hunger, fatigue, bloodloss) was completely redone.<\/li>\n
- new shaders on everything allow for more precise damage decals<\/li>\n<\/ul>\n
Back-end changes:<\/strong><\/p>\n
- \n
- item import system re-written<\/li>\n
- character controller re-written<\/li>\n
- vehicle management system re-written<\/li>\n
- navgrid pathfinding replaced with navmesh pathfinding<\/li>\n<\/ul>\n
Click any of the following images for previews of some of these changes, or click ‘Read More’ below to see all of the explanations in the full post.<\/p>\n
![\"\"](\"http:\/\/www.zombox.net\/stuff\/zombox_cap_112.jpg\")
<\/a> ![\"\"](\"http:\/\/www.zombox.net\/stuff\/zombox_cap_113.jpg\")
<\/a><\/p>\n![\"\"](\"http:\/\/www.zombox.net\/stuff\/zombox_cap_114.jpg\")
<\/a> ![\"\"](\"http:\/\/www.zombox.net\/stuff\/zombox_cap_115.jpg\")
<\/a><\/p>\n![\"\"](\"http:\/\/www.zombox.net\/stuff\/zombox_cap_116.jpg\")
<\/a> ![\"\"](\"http:\/\/www.zombox.net\/stuff\/zombox_cap_118.jpg\")
<\/a><\/p>\n![\"\"](\"http:\/\/www.zombox.net\/stuff\/zombox_cap_119.jpg\")
<\/a><\/p>\n<\/p>\n
Weapons now have durability:<\/strong><\/p>\n
So each weapon in the game now has a durability value. Different weapons also have different durability tolerances (better weapons take longer to degrade). When a weapon’s durability is depleted, it ‘breaks’ and is downgraded to a lower level. So, for example, a ‘new axe’ might degrade to a ‘chipped axe’, which then could degrade further into a ‘broken axe’, etc. At each degradation level, the item’s stats are reduced. Eventually repair stations will exist where you can fix your broken items.<\/p>\n
Also, items that have durability cannot be stacked on top of each other in the player inventory.<\/p>\n
Here is an animated gif showing what happens when an item you are using degrades. As you can see, its icon ‘shatters’, revealing the degraded icon underneath.<\/p>\n
<\/a><\/p>\nIndividual items can now have perks:<\/strong><\/p>\n
Combining two identical items will now result in a final item which contains a new perk. Perks can take many forms, and many different types of items can get them (not just weapons). So, for example, a piece of clothing might get a defense boost, or a weapon might get a damage boost, etc. When you combine two items that don’t already contain a perk, the new perk will be chosen at random.<\/p>\n
Items that are eligible for perks can get a maximum of two perks. Combining two items that each already have a perk, will result in a final item that contains both perks.<\/p>\n
Here’s an image showing where perks are displayed in the inventory panel:<\/p>\n
<\/a><\/p>\nThe ailment system was completely redone:<\/strong><\/p>\n
So previously, character ailments (hunger, fatigue, bloodloss) were displayed on-screen in little speech bubbles (here’s a link<\/a> to the old post which first described them). Aside from the fact that their original design was rather ugly, they weren’t very helpful because until they popped up you’d have no idea how hungry\/tired\/injured your character was….so unless you kept track of the last time you ate\/slept\/healed, you’d have no way of figuring out whether your character was close to needing any of those things.<\/p>\n
That’s not even mentioning the fact that eventually I wanted to make it so the character could get poisoned, or could suffer from radiation sickness while traveling close to the giant meteor in the center of the city…yet there was no room for any more of those ailment speech bubbles!<\/p>\n
So I re-arranged some of the on-screen icons and replaced the old ailment system entirely. Here’s how they look now (although this is just for illustration purposes…they won’t all appear on screen at the same time during gameplay):<\/p>\n
![\"\"](\"http:\/\/www.zombox.net\/stuff\/zombox_111med.jpg\")
<\/a><\/p>\nNow instead of the three previous ailments, there are 5 in total. Hunger, fatigue, bloodloss, poison, and radioactivity. Also, the hunger and fatigue bubbles are always visible so you can keep track of your food\/sleep levels at all times.<\/p>\n
Each ailment has various levels of danger, and if you wait too long to sleep\/eat\/heal (depending on the ailment), you could die from them. Here’s an animated gif showing the character entering toxic water and getting poisoned:<\/p>\n
<\/a><\/p>\nAlso, as with the original ailment system, if you eat\/heal\/sleep more than necessary, you’ll get an ailment ‘bonus’ of either a damage, defense or XP boost. Here’s an example showing the player activating the damage bonus by eating food. Notice that the duration of the bonus is proportionate to the amount of food eaten, and it can only be activated while the player is at full health.<\/p>\n
<\/a><\/p>\nNew shaders improve damage decals:<\/strong><\/p>\n
So before this last update, I didn’t really know anything about shader languages. I had modified some shaders before but didn’t really understand what I was doing (cg shaders have a structure that can be tricky to understand).<\/p>\n
Because of this, I didn’t realize how powerful they could be. For example, previously, when a zombie is hit with a weapon, it gets blood splatters all over its body. This was accomplished by swapping the zombie’s normal texture out with a bloody texture….and because there are various levels of blood that a zombie can be covered in, I was constantly swapping in\/out multiple textures in order to achieve this. It was a clunky, horrible solution…but it worked.<\/p>\n
Well, now I realized that was all a waste because I can use shaders to achieve the same effect using only one texture map! What I do now is the following:<\/p>\n
- \n
- store a grunge map in the alpha channel of the zombie texture map<\/li>\n
- when a zombie is damaged, set the vertex colors of its mesh to a linearly interpolated value between 0-255 based on the amount of damage done<\/li>\n
- the zombie shader then uses the vertex color channel to decide how much of the alpha channel grunge map to clip into the main texture<\/li>\n
- the resulting grunge is then hue-shifted to red<\/li>\n<\/ul>\n
The result is a very nice smooth transition in the zombie texture from normal to fully bloodied that doesn’t require any extra texture maps….and even more importantly: can still be batched because it doesn’t require multiple materials either!<\/p>\n
Here is an animated gif showing the effect on a zombie:<\/p>\n
<\/a><\/p>\nAnd as a further bonus of this new system, I implemented it into all of the inanimate objects in the world too! So damaged props will now get covered in cracks and marks before finally being destroyed! Here’s an animated gif showing that effect:<\/p>\n
![\"\"](\"http:\/\/www.zombox.net\/stuff\/zombox_cap_117.jpg\")
<\/a><\/p>\nItem import system re-written:<\/strong><\/p>\n
So when I was implementing item durability, I realized that my old item system was horribly unmanageable and archaic. It was also very difficult to easily update or even understand. As an example, it was similar to the following:<\/p>\n
items.add(new bluntWeapon(\"hammer\", 20, 1.2, 40, 45, 2, 0, 0, 13, \"hammer_attack_animation\");<\/code><\/p>\nThis is similar to how items could be ‘added’ to the game in the old system. Notice the long list of numerical arguments? What do any of those mean? Good question…if I wanted to find out, I’d have to go find the ‘bluntWeapon’ constructor and figure out which argument corresponded to which item property (so, for example, ’40’ might be the damage, ’13’ might be the cost, etc).<\/p>\n
Now imagine hundreds of declarations like that, all corresponding to constructors with different arguments. Ugh!!<\/p>\n
So I re-wrote every single aspect of the item system, so that it’s now much more organized, and it’s able to import items from a standard spreadsheet! So now I define everything nice and cleanly inside a google spreadsheet document (no more guessing about which value means what…all values now sit in neatly labeled columns), export it to a text file and everything is auto-imported into the right place. Due to the way in which I import things, memory usage is also cut down.<\/p>\n
This new system will greatly speed up how long it takes to add new items to the game — especially craftable items (many of which still need to be added…but that’s for a future update).<\/p>\n
Character controller re-written:<\/strong><\/p>\n
Similar to the old item system, this was another part of the game that had been nagging me for a very long time. The previous character controller had existed in its current state pretty much since day one…and it was extremely messy and hard to understand or modify. It was basically just a looooooong list (about 1500 lines long) of if-then clauses, defining every possible state the character could exist in and all the various combinations thereof.<\/p>\n
Now I implemented an action queue that is a dream to work with. Instead of trailing through a huge list of clauses to figure out what action needs to be performed, I just pop that particular action to the top of a queue that is processed each frame, and the character responds accordingly.<\/p>\n
Vehicle management system re-written:<\/strong><\/p>\n
So as I was about to finish the new city generation system (it’s now done….woohoo!), I realized that my old vehicle management system was needing an upgrade. In the old system, vehicles just existed in the world permanently…no matter where in the map you are standing. This is incredibly inefficient because that means the rigidbody dynamics of a vehicle that’s all the way across the map from you will still be calculated each frame. On iOS devices, this means I could only ever have a handful of vehicles on the map or else the physics requirements to keep them ‘active’ would be too high (switching them to kinematic rigidbodies when they’re far away was an option, but that itself would have its own issues).<\/p>\n
So I re-wrote the whole system and now, just like every other object in the game, they’re loaded in\/out of memory based on how far you are from them. This doesn’t mean a vehicle is ‘deleted’ from the world once you move too far away, it just means that it’s placed back in reserve pool, rather than remaining as an active rigidbody. The added benefit of this is that because they’re now treated like any other in-game prop, they don’t need all of their properties defined by a special vehicle class, they instead just extend the generic prop class. So…they’re now very easy to manage and you could, in theory, have hundreds of them scattered throughout the world without any performance hit, because they wouldn’t become ‘active’ until they’re in view.<\/p>\n
Navgrid pathfinding replaced with navmesh pathfinding:<\/strong><\/p>\n
This has been the biggest change made to the game, and is what I’ve been working on for the past month.<\/p>\n
Basically, as time has progressed in development of Zombox I’ve slowly come to accept the fact that my navgrid pathfinding system simply won’t ever work the way I want it to. This is not due to any bugs, but instead due to the limitations of navgrid systems.<\/p>\n
The navgrid system works like this:<\/p>\n
- \n
- the world is divided up into a grid of small cells<\/li>\n
- cells are marked as ‘blocked’ when in-game obstacles cover them<\/li>\n
- paths for zombies and NPCs are then generated by traversing unblocked grid cells using the A* search algorithm<\/li>\n<\/ul>\n
In simple cases, this works just fine. But in complex places it can cause several problems. The biggest problems are:<\/p>\n
- \n
- In order to properly correspond to small in-game obstacles, the grid itself needs to be small. This can take up a lot of RAM. For example, Zombox’s procedural world is separated into tiles, 126 of which span the width and height of the map. Each of those tiles is then subdivided into 16×16 navgrid cells. Combined, that is over 4 million total navgrid cells required to create the entire navgrid. Each cell must contain a certain amount of information in order to describe its state (number of obstacles covering it, type of obstacles covering it, etc). I eventually decided to use 16-bit integers to contain this data, because 8-bit integers were too small and 32-bit integers were too big. Even with this limited data type, the total RAM requirement for the navgrid alone was almost 10 mb…a considerable amount on mobile devices.<\/li>\n
- Because the granularity of the grid can only be so small, I would often run into cases where paths would not form in areas that ‘seem’ open, but area really deactivated due to nearby obstacles overlapping parts of the grid cells. I originally considered this only a minor problem but eventually found there are lots of cases where it is a bigger problem. For example, exploiting this issue makes it easy to ‘trick’ agents (zombies or NPCs) into thinking they cannot traverse an area that is actually wide open.<\/li>\n
- A square grid works great for axis-aligned square objects, but it does not work well with obstacles positioned diagonally…and since vehicles can spin 360 degrees, you run into lots of cases where the navgrid cannot properly correspond to the vehicle obstacles.<\/li>\n<\/ul>\n
So…after all of this, I finally conceded defeat and switched to navmesh pathfinding. Navmesh pathfinding is different in that instead of using a static grid to define walkable areas for your AI, you use a virtual mesh of triangles to define walkable areas. Because the mesh can take any shape, you can effectively describe walkable\/blocked areas with perfect accuracy (rather than trying to find workarounds to the accurage problems of a navgrid).<\/p>\n
The caveat to navmesh pathfinding is that generating a procedural navmesh can be very slow. Thankfully, since the Zombox world is already segmented into thousands of individual tiles, I just use those to define areas for the navmesh system to generate navmeshes and connect them together afterwards. I also pool navmeshes in\/out of memory based on their distance from the player in order to conserve RAM (there’s no point in calculating paths for AI that are far off-screen).<\/p>\n
My final implemenation uses a couple of external libraries, requires no new memory allocations per frame (once the necessary data buffers spin up) and runs wonderfully on my iPhone 4S. So…success!!<\/p>\n
Here’s an outline of how it works, for those interested:<\/p>\n
- \n
- Wherever a character is located in the world, navmeshes are generated on nearby tiles in an outward spiral from the character location.<\/li>\n
- Navmeshes are generated by first collecting nearby obstacles and defining a convex polygon around their perimeter.<\/li>\n
- A walkable convex polygon is also defined around the current active tile<\/li>\n
- Using the Clipper<\/a> library, the obstacle polygons are subtracted from the walkable polygon<\/li>\n
- The resulting hole-containing polygon is then triangulated using the poly2tri<\/a> library<\/li>\n
- The resulting triangles are then fed into the current navmesh<\/li>\n
- The final list of triangles is processed along with all neighboring navmesh triangle lists to find edge neighbors<\/li>\n
- Once activated, the navmeshes can take pathfinding requests from nearby agents<\/li>\n
- Paths are determined by walking through edges to neighbor triangles until the goal is reached, using A* as the pathfinding algorithm<\/li>\n
- Once a path is found, it is string-pulled using this algorithm<\/a> to smooth it out<\/li>\n<\/ul>\n
Coroutines are used to generate the navmeshes so that they don’t require too much time per frame on mobile devices, and because navmeshes requires less nodes to be traversed during the path search than navgrids, they perform quite fast. On my iPhone 4S, each step of the navmesh generation process usually only take 1-2 ms, and finding an individual path takes only about 0.15 ms. Can’t complain about that performance!<\/p>\n
Also in the process of working with all those external libraries, I learned C# and can now comfortably code in it. It’s not much different than Javascript but it compiles much faster in Unity and it has a number of other benefits so it’s definitely a good language to know.<\/p>\n
Here’s an animated gif showing how the navmeshes are generated as the character moves through the world:<\/p>\n
- The resulting hole-containing polygon is then triangulated using the poly2tri<\/a> library<\/li>\n
![\"\"](\"http:\/\/www.zombox.net\/stuff\/zombox_cap_112.gif\")
<\/a>![\"\"](\"http:\/\/www.zombox.net\/stuff\/zombox_cap_113.gif\")
<\/a><\/p>\n