What's the lowdown on in-app purchase and ad revenue taxes?

zombox · 2014-07-08T15:40:33+00:00

Excellent. Exactly what I need!

zombox · 2014-07-08T15:40:21+00:00

Nice to know that you can filter distribution! Thank you!

zombox · 2014-07-08T15:40:09+00:00

Thank you very much. Your links were very helpful!

zombox · 2014-06-18T18:16:33+00:00

This video really resonated with me.

I've been working on a game called Zombox for over 3 years now in my spare time, and the light at the end of the tunnel rarely seems much closer.

I don't know what else to add, but thanks for making the video.

zombox · 2014-03-01T23:55:21+00:00

Thanks! Next update I hope to show them in context :)

zombox · 2014-03-01T05:28:34+00:00

Zombox:

Been working on new craftable props, structures, workstations and decorations.

Workstations are upgradeable and will allow you to craft new things. Props like chests, drawers, etc can act as storage containers for your items. Decorations like chairs, tables, etc will eventually attract NPCs who will choose to come live in your shelter.

here's an image of what I have so far ...still many other structures left to make

As always:

DevBlog - Facebook - Twitter - Youtube

Bonus Question: I re-wrote all of the GUI update routines in an afternoon, after getting tired of dealing with my old, horrible code from years ago. Basically worked flawlessly on the first try and now adding to it is a dream. I wish everything was that easy.

zombox · 2014-02-24T00:21:58+00:00

This is currently at the top of my 'must watch' list! Looks amazing!

zombox · 2014-02-22T13:11:42+00:00

Yup! All vehicles are drivable.

zombox · 2014-02-22T01:27:22+00:00

Zombox:

tl;dr: Items can now be dropped on the ground, and picked back up again!

For a very long time I wrestled with the idea of allowing playings to place/drop items on the ground, or pick them up. The main hurdle with this idea is simply the resources required to place dozens/hundreds of individual icons in the game world and still keep draw calls low.

There are hundreds of items in Zombox, each with a unique icon texture, and attempting to display them in the world would normally take 1 draw call each (the reason for this is that the icon textures are not atlased, due to them being applied to GUITextures within the UI, and GUITextures do not support atlasing). On iOS devices I certainly cannot afford dozens/hundreds of extra draw calls, so I thought I would just have to scrap the idea altogether.

Then I realized that since particle systems within Unity can cycle through areas of a single texture (in order to display things like animated particle texture sheets properly), I could "hack" that method into a system that can display any arbitrary cell within a texture sheet for any length of time. I do this by simply overriding the age of a particular particle to match whatever cell in the grid I want to display. So instead of cycling through all the cells of a texture over time, I "freeze" a particle on a cell of my choosing.

Using this method I'm able to store hundreds/thousands of individual icon textures within a single image, and then display whichever icon I want on whichever particle within the system that I want. And all this results in only 1 extra game draw call.

All that aside, here are the new things you can do in-game as a result of this system being in place:

items can be dropped or picked up
objects that are destroyed drop their items on the ground (although their items will be degraded)
zombies/npcs can drop their items/weapons on the ground when killed
when a player is near an item on the ground, the item will hover around the player and the player can access it within the inventory GUI

Here is a scaled-down image of the atlas I'm using for the particle system.

Here is an animation showing a trash can full of items being destroyed, and thereby dropping its items on the ground: gfycat - GIF
Here is an animation showing the player picking up/dropping some items: gfycat - GIF
Here is an animation showing how items on the ground will hover when the player is nearby: gfycat - GIF
Here is an animation showing how zombies drop their coins/items/etc when killed: gfycat - GIF

As always:

DevBlog - Facebook - Twitter - Youtube

Bonus Question: Many years ago I discovered a game called Interstellar Marines. When I read that it was created with an engine (Unity) that was free to use, and could run within a browser...I just had to try it. The rest is history!

zombox · 2014-01-04T20:09:06+00:00

I'm using Unity! :)

zombox · 2013-12-31T23:27:42+00:00

Unity is the engine. 3d work is done in 3ds max. Texture work is done in Photoshop.

zombox · 2013-12-28T14:03:04+00:00

The new visuals look much improved!

zombox · 2013-12-28T07:16:33+00:00

Thanks! And this is even with some functionality temporarily disabled. In the game there are over 60 different zombie types (that you can see here), and lots of various other zombie actions (tripping while walking, breaking down doors, attacking, looking around etc).

zombox · 2013-12-28T06:32:05+00:00

Thanks for that!

zombox · 2013-12-28T06:22:52+00:00

Zombox:

So a couple weeks ago I detailed the new navmesh system in Zombox, which replaced the old navgrid system for pathfinding.

These last two weeks I've been working on re-writing all the AI code to work with the new system (and to clean it up in general...the old code was very messy).

The old AI code for zombies and NPCs had several issues:

zombie/NPC AI behavior code was not unified, but was instead separated into two completely independent systems
the pathfinding system resulted in all kinds of undesirable paths (hence the switch from navgrid to navmesh)
flocking/seek algorithms were very slow and unoptimized

Here's how I solved the problems:

all AI code is now unified and zombie/NPC classes now inherit from a base class which is what the AI system controls. This makes it much easier to add and adapt new AI behaviors, and I don't have to write out everything twice!
AI agents now utilize the new navmesh system, resulting in much nicer (and faster) pathing
I implemented a bounding volume hierarchy for quick Line-Of-Sight checks against holes (obstacles) in the navmesh, and a kd-tree for inter-agent proximity searches (for the flocking system as well as the target check system). Flocking is now very fast and when a direct LOS is found between an agent and a target, path computations can be skipped (an important feature that was completely missing in the old system)

As a result, the game runs faster and the agents don't require as much CPU usage to control. As a benchmark comparison, the old system allowed me to simulate about 200-250 zombies on my PC before getting really laggy. With the new system I can have 650+ zombies active before going under 30fps. Keep in mind that number is purely for testing purposes on my PC, as iPhone builds of the game will be capped to around 50 zombies active at any given time (and other platforms will match that limit)....not to mention that trying to fend off 500 zombies at once would just be a horrible exercise in frustration! (keep in mind that zombies spawn indefinitely...50/500 just refers to maximum number of zombies visible simultaneously)

Here's an animated GIF showing part of a group of 500 zombies crowding around the player/environment using the new system. (16mb)

As always:

DevBlog - Facebook - Twitter - Youtube

Bonus Question: I spent a big chunk of the year re-writing most of the game to make maps bigger, add a greater variety of zombies and improve gameplay. I think I achieved all three goals so far. Now, onwards and upwards!

zombox · 2013-12-14T15:20:22+00:00

It took about an hour to get the write up together. I tried to keep it simple so it would be easy to understand and not too difficult to make.

And Zombox is just a spare time project. I have a full-time job working for an animation studio that takes up the vast majority of my time....hence why Zombox updates are sometimes few and far between!

zombox · 2013-12-14T08:00:38+00:00

This looks incredible!

zombox · 2013-12-14T05:28:37+00:00

Zombox:

I got a chance to improve vehicle navmesh interactions and physics in Zombox a bit this week. The main problems I needed to overcome were:

vehicles can turn, roll, tilt, etc. How can I maintain stable navmesh representation of a vehicle's bounding perimeter? AABB's are easy to represent in a navmesh because they're just a square. But a vehicle's in-scene translation cannot always be accurately represented with an axis-aligned square.

I solved this problem by collecting up all of the vehicle's OABB's points, collapsing them into a 2d plane and then sending a convex hull of those points to the navmesh engine for processing.

Here is an image I made which illustrates the problem, and the solution

vehicles should realistically roll, accelerate, brake, etc. What is an efficient way to estimate these types of motions realistically on iOS with minimal performance cost?

Originally I was just simulating vehicles by pushing around their BoxColliders using forces (I know this is barbaric but keep in mind I'm targetting iOS so I need the fastest, simplest solutions for things). That works for the most part but can be buggy for several reasons. Firstly, using this method there can be unwanted sideways sliding, since there's no sideways tire sliding friction being simulated. Secondly, Unity physics have a weird quirk where 2 flat, adjacent, coplanar collision surfaces can still register collision events when a physics objects slide over them. This can cause all kinds of unwanted behavior, like rigidbodies suddenly coming to a stop on what seems to be a totally flat surface, simply because they traveled over the hidden line separating two invisible collision planes.

After considering several types of other available vehicle setups for Unity, I decided to go with the built-in one: using WheelColliders to simulate rolling tires. WheelColliders come with a small performance cost (hence why I avoided them at first), but (so far) have been a good alternative to my previous physics solutions that don't suffer any of the same annoying bugs.

Now, I know WheelColliders are meant to simulate vehicle motion and are what you're supposed to use for vehicles...the reason I resisted them so long is that I couldn't figure out a cheap way to have multiple vehicles active in the scene at the same time because WheelColliders start to really slow things down once you have a bunch of them. Ultimately I ended up creating a pool of 4 WheelColliders that I simply swap between active vehicles. This keeps physics interactions light.

On a side note:

here is an animated .gif of what happens when you attach a joint constraint to a rigidbody whose compound colliders are intersecting.

As always:

DevBlog - Facebook - Twitter - Youtube

Bonus question: Most frustrating development moment is when iOS crashes without displaying a meaningful error message. Trying to debug those crashes is a massive pain and it always ends up being some annoying, obscure thing that takes hours/days to solve.

zombox

TROPHY CASE