Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Tech Stack at Axham Games
by Vijay Varadan on 07/09/13 03:27:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Cross posted from the Axham Games Bloghttp://axhamgames.com/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.

 

Cross Platform Games

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.

Three Approaches

Three Approaches
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.

Ogre3D - Rendering Engine

Ogre 3DPython-Ogre
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. :-D
Once 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.

Crazy Eddie's GUI (CEGUI)

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.

Python - Scripting Every Time, Everywhere

PythonYes, 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 - In-Game Scripting

LuaLua 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.

MinGW - Minimalist GNU For Windows

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 - Distributed Version Control System (DVCS)

MercurialMercurial - 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 - Build System

SconsScons. 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.

Apache Bloodhound - Issue Tracking And Wiki

Apache BloodhoundWe 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.

Windows 7, Ubuntu 12.04 LTS - Operating Systems

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.

Bonus - Art Pipeline

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.

Blender - Modeling, Rigging, Animation

blender-iconNeed 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.

Photoshop - Concept Art, Texturing

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.

Inkscape & Illustrator - Vector Drawing

InkscapeI 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.


Related Jobs

Red 5 Studios
Red 5 Studios — Orange County, California, United States
[10.24.14]

Graphics Programmer
Red 5 Studios
Red 5 Studios — Orange County, California, United States
[10.24.14]

Gameplay Programmer
Gearbox Software
Gearbox Software — Plano, Texas, United States
[10.24.14]

Server Programmer
Forio
Forio — San Francisco, California, United States
[10.24.14]

Web Application Developer Team Lead






Comments



none
 
Comment: