Finding a Game Engine is Hard

Well, if you're new here - congratulations on finding the most useless blog on the planet.

If you're not new here, thanks for coming back to another installment of "And he just keeps moaning!", this weeks episode deals with how hard it is to select a Game Engine for your development needs.

As I've mentioned in the past, there are many things to consider when developing a game:

• Storyboarding
• Specification document
• Game Engine
• Resources (art / sound / levels)
• Time constraints
• Return on Investment

Since I've preached about the Specification Document all throughout my last post, I'll save you a little bit of reading by saying it's nearly the most important part of the entire process - nevermind having a compelling game - without the specification document, nothing gets built.

Storyboarding is kind of like the specification document, but it allows you to draw little screens of the game as you imagine it to be, without too much detail. And it allows you to have a visual tool which you can move around to help with explaining the flow of the game to other humans.

Resources are simply all the files (images + textures + sprites, sound clips, music tracks, font images etc) which your game relies on to have the look and feel you desire. Many people get stuck on this bit - they can't draw or sketch and they can't find that very unique image online that represents what they are imagining. Most guys give up at this point, since it's easy to mock up a prototype online - there are tons of resources that allow you to prototype a scene, there are very few hidden resources that help you find or create the artwork you see in your minds eye.

One thing I have to mention is that, in a strict sense, you could view other humans as resources. For instance, I usually think of myself as a resource for code, so when I start a project that requires a developer, I write my name down in the resources section of my planning document. Knowing that I'm a resource allows me to better plan for my own utilization during project development - understanding that I can only churn out so much code for so many hours per day is paramount to helping me limit the reach of what I touch. If you only have 1 developer resource, then you're better off trying to find more Human Resources to better manage the workflow.

Time constraints are simply a measure of how long each item in your task list will take to complete divided by the total amount of time you want to spend on the project. This is a simplistic view at best, since some tasks take longer than others to complete, and its up to your Human Resources to help you in this phase of planning. Developers are notorious for underestimating the amount of time tasks will take, try to add 'padding' around time estimates from developers as they're only human and sometimes run into unexpected issues.

Return on Investment is a simple calculation of how much each planned feature will contribute to the overall perceived success of the project - notice I use the word "perceived" as it's not known at development time how successful the product will be, it's only known how much each planned feature will contribute to the perceived value of the product.
As an example - if you're developing a knife, it's better to spend more time working on the strength and flexibility of the blade than it is to nitpick over the colour of the engraving on the handle - and yet, some product planners seem to get this wrong.

I've seen several instances where a huge amount of importance is given to certain features because the perceived value of the feature is inflated due to personal bias. In this regard, it's best to find an impartial observer and show them a mock-up of the product with and without the feature to gauge their response. This is similar to A/B Testing and helps tremendously with product design, yet it's often overlooked.

This brings us to the topic of todays Moaning Session Post. The Game Engine.

I've personally seen some inexperienced teams plan out an entire game - yes, from start to finish, with storyboards and careful resource allocation charts - without even mentioning which Game Engine they're going to use.

You might find this fairly hyperbolic, but I assure you - it's very easy to overlook the Engine, after all - the Game Engine is just a set of classes with which your code interfaces that "takes care of" (tm) the low-level details so that your developers can get on with writing the code for your awesome game.

While this is true, it's also not 100% accurate since there's a cost involved in selecting a specific engine. If your team isn't intimately familiar with the engine, there's a huge learning curve - especially for larger engines, which you'd have to take into account.

If you'd allow me to make a tangential example - it's kind of like training to run a marathon, while running the actual marathon. I'm not even exaggerating, this is almost exactly what it's like to pick up a new Game Engine and start using it in production from day one.

My recommendation is to try to find people who are familiar with building projects using the engine you're trying to use, else there's a lot of internet searching you'll have to do to get everyone up to speed with how things work.

I recently embarked on this mission myself, but I had the luxury of not really caring too much about any Game Engine in particular - I'd had some experience with Irrlicht, a little bit of dabbling with other Engines, but I had nearly 0 experience with Game Engines which target Android.

This relative inexperience put me in a unique position of having to slough through tens of engines to find something even close to what I needed. Unity was almost immediately disqualified - not only does the editor devour my machine resources when I start it up, but I'm not too happy with the coding language access and implementation they're using.

Unreal was totally unreal in their licensing model. Irrlicht was also disqualified, since I wanted the engine to be easily usable inside Android - mostly written in Java and I wanted the engine to hide the language bindings from me where they've chosen to use C++ for speed boosts.

Godot looked fairly promising based on user reviews, until I went and read up a bit of their documentation - the moment they mentioned Scons my eyes glazed over and I rejected Godot. There's no way I'm unleashing that dragon.

Most of the other engines I researched had one limitation or another that didn't sit well with me. Some had strange licensing terms, others had tough build systems, and yet others were written using non-Java-like syntax and naming conventions.

I can appreciate as much as any other developer how hard it is to learn conventions that are specific to a language and the community built around them - Java code can be written to look much like C++, but the two communities differ and therefore the accepted language conventions differ as well. When writing something as utilitarian as an Engine, all that's required is a firm grasp of the language specifics - Memory management and Object construction, in order to write a decent engine. One could argue that good engines are constructs which can be written in any language, and naming conventions and language specificity only serves as fluff.

I'm not going to argue the point above, but one could . . .

Since I've spent a fair amount learning Android development by building Android apps and games, I've spent a fair amount of time just learning to understand the basics of the development process. This is something I've never bothered with - since I'm self-taught, and never cared about that much, since most of the good development skills are language agnostic in any case. I've paid special attention to Android, as this is where I believe I'd like to fit in, so to speak.

When I write Java code on Android, I'd like it to look as much like the code which Google releases as possible, naming conventions an all. So I've paid special attention to Java since I'd like to continue developing in it and be able to blend in seamlessly with the online communities around it - and the most obvious way to stand out is to not be aware of the unspoken conventions surrounding the language.

With all this in mind - as well as the fact that it's easier to be productive in an environment that's familiar, even though it's new. I embarked on my mission - scanning through tens of engine entries on search engine pages, scouring forums and articles. Perusing blogs and StackOverflow questions and answers until only one Engine stood out among the rest.

Enter libgdx - as much an engine as a library, it has it all: Feature List

Even though it's cross-platform, when I develop on Android, it feels like Android, it's nearly immediately obvious which class I should instantiate, or how to do it, since it feels so familiar. With this in mind - it has great performance and a substantial list of helper classes to ease my job. Their documentation is also some of the best I've seen in a while, and I'd highly recommend anyone who wants to get anything serious done on Android to give it a shot.

More important than all of that - their build system didn't require me to change anything about my development environment - all developers know what I'm talking about: you get your IDE set up nicely the way you like it, then you select a Game Engine and are forced to abandon your IDE and reach for your Terminal (Command Line on Windows) because the Engine does something that requires it.

With libgdx you can develop with Eclipse or Android Studio - it's supported by Gradle and allows you to continue working on your mock-up without changing much apart from a few class names.

There's also the question of file size, since Android games can reach into the hundreds of megabytes these days, I wanted an engine that didn't add that much overhead to the size of the resultant APK, and this is where libgdx really shines - I followed a tutorial which contained 2 images and one WAV file and checked the size of the resultant APK, around 4.5MB which is significantly smaller than most of the other engines I'd looked at.

I'm really being picky here, but I'd like for my supporting engine code to not outweigh my own game, and this is something I find very important on mobile devices - especially in my country, where mobile data is exceptionally expensive, and most people opt for the 'Lite' versions of almost any app they choose to download - if I want a shot at the local market, my app needs to be as small as possible.

While I could go on all day about the benefits of libgdx, I'll leave it at what's already listed - you could go read more about it over here if you really want to - after all, who better to tell you about it than the people who built it.

In closing, you're more than welcome to use any engine you wish, after all you'll select based on criteria that is unique to your project - but please make sure you take into account that any engine selection comes with a learning curve, and that learning curve needs to be accounted for in your Time Constraints considerations when planning your projects.

I think, in total, it took me about a week to make my final selection, and that's only the beginning - now the real fun starts.