Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.
A quick look at the tools and technologies in use at Axham Games.
Cross posted from the Axham Games Blog: http://axhamgames.com/tech-stack-at-axham-games/
image by zzubnik 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 GamesWe 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. |
Three Approaches
|
Ogre3D - Rendering Engine
|
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, EverywhereYes, 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 ScriptingLua 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 WindowsSince 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)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 - Build SystemScons. 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 WikiWe 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 SystemsFor 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. |
Bonus - Art PipelineIf 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, AnimationNeed 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, TexturingYes, 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 DrawingI 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. |
Read more about:
Featured BlogsAbout the Author(s)
You May Also Like