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 or learn how to Submit Your Own Blog Post
Ever wondered if games use open source software? In this blog post I talk about how open source has been a useful basis and addition to our development toolbox and how I approach in general the tool selection process.
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.
Learning curve: Take into account the learning curve for tools. You have a time line, or should have one. So learning tools comes out of the design and build budget.
Feature completeness (or extravaganza): Tools offer great opportunities for adding cool features, but use the game design breakdown as a reference to check for fits and gaps. On the other hand check the features list is not so big that it overshoots your goal. If you add fancy particle effects to your HUD, does that degrade the rest of the art forcing you to upgrade them as well? My philosophy here is, keep it simple but modular and expandable.
Licensing: Licensing is as important in commercial software as it is in open source. I always evaluate licenses from the business perspective, positive business case, go with it. Too vague, too risky, drop it.
Tools vs. hand work: Does it get the job done faster? Does it take longer to find, install, configure and use the tool than it does doing it by hand? Forget about it. Sure re-use is great, but if you can't think of two other instances for the same use of the tool right now (and save time), it's probably not worth it. I'm guilty of playing around trying to create an automated nav mesh creator, but in the end decided it was quicker to put more info in the map by hand. By making that decision I actually handed more creative control to the designer, which is always a plus in my opinion.
Look ahead: determine long term gains. Are you going to make a map based game? Invest in a map editor capability. Is your game made up of levels? Get a tool that can handle all the level ingredients in a way that the designer can easily work with. One of the key decisions we made was integrating the map editor and the graphics design tool. More on that later.
Total cost of ownership (TCO): every dollar you spend you must earn. What is your target profit and can you afford the tool? Take into account not only the purchase price of the tool, but possible support, upgrades, add-ons, server cost, etc.
Technological lifespan: Nothing is more killing than using a tool or technology that is no longer supported by your target platform by the time you release. Look for roadmaps of the tool, upgrade strategies, etc. Take these factors in consideration and compare them to your time line.
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:
Buy a tool. The main advantage of buying a tool is increasing your productivity or adding a capability right away which you cannot source in another way. Another advantage is that someone else is doing the maintenance and adding more features to it with you focusing solely on using it.
Get a free open source tool. Free is not a lot of money, which is good if you don't have a lot. If you also can find an open source tool, most of the time you will be able to modify it if needed or dive into the code quickly.
Build one. Crafting tools is a real skill, don't take it on unless the game can't come to life without it. On the other hand, sometimes it is the best option when there is no fit with your requirements or your budget.
Which tools did we need?
Game engine: an engine that can handle a standard life-cycle of a game, start-up, initialisation, update and rendering, clean up, logging and resource management.
Graphics engine: our requirements here were that it should be able to handle 2D, use hardware acceleration, work with vector graphics and be accessible for non-graphics experts
AI framework: a toolbox with building blocks to assemble computer opponents with some character
Graphics tools: with our art style set to 2D and a clean, board game, look and feel, we decided on using a vector based drawing tool.
Game Design tools: given the type of game we were building, we required tools for map editing, combat modelling and navigation/movement modelling
Sound tools: the only requirements we had were simple mixing and editing capabilities.
Version control: to be in control of any development process, a version control tool is a must. The requirements depends entirely on your working style and team setup. We are a two person team located in the same town with assets consisting of code, xml files, sprites and binary library.
Project/task tracking: we needed something small, easy to work with, flexible and online. Something for task tracking and something for document management.
Development IDE: as soon as I settled on Java as the development platform, there was just a choice of three: IntelliJ, NetBeans and Eclipse. I've been using mostly Eclipse for years with great satisfaction so decided not to spend time on re-evaluating and fix it as the IDE.
Packaging and build tools: target platforms for Tenshu General are Windows, Mac and Linux which all require some kind of packaging tools.
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.
Some were too 3D oriented.
Where they catered to simple 2D games they were geared towards platform games
With our limited graphics requirements they felt overpowered in the amount of features.
Debugging felt limited (I'm used to the extensive debugging features in Eclipse).
Integration pluggability of (open source) libraries was hard/limited.
I'm lacking experience in these general purpose tools and therefore am unfamiliar with the terminology and it takes me time to figure stuff out. In short a steep learning curve.
Customisability was limited when certain features were missing.
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:
Programming Game AI by Example, by Matt Buckland
The AI Game Programming Wisdom series, edited by Steve Rabin
AI Game Engine Programming, by Brian Schwab
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:
Eclipse: specific java build tool
Ant: general purpose build tool
launch4j: creates .exe files for you java application with option jre bundled
appbundler: creates .app folders for Java applications on Mac
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:
Creating tools together as a community can help accelerate innovation in the game industry as it has done successfully in many other software development industries.
Open Source tools are often incomplete, but if they are 80% complete and are easy to extend and customise they are well worth it.
If you want to use a certain product, spend some time to understand how the community around the product works. Can you participate in its development? Is there an active support group? etc.
Before downloading and using any tool you can find right away, try to judge the maturity of a library/product. Is it well documented? Has it been around long? Are there references from other sites to the main product site? Is its development team experienced?
Look ahead. Is the tool following market trends in terms of technology? How easy can you get stuck?
Way the advantages: it can be free, you can look under the hood when necessary, you learn by sharing code. If you get together and develop frameworks everybody needs and you can share the development cost.
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.
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
