Tech Stack at Axham Games

Time for some saucy tech talk. As I mentioned in one of my earlier posts, we're not quite ready to talk about the game we're working on. But that's hardly a reason to keep up the silence that been going on for so long. So, here's the first of many tech posts to come. Just to be clear, I'm interested in sharing what we do with the expectation that fellow game developers will benefit from our experiences and maybe even take the time to point out any foibles. Hopefully, this will also whet the appetites of our fans, who are, of course, legion. ;-)I'm a big believer of "horses for courses" and having some consistency to our choices. Being a small studio, it's important to pick tech and tools that can be used under varying conditions. So, you'll find that as a rule, we tend to standardize on tech that runs on multiple platforms out of the box and find equivalents where feasible. e.g. we use bash as our shell - it's natively available on Linux and OSX with MinGW bash giving us what we need on Windows. Similarly, we use Python which runs on all platforms as our scripting language and we try to pick as much Python based tech as we can e.g. our source control, build, issue tracking and wiki systems are all Python based.

We create cross-platform games at Axham Games; the rational behind going cross-platforms is financial. By being available on more platforms, we can sell more copies. At this time, our target platforms are Windows, OSX, Linux, iOS (primarily iPad) and any consoles for which we can get SDKs. You may notice that Andriod is conspicuously missing from the list. I have good reasons for that - fragmentation. I've had some questions around exclusivity demanded by console manufacturers - this is a bridge I'll cross when I come to it, probably towards the end of 2013. In principle, I strongly prefer releasing on all platforms at the same time, but I can understand the business reasons behind demanding timed exclusivity in exchange for peripheral benefits such as lowered SDK costs or defrayed marketing costs e.g. through in-platform showcasing of the game.So, the major chunks of the tech we choose need to be available across multiple platforms and where they are not, they should be replaceable with platform specific versions without too much pain.

I saw three approaches, the first would be use a game engine, such as Unity, that is available across multiple platforms and the second would be assemble a game engine using readily available libraries for the different subsystems that constitute a game engine. A third approach would be to pick a game engine, like Panda3D that worked on a limited number of platforms and port the engine to work on the remaining platforms.The first approach was ruled out when I found that my experience trying to work with Unity was less game play oriented and engineering oriented than I liked - note that this is matter of personal preference; there's no negative for Unity here, it really is just a matter of personal preference. The third approach of porting an entire game engine to multiple platforms is time consuming and the goal of the studio is to ship games, not tech. So, I went with the second approach of assembling a game engine from libraries.

This was a fairly easy decision to make once I had figured out that assembling the game engine from libraries was the way to go. It certainly helped that a very high quality, commercial game like Torchlight [official site] has successfully used it at the time of making the decisions. This has further been enforced by seeing that Torchlight II [official site] continued to use Ogre 3D for rendering.Ogre is written in C++ and there are a number of more rapid development platform choices such as Python via python-ogre available which was just gravy. Yes, there's a .NET version as well called MOgre, but really, when you have Python, why care about anything else. :-DOnce this major choice was made, other parts of the stack would be restricted to being able to integrate with Ogre, with varying amounts of work needed to make them work well.

The natural choice. CEGUI is mature and works very well. Significant improvements made it easier and more modular for use as of version 0.7.

Yes, its the snake that wins. Every time, everywhere. We do all our prototyping with it including server side stuff for multi-player. A large number of our tools are chosen coz they're written in Python which automagically makes them 100% better than their competition.

Lua for in-game scripting. Why not Python? Easy. All games today are multi-threaded. Python (at least the C implementation) suffers from the infamous GIL limitation which restricts the number of threads simultaneously executing Python code to one. In fact, we're looking into using Lua as the embedded scripting language within our game engine based on python-ogre. Why? Our prototype is used for more than testing out game play and mechanics. We also use it as a proving ground for tech. Embedding Lua into our prototype engine will give us a sense for what it will be like when embedding it in our production game engine which will use Ogre3D as the rendering tech and will, naturally, be in C++. If you're curious, it looks like we'll use Lupa, which is a rewrite of Lunatic Python.

Since we make cross platform games, MinGW is what we use when we're on Windows. We'll dip into Visual C++ if needed, but I'll address that later in the year, once we're in production. That'll also be the time that I figure out whether it's worth it to use Direct3D rendering on Windows, while using OpenGL on the non-Microsoft platforms.

Mercurial - is there anything else out there? Yes, there is, git. But Mercurial has lower administrative overhead and is written in our favorite language - Python. Yes, we'll all about Python at the studio.

Scons. It's in Python. If it's good enough for id Software (yes, I'm a fanboi), it's good enough for us. And again, it's in Python. Did I mention, it's all Python? Just in case I forgot, it's written in Python.

We used to use Trac - it's great, but Apache Bloodhound (based on Trac) comes along and provides support for multiple projects (they call it products in Bloodhound) out of the box. So, last month we migrated from vanilla Trac with a bunch of plugins to using Apache Bloodhound. It helps that it's an Apache initiative. We like it so far. So much so, that I've created multiple instances for each "department" e.g. operations, marketing, product development knowledge base, prototyping, etc. each have their own Bloodhound instance with separate "products" that have wiki articles and tickets partitioned by products. And it's written in, yes, you guessed it - Python FTW.

For now in the pre-production stage, we do all of our development in Windows - essentially Windows 7. We haven't made the move to Windows 8 yet and while our games will run on Windows 8, it's not the primary Microsoft platform for us at this time. The main reason for being on Windows and not on Ubuntu 12.04 LTS is that the time and effort required to get python-ogre working on Linux was way too high - so, we decided to use it on a platform on which it seemed to work out of the box and deal with getting it to work on Ubuntu later... much later.It's likely that once we get to the production stage when we'll be programming primarily in C++, we'll move over to Ubuntu. Not sure about that right now, but that's the direction I'm leaning towards.We'll have to get some OSX machines in at some point of time in the near future. Probably early in the new year (2014). It's less urgent for us, since we're developing with iOS in mind and ensuring that all controls feel natural for touch interfaces.

If you made it this far, you deserve a prize, sort of. So, more information for you. This isn't tech, but the tools we use on the art side. This is a sort of preview and it's likely to expand as we get more into the pre-production and move into production. But it's what we use at this time.

Need I say more? Depending on what the artists feel, we may throw Z-brush into the mix for sculpting. That'll get decided in about 3 months. Blender's doing the job very well so far. Again, it helps that Python is the scripting interface to Blender.

Yes, we use the big bad boy for concept art and texturing. It was great while we could buy boxed versions of the software, but with the subscription model kicking in, it's even better for a small studio like ours. Less capital expense and costs spread over a period of time.

I like Inkscape and some others at the studio like Illustrator. I just got used to Inkscape when I couldn't find my copy of Illustrator CS5. Now I find it hard to go back to Illustrator. There's not a lot of vector stuff we do, so this is rather low use.