Up until a few months ago, The Journey Down was assembled in an excellent piece of software called Adventure Game Studio. As we’ve mentioned in a few earlier blog posts, we’ve spent some time poking around in the innards of the newly open sourced AGS, trying to make it suit the needs of our production. There were two primary concerns we had with AGS which we needed to resolve. The first was that we needed to be able to make use of higher resolution content and make use of higher screen resolutions than were possible and the second was that we wanted to be able to easily port our game to multiple platforms and operating systems. As some of you might remember, we adressed the former concern a while back and added support for more screen resolutions. Porting the source to further platforms however seemed trickier. In the end, we ended up not being able to resist that which pretty much all game programmers end up doing… We built our own engine.
Leaving AGS was definitely not a decision we came to lightly, but one of our main reasons for running SkyGoblin is that we want to have fun and building our own tech rather than adapting others’ is a lot more fun! After a few months of tinkering in C/C++ at home, our very own 2D Adventure Game engine, Gobby, was born.
When desigining Gobby, most of the inspiration has been drawn from the experience me and Mathias have aquired in building Nord (and a few other projects) during the past few years. We wanted to make sure to avoid the most obvious pitfalls we’d tumbled down when developing Nord as well as adress the different nitpicks Theo had with AGS when developing the prototype for The Journey Down. There are practically no technical similarities between Gobby and AGS, but without the many hours spent in the AGS editor, I’m certain that Gobby would look a lot different from how it looks today.
Gobby is more or less entirely written in C/C++ and we’ve put effort into making it as portable as possible. Currently, it runs on Windows, Linux and Mac OS X. To minimize portability problems, we’ve refrained from using any proprietary or platform dependent technology, written our code in Eclipse and use different flavors of Gcc for compiling (MinGW on Windows). A proof of concept version of the engine is running on Android (native C/C++ with just a thin layer of Java wrapping it) and since we’re always keen on getting our hands dirty with different kinds of tech, we have every intention of creating an iPhone/iPad version as well. Right now, the list of features and state of the source code changes a lot since we’re constantly adapting it to fit our current production needs. For that reason, we’re currently exclusively focused on desktop development, but as soon as the dust settles a bit we’ll continue working on the code for handhelds. The proof of concept port of the engine to Android was done over a weekend, so we’re confident that we should be able to finish it and an iOS port in a reasonable amount of time. Whether or not we make use of the handheld ports for any current projects remains to be seen, but I very much doubt we’ll be able to keep ourselves from toying around with our tech on different devices.
For those of you who are technically curious, we’ve so far made use of the following technologies and libraries in assembling Gobby (a big thank you to the developers of the named libraries!):
- OpenGL for cross-platform rendering. We’ve tried to keep the API specs as low as possible to ensure that the game at least runs on older hardware. Those who have graphics hardware with programmable shaders and support for GLSL will see a slightly prettier game as we make use of shaders for a few non-essential effects such as real-time colorization of sprites to make them fit more snugly to their environment. For window management and input handling we currently use the GLFW library on desktops and provide our own implementations on handhelds. OpenGL is convenient since it allows us to write pretty much the same rendering code on all platforms including the handhelds.
- Angelscript for scripting has made our life a lot easier thanks to its intuitive and flexible C/C++ interface. Bridging our script functions and core engine features with Angelscript is a breeze!
- libPNG for image assets. In order to make it easier for our artists, we use a standardized format during development to make editing existing assets as easy as possible. We’re investigating using WebP for near-lossless compression of the deliverables.
- Ogg/Vorbis for audio samples.
- Ogg/Theora for video. We use very little full motion video, but the intro and outro of The Journey Down will be hard to pull off without FMV.
- OpenALSoft for audio playback on desktops.
- Freetype for font rendering.
- GLM for convenient and portable vector math.
To make our artists (and for that matter ourselves) a bit less suicidal after long stretches of The Journey Down development, we’ve put some effort into creating an editor in which we can assemble our assets. The editor is written entirely in cross-platform Java and contains, among other things, functionality for assembling animations, putting sprites at their desired locations, adding hotspots, walkable areas and a built-in script editor. Like the engine, the editor is in a state of constant development as we continuously add the features we realize that we are in need of. All in all, development is progressing nicely and we’re currently capable of producing content for The Journey Down using our own tech at a surprisingly high pace!