All over the place this week

What got done

• Lots of bug fixes from the previous week's playtesting.  The game has gotten a lot more stable over the past week, and the playtesting results from Friday reflected that almost all of the bugs that we set out to fix were actually fixed.  This included a lot of null checks, a refactor of how network IDs are assigned to avoid collisions, changes to unit movement and more.  (12 hours)
• We actually got some models in game this week.  No textures or animations yet but the models are in!  (3 hours)
• Network testing and some bug fixing for the new way we store team information that Ryan made. (3 hours)
• GUI planning and design and some NGUI research. (1 hour)
• After the playtesting session on Friday we decided we wanted to try an implementation for resources where there would be no resource nodes to claim.  Instead your gygan automatically generates a certain amount of resources every wave (increasing linearly over time).  I implemented that and made a new map to try it out on.  (3 hours)
• Lately I've been noticing performance issues when playing the game after an extended period of time to the point where my laptop could hardly keep up.  Since we have a lot of moving units on screen all the time, entities on different teams that require different colors, and a map that is generated at runtime, I did some research to try to find a solution.  For reference, if you zoom out all the way on an average sized (200 x 100) map, you will end up with this many draw calls.

(Map with no optimizations)

First I tried static batching at runtime, which combines meshes that share the same material into one big static mesh (cannot be moved).  This helped a little bit with bringing the amount of draw calls down but the draw calls just ended up being batched instead of removed.  Batched are draw calls are good but when you get too many of them it has diminishing returns, and in order for draw calls to be batched they need to share the same material.  From here I started looking at some assets for automatically creating texture atlases so every object could use the same material.  A few seemed promising but most had workflow issues that would cause us to jump through a few hoops.  The best solution that I have found is a third party asset called Mesh Baker.  With this tool we can automatically combine meshes and materials at runtime with very little workflow changes.  Going back to the map example, here is what I got when I used Mesh Baker to combine the meshes and materials at runtime.  

(Map with Mesh Baker)

That's a huge difference, and it only took a little over a second to do that.  It sounds perfect but there are some limitations.  Meshes that have tiling UVs do not work correctly (which almost all of the placeholder environment models have), so we will have to take that into account.   Another issue we were going to run into are potentially hundreds of skinned mesh renderers (used for animated meshes) on screen at any given time.  In addition to the overhead that skinned mesh renderer produces, skinned mesh renderers cannot be batched.  So in a best case scenario, each unit/tower/gygan will be 1 draw call.  Mesh Baker has a solution to combine meshes and materials for skinned mesh renderers too, and it preserves animations.  Here's two instances of the Augher model.  Each model is 6 draw calls because no texture atlases were made.

Now here is one where they have been baked into a single skinned mesh renderer. Again, the animations still work and you can still move them as you would any other object (although I am still researching how exactly they do that).

So this looks promising and I am going to continue looking into it. (9 hours)

What's next

• Continue researching draw call optimizations
• More UI implementation for in game pause menu and map editor
• Adding some of Jonathan's particle effects to the project