In this post we’d like to cover the underlying technologies that tie everything together and run the whole 2d point ‘n click experience.
We stated that one of the main criteria for our game engine is to be able to run on multiple platforms. This requirement made us have a look at what programming language would make it easier for us to support this in a convenient way and at the same time be suitable for us based on our combined experience.
The following shows a list of languages that did not make it and the reason why:
- Platform dependent language
We want our codebase in one language. So no language per platform (Objective-c for iOS, Jave for Android, etc)
We don’t want it to be HTML5. HTML5 might sound ideal for multi platform but it has several limitations so it’s a no go for us.
- C / C++
We are not completely comfortable using c or c++. Although we know what it can do and that it can support all platforms, we think there are more convenient languages that should be able to offer what we need.
Although C# is a great language, and using Xamarin you can target many platforms, we didn’t go for it. It’s too Microsofty.
So what did we end up using?
*drum rolls, pigs screaming*
Haxe? What is that? (at least that’s the response we have gotten so far)
Haxe is a language and a cross platform toolkit. To quote the Haxe website:
“Haxe is an open source toolkit based on a modern, high level, strictly typed programming language, a cross-compiler, a complete cross-platform standard library and ways to access each platform’s native capabilities.”
In our case only the C++ target is relevant, since all of our target platforms (Windows, Mac, iOS, Android) can handle this natively.
Since we have our own respective busy lives – being part of some corporate machine – and simply cannot spend our time implementing every bit of machinery ourselves we have decided that we’d like to have some kind of framework that would help us get a little head start with the low-level game mechanics.
For example, a typical game framework takes care of handling things like rendering sprites or textures, playing sounds, file I/O, handling animation, etc.
Since there are a lot of good frameworks for Haxe out there, we tried a couple before we decided.
The first version of our game engine we built using HaxeFlixel, an extensive framework for Haxe with a large and vibrant community. HaxeFlixel was great to use, but in the end it did not give us what we needed. In a future post we will pinpoint exactly why we decided to abandon this particular framework and tell you how we ported it to the framework we are currently using:
“luxe is a free, open source cross platform rapid development haxe based game engine for deploying games on Mac, Windows, Linux, Android, iOS and WebGL.” (luxeengine.com)
Although it’s called a game engine, we see it as a framework for building things such as game engines. Most conveniently so, using Luxe you can develop games cross platform for the following targets: Mac, Linux, windows, HTML5, iOS and Android.
“Snowkit is a collection of tools and libraries, but is also a group of developers, and the community itself, all with a common set of goals toward a high quality eco system”
For more information about the details of Luxe, read the website, which includes a general explanation of the core concepts, various code examples, API docs etc.
This image illustrates the architecture of luxe, snow and flow (click to enlarge):
(taken fom luxeengine.com)
Why did we choose Luxe?
Luxe provides us with all we need: animation, state machines, mouse/touch input, sound playback, camera controls, tweens, fonts, particles, shaders, etc. At the same time it allows us all the freedom to plug in or override any code, because luxe also exposes the underlying snow framework, which in turn exposes the OpenGL functions. So if we wanted to we could manipulate really low-level functionalities – so far we haven’t – and for instance plug-in our own rendering code.
Of course there are also drawbacks using Luxe. The most important drawback is that it’s still alpha. Although it’s mostly feature complete, this might change, so during development we might have to rework some things.
Another downside is the documentation. There are several useful guides, but the thing is, is that not every part has been described so far. Same goes for the API documentation. This will most likely get much better, but in the mean time some things require some real trial and error.
The big plus is the great (but not yet large) community of enthousiastic luxe users. The gitter instant messaging and the Snowkit chat is full of helpful people (check out gitter snowkit). We at least like to recommend giving luxe a try.
In future posts we will show you how to use luxe for certain useful game mechanics, such as: targeting multiple devices with different resolutions, using the camera, creating parallax effects, etc. So stay tuned!
Third party libraries
Apart from Luxe we use several other libraries that we did not build ourselves.
The great thing about Haxe is that there are a lot of people developing libraries and they are very easy to incorperate in your project using HaxeLib.
“Haxelib is the easiest way to find libraries and code for your Haxe project – and the best place you can share your code with others in the Haxe ecosystem. Haxelib is the package manager for the Haxe Toolkit.” (lib.haxe.org)
We use the following open source libraries:
We use Lua for all our game logic. This way we can keep the game engine code and the game logic code separated.
We use the version of hx-lua from ‘kevinresol‘: github.com/kevinresol/hx-lua, which is a fork of the original by ‘MattTuttle‘.
In the mean time ‘RudenkoArt‘ forked this as well and made some further improvements. We might incorporate his version in the near future.
Future posts on this blog will go into great detail how we use Lua for game logic, and how we accomplished this in our engine.
We love JSONas a file format, but we don’t like how strict it is.
Therefore we use TJSON (source) by ‘martamius‘. TJSON is a tolerant JSON parser and encoder. It unserializes and serializes JSON data, but without all the strictness of standard JSON parsers; it supports multi and single-line comments, keys without quotes, and single quotes.
This library is not really adventure or game engine related, but since we plan to put up some posts with JSON examples, we don’t want people shouting “That’s no JSON! You’re doing it all wrong!”
JSON is great for machines and also quite human readable, but it’s not that great to represent interactive dialogue with. Instead for dialogue we use YAML, a data serialization standard that is geared towards being conveniently readable and editable by humans. To parse YAML in our Haxe code we use yaml (source) by ‘mikestead‘. In a separate post we will dive into the surprisingly complex realm of inputting, processing and visualizing interactive dialogues.
There are some other pieces of software we use, including some code snippets from others, but for now this concludes our overview of the chosen technology for our game engine.
If you have any questions, don’t be shy and leave a comment.