When 2 years ago I started looking for a crossplatform mobile game engine, it was really hard to find one that matched my needs, because as it turns out, I did not actually know what I needed. I was choosing them by completely different characteristic that proved to be irrelevant in the end. For example, I wanted an engine which provided development in the language I already knew and was comfortable with. That actually put a very strict limitation and I was missing out on many great engines. My second mistake was assuming that most popular engines would be the best. Yes, it is great if the engine has a large community and lots of resources, etc. But, in the end, those engines are overpriced, they usually force their own views and ways, and I was missing out on a lot of smaller popularity engines that maybe did not have all the features in the world, but actually provided the ones I need. So while searching and jumping from one engine to another, getting burnt by limitations I found, and struggling to find the one engine I wanted to work with, I started to lower my expectations and try out a couple of less popular ones, until I found what I needed. My best fit turned out to be Gideros (http://giderosmobile.com/) and now after being with Gideros more than 2 years now, I grew fond of it so much that I published a book on Gideros and even started working in team at Gideros to make the engine even better, contribute more, and add the other features I was missing for other projects. So here are the 10 things that turns out I needed and can't live without them now.

10 Things You Didn't Know You Needed from Crossplatform Mobile Game Engines

1) It should be free to try

Of course the engine should allow you try itself for free, with as little friction as possible. For example, first download for free version should be without any registration and strings attached. Also free version should probably allow at least testing app on real devices, yet bettering to publish app with some limitations.

2) Handling multiple resolutions

With all the Android fragmentation and now lots of options to publish to micro consoles running on HD TVs, there must be a built in way to handle multiple resolutions. Either it is an automatic scaling, or handling images with different resolutions, the solution should be provided by the engine giving you control over how you want to handle it.

3) Exporting to the platforms you need now

It gets very tempting to sacrifice some features you might really want, to the option of being able to export to some other platforms you don't need now. Because you know, in case you might need them. But in the long run, the platforms and markets are changing so fast. Lots of micro consoles spawning, and Blackberry dying etc. So if you want to target Android and IOS, don't look also for desktop support. And vice versa, don't go for an engine that does not have a platform you need, thinking it will be supported later.

4) Instant on device testing

This is something I saw only on Gideros, and if someone knows other similar options, feel free to comment, but I cannot stress enough how awesome this feature is. Basically when developing mobile games for different platforms, you would need to build apps and deploy them to try them out, or use simulators, which are usually so slow. And building/packaging takes too much work and time. So there should be some kind of built in solution. And in Gideros it is a Gideros player app, which can run code from your computer on your device with 1 click within seconds

5) Extending with plugins

When I was looking at different crossplatform engines, I was thinking it has to have it all. Oh boy how wrong I was. Firstly if an engine has it all, it is most probably so bloated, providing huge app files. And chances are, its API will be so fragmented, that some function would only work on one platform, others on other. It won't be developing once run anywhere anymore, it would be more like, write once adapt everywhere, which adds more work to it. But what I found out, it is better to have the option to extend what you want/need with plugins, basically extending to any platform specific functionality. No more road blocks, as it does not support this ad framework, or that service, etc. Just take and build it yourself, you're the king of your app's possibilities.

6) OOP

Game development is very difficult without a proper OOP model provided in the language/environment. It's not impossible, but when you are creating a game, there are a lot of objects there (notice word objects, already indicates the preferable development approach), and their properties overlap, so you can define them in classes, inherit properties, etc. So when I was looking for game development in JavaScript, this is what usually provided lots of development problems - the lack of proper OOP. Although it is possible to achieve something similar in JavaScript, it usually felt unnatural.

7) Full control of exported project

When exporting your project to platform specific app, some engines provided an end app, without giving you any control over what's inside and how it is handled. This feature could be arguably considered as con, because it makes you work with each native platform building workflow and learning it. But I would want to say that learning the way it works for each platform, first makes you more engine independent, second provides more flexibility to your project, like adding an animated splash screen, third gives you control over what is inside your app and fourth provides the ways to create your own build workflows reusing dropbox, testflight deployments, etc. Edited: As pointed out, another con is that you will need a Mac to build apps for IOS

8) Common interfaces

The more I hear that engine X created specific plugin for service Y, the more I understand how awful their API must be. Because you see, it's basically all about marketing. X can announce that they created plugin for Y. Y can announce that they now support X, but in the end, the developer has another class with similar functionality but different usage he needs to learn to work with. So since we are looking at crossplatform engines, they should in many cases provide an abstraction for similar libraries. For example, providing a common interface for Ads that allows you to implement lots of ad frameworks, using completely same workflow. That way if you want to change from one ad framework to another, it should be a question of changing a couple of lines, without changing the usage of interface much. Same could go for for In-app Purchases, Social portals, Leaderboards and Controller support.

9) Encryption

I once saw a situation happen to a fellow developer, that someone disassembled his app and without even changing the code, simply replaced the graphics and republished multiple variations of copies of such app. Funny thing they did not even change the email address of the support form, thus the original developer was receiving in app support emails from the copied games. Thus it is really important to not only encrypt your code, but also assets.

10) Community

No matter how good you are at developing, when learning something new, it is really important to have someone to ask for help, to learn more quickly. You should definitely check out the forum of the engine you are trying out and try asking couple of noob questions there, to see a reaction. ;) This was my list. Now what other features your favorite game engine provides that you can't live without? :) title image