When we first began developing Master of the Seven Teas, we were programming using the C# language and the Microsoft tool set called XNA.  This allowed us to build the initial version for the Xbox 360.  But with the announcement that XNA had not only received its final update, but would be completely “phased out” by April 2014, we need an alternate solution.

Fortunately for us, we had the art assets, the fluid algorithm, and we had built this game before – so we jumped onto familiar ground, using Adobe AIR.  If we needed anything with a little more oomph then we could utilise ANEs (Adobe Native Extensions), like with our fluid system.  A few months into development and things seemed to be going well.  We had targeted a robust 3D engine that made use of GPU accelerated visuals, we had an ANE based physics engine and our fluid system (also an ANE) was implemented.
But it was at this point that we began to notice some frame rate drops.  We hadn’t even begun to add AI, UI or really any significant features of the game – but once we had both the fluid solver (that forms all the fancy ripples) and the shaders that make it look like water (reflection, refraction, specular etc), the frame rate became unplayable.  We were simply trying to push too much through the OUYAs little GPU.

After some substantial investigation, we found that part of the issue could be solved through shared memory.  You see, the fluid is calculated on the (or rather, one of the) CPU, and the change in the surface is then uploaded to the GPU.  The process of uploading the vertices every frame is incredibly costly – hence the desire to use shared memory.  This way, our CPU would lock the memory, move the ripples and unlock it, so that the GPU could lock it, draw it and unlock it.
This whole process is not possible in AIR.

This meant we needed another solution.

We looked around at the latest offerings, investigating CryTek’s “Cryengine” – as there was soon to be an Android supporting exporter, but it isn’t available yet, so we needed something else.  Epic’s Unreal Engine 4 entered a new pricing model and while the tools, code, tutorials and community are currently the best, the engines next-gen capabilities rendered the poor OUYA somewhat lame, and was also not a viable option.

Towards the end of the week long investigation, we dabbled with Havok’s Project Anarchy.  After an initial learning curve, the whole team decided to adopt this fantastic product – which includes many industry standard tools such as Havok Physics, AI and Character Animation, along with their fully cross platform renderer, the Vision engine.  Throw in other tools like the Fmod audio engine and Autodesk’s Scaleform – and the fantastic performance on the OUYA, with all of these systems running at once, we had a winner!

There are a number of changes we’ll have to make to all our code, porting over to C++.  And something similar will need to be done with all our artwork, using the Project Anarchy pipelines.  But this move will allow us to better focus on the game and bring an experience to all the platforms we wanted… and hopefully, a few more!