Open source tooling, try it before you buy it.

Introduction
For years I have been using a lot of open source tools and libraries in non-game software development. I'm also a fan of the cooperative work style that most open source projects adopt. So when I started to research the available tools for the development of our strategy game Tenshu General I naturally included in the search what was available as open source. Since the game is now released on Desura this post is also more of a second part to another blog post I wrote about a month ago.

Tool selection process
Before I share with you what tools we chose to use for Tenshu General, I want to highlight the process I use in tool selection.

Proper tool selection for me starts with defining the selection criteria. Making a list of criteria to score tools against comes from one of my development principles: fit the tools to the job, not the other way around. It helps in determining if tools support your business model or potentially harm it by lack of support for certain platforms or distribution channels.

Finding a balance can be hard. Any tool limits the game in some way. Once you weighted the pros and cons and considered your constraints of time and budget, accept these limits and make the design work with it, it often creates innovative, fun and creative solutions. Also it keeps the game focussed.

Buy it, get it for free, or build it?
So with the list of criteria setup we were ready for the selection process. For each tool  required, there were 3 possible outcomes:

Which tools did we need?

All-round Game Building tools
Looking at the long list of tools we required, you might ask "Why we didn't go with tools like Unity, Game Maker, Unreal SDK, etc.?", which combine a lot of these tools in one nice package. In the time before we started work on Tenshu General I tried some of them out. It's not my intention to give a review of these tools in this blog post, but I'll list some of my experiences with ultimately helped in my decision not to use them.

Game Engines
With regards to game engines for Java, choices are limited, but there is enough to make great games, not AAA (yet), but enough. Game engines share similar design and there are number of books which are a helpful tool here to understand and use them:

Even though a lot of the examples in books or across different websites might be in C++, it's fairly easy to translate them into the Java world.

Finally, after some internet research I came across Slick2D which fit in terms of its simplicity, resource management, focus on 2D, customisability and integration with other libraries. Also it supported cross platform development by utilising OpenGL and OpenAL as its native platform. Since it is also open source with a license that permits modifications, where it lacked or was not exactly as required I was able to make some small modifications. Side note: Slick2D is currently in the process of moving to another development team which I'm monitoring to see how I can contribute to its continuation. In the meantime the original code base is very stable if you stay within the original simple 2D sprite based design parameters.

Game Engine: got it for free

Graphics Engines
By using Java as development language, in principle the game is a cross platform game. But to take advantage of hardware acceleration, native integration is required. In order not to lose the cross platform capability I looked at OpenGL, OpenAL and OpenCL. These technologies have been around for numerous years and are still in active development and support. To use them within a Java environment, you require a native link. Fortunately there is a great library which bridges this gap for the laptop/desktop platform called LWJGL.

The choice for a particular graphics engine will be driven by the release platforms you want to target for your game. For example if you are targeting a browser game, HTML5 is great and can be ported to mobile devices, but browser games and mobile games do not share the same business model. So just choosing HTML5 because it is multiplatform is not a good enough reason. When it comes to using OpenGL as your graphics engine, an important difference between desktop and mobile platforms is the supported standards. Mobile platforms follow the OpenGL ES specification where the desktop/laptop platform follows the full OpenGL specification. If you plan to port your game to mobile, you should limit the use of the OpenGL API to those functions also supported in the OpenGL ES specification.

Slick2D is targeted for desktop games and has out-of-the-box integration with LWJGL. For our game this was a perfect fit and gave us an option to port the game eventually to at least the Android tablets with a reasonable effort.

Graphics Engine: got it for free

AI Framework
The AI in Tenshu General is custom build, but uses various design patterns from the books mentioned earlier, as well as a simple Fuzzy Logic library called jFuzzyLogic. As far I have been able to find there are no general purpose toolboxes available yet for Java.

AI framework: build it based on design patterns

Graphics tools
Choosing a vector based graphics style for a game is fairly uncommon. The choice was driven by personal preference and therefore the tool we selected followed also a more or less personal preference. As indie developers with a limited budget, which I described in my other blog post, we chose again a free tool called InkScape with a low threshold in terms of learning how to use it. The advantage of vector based tools is that in the format in which the assets are stored can generally be programmatically parsed and therefore easily integrated in the game and graphics engine, which I will elaborate on in the next section. For all the assets that were converted into sprites, we used mainly Gimp for post processing.

Graphics tools: got it for free

Game Design tools
To enable the game design in Tenshu General four main tools were required: a map editor, a combat model editor, a movement model editor and nav mesh editor. Lead designer Joost used InkScape to prototype the maps and when I looked into the file format used by InkScape I discovered it was a well-defined XML format which I could a) render using the actual XY coordinates in the file, translating them directly into rendering calls and b) parse the 2D shapes to use in the nav mesh generation.

Through the use of layers in InkScape, we are able to separate the navigation information in the map easily from the map items layout (villages, Tenshu locations, army bases, etc.) as well as the level design elements such as starting location and starting territory for the different players. All the shapes in InkScape can be annotated to provide additional styling and game object information such as level information of the game objects and the names of sprite to use in rendering.

To model combats and balance modifiers we used spreadsheets to calculate outcomes of combats between two armies of different composition. Also we used spreadsheets to balance movement modifiers. Next to this all aspects of the game that needed to be determined at design time dynamically were put in a parameter file directly accessible to the map designer. To work with spreadsheets we used either LibreOffice or MS Excel and parameter manipulation was done using a basic text editor.

Game Design tools: got it for free

Sound tools
Given our limited requirements we were fine with using Audacity, a small tool for all the basic sound editing stuff you need.

Sound tools: got it for free

Version control
Version control for more than one person requires some kind of server based system. Maintaining this yourself is possible, but you have to account for hosting, patching etc. Given the professional services offered and our intension to have our game development as professional as possible, we opted to buy version control services from Beanstalk.

Version control: bought it

Project and task management
I followed the same line of reasoning as I did for the version control selection. Server based, low maintenance and professional without a lot of unnecessary features which just produce overhead. Our final choice was Basecamp.

Project/task management: bought it

Packaging tools
The end result for any packaged game is most of the time going to be for a very well defined platform and therefore is going to follow certain rules and best practises. There are a lot of smaller and bigger tools that help you with this process, but still I spend quite a bit of time configuring them. I wanted to have the whole build process automated and repeatable. Something that gives you much more security in the quality of your packaged game. Here is a list of tools I used:

Packaging tools: got it for free and customised it

Understanding open source
As you might have gathered from this article we have used quite a bit of open source for the development of our game. Open source is mostly just like any other product, except for the way it is produced and how you can use it. There is a lot written about open source which I will not go into here, but related to game development I'll name a couple of points I specifically pay attention to:

Conclusion

Like any trade or craft, good tools are the difference between quality products and mediocre products. The definition of what makes a good tool however depends on the job they need to do. That's why I believe spending time setting up proper selection criteria (including budget) that are based on the design goals of the game is essential to find the correct tools.

Whether you buy your tools, use free open source tools, or build them yourself depends on how good a match you can find with your selection criteria and how critical the tool is for the finished product.

Finally I hope I showed there are great tools out there which you can use and contribute to and in that way help drive innovation in the industry by sharing knowledge and spreading the effort in building tools.