Jump to content

  • Log In with Google      Sign In   
  • Create Account


Like
6Likes
Dislike

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

By Arturs Sosins | Published Mar 03 2014 02:42 PM in Reviews
Peer Reviewed by (jjd, jbadams, dejaime)

crossplatform mobile game engine gideros

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



License


GDOL (Gamedev.net Open License)




Comments

So you (the author) are on the Gideros team? If that is the case, then this article is supposed to be marked as a 'review' and follow the structure of a review.

 

-Josh

I definitely agree with Josh, this writeup is review and promotion and should not be listed as a general article.

I stopped reading when realizing only one engine is mentioned over and over again. This should be placed as a banner not an article.

This is not a page for free ads.

Sorry, first time user here, changed to reviews ;)

I stopped reading when realizing only one engine is mentioned over and over again. This should be placed as a banner not an article.

Although in this case they apply to one single engine, the real meaning was that those features are great to have, and maybe something you could look in other engines too 

Sorry, first time user here, changed to reviews ;)

 

Thanks for making the change, Arturs! One suggestion I would make is to disclose that are now working on Gideros at the beginning of the article rather than the end. Otherwise I think it is a fair review. :)

 

-Josh

I think number 4 is the real winner. In a scenario where you have 4 or even 5 different deploy platforms it is crucial to have on-the-fly testing, basically just re-uploading the "kernel" or whatever you call your application to a fresh instance on the device. No platform specific re-compilation, no USB upload through itunes or whatever. Yes that is a definite winner as if you have the 4 of them in front of you, basically you could update the app on all platforms (even those standing in a show case room) with the click of a button. Very cool.

While point #6 does have content with merit as an opinion, the sentence "Game development is not imaginable without a proper OOP model provided in the language/environment." is actually both very wrong and misleading.

 

Sorry, first time user here, changed to reviews ;)

 

Thanks for making the change, Arturs! One suggestion I would make is to disclose that are now working on Gideros at the beginning of the article rather than the end. Otherwise I think it is a fair review. smile.png

 

-Josh

 

Thank you for suggestion, moved it to the Introduction part ;)

While point #6 does have content with merit as an opinion, the sentence "Game development is not imaginable without a proper OOP model provided in the language/environment." is actually both very wrong and misleading.

 

True, it sounded too biased, rephrased it

Unity does everything mentioned here better.. plus more

Even if this is an article/review of an existing package, I see it more like inspiration for my own framework (never meant to become commercial by its own). Unity is good for what it does, but it's very hard to extend and has the look-ma-we-have-plugin-x syndrome which is actually described here in point 5 and 8. Please correct me if I am wrong, as this is from an experience of a friend of mine.

Unity does everything mentioned here better.. plus more

Sure I agree, Unity has really a lot to offer.
I've tried Unity before their support for 2D and it was very complicated to start with, but I guess once you get into it, it gets better.

 

By the way, I don't remember Unity having instant on device testing. Is that changed now?

What the author did not mention in this post is that the drawback of exporting project files instead of app packages is that you'll need a mac to compile for ios. 

 

I have a problem with this sort of article, especially considering the headline which brought me here. A proper name would be "10 Reasons for using our cross platform game engine". The article is superbiased and written with the intention to spread the word for one specific engine and not to inform fellow game devs. 

@überflieger and I agree with you

 

What in your opinion would make it less biased?

 

If for example, all reference of the specific engines would be removed, would you still call the 10 listed features too biased?

 

And about exporting to Mac, either way it would be against the Apple rules to allow creating ipa without a Mac, wouldn't it?

Wow, this really seems like a provoking way of advertising. Get a banner instead. Even if it was a review, it would be really biased, as its the author himself who does the review.

Point taken! Edited it.

 

Just wanted to say that it is not my job to promote it (unfortunately I'm not getting paid for that smile.png ), I just wanted to share the experience and hear what others like about their favorite game engines. And I am biased to Gideros engine, but not because I work there, but because I use it in my game dev company and I really love it (and THAT is the reason why I also work there)

 

;)

What in your opinion would make it less biased?

 

Comparing at least 2-3 different engines I guess.  Or not mentioning a specific engine at all. If you headline your article with "Things you did not know you needed..." then I would be much more interested why I should care about the points you make. And how you came to these points.

 

 

If for example, all reference of the specific engines would be removed, would you still call the 10 listed features too biased?

 

Yes, because they are chosen in order to highlight specific features of your game engine. I mean a list of such things can never be accurate, because everyone has other needs. What about IDE support? What about Debugging Capabilities? What about acess to native device features. These are things I look for in a cross platform kit. I think you can write an article about what based on your experiences you value as important. 

 

 

And about exporting to Mac, either way it would be against the Apple rules to allow creating ipa without a Mac, wouldn't it?

 

You have to build your ipa against an ios SDK. There is no mentioning of doing this on a Mac in the Apple dev guidelines. I know of at least one cross platform kit which allows for compiling an ipa package on Windows.

@überflieger hmm, interesting I think it was mentioned somewhere more strictly then guidelines, but still your point is valid, edited the article and thank you for the feedback.

 

I tried to emphasize it is my opinion in the article now, so hope it is better now

 

BTW what engine exports ipa and how exactly that is done? By remote server? Because I imagine that even if ipa is exported, you would still need to run the engine on Mac to do so, wouldn't you?

Excuse my ignorance but what prevents a package to have a dynamic jit lua recompilable app layer? Meaning if you have the ip of the app it would just connect to get the proper execution envionment. Why would you have to go through the apple SDK if you use a VM?

BTW what engine exports ipa and how exactly that is done? By remote server? Because I imagine that even if ipa is exported, you would still need to run the engine on Mac to do so, wouldn't you?

 

Adobe Air for Mobile does compile native ios IPA on Windows. Their Gaming SDK comes with an ios SDK also on Windows. They provide their own packager. No remote server involved. You get a native app as a result.

 

 

BTW: I think it is great that you try to listen to the feedback here. 

@spinningcube yes that is exactly how Gideros player work, but it mostly for testing purpose.
To use such system in real environment need to be more carefull, as Apple might not allow an app being published which executes none packaged code sent to the app or provided dynamically in other way

@überflieger Windows compatible ios SDK? Wow, they must have somesort of deal with Apple, or something.

 

And of course I try to listen to feedback, I am new here. And I'm not a writer, much less marketer :D

Just trying to express opinion and learn the ways :)

I see so it's more like their policy but it's not something they can really reinforce except after the fact like a kind of ban on certain applications once they observe such behaviour. It is really constraining developers for all the wrong reasons in my opinion, but then again people eat it up and love Apple whatever they pull. It's a raison d'etre of the appstore. Kind of preventing developers to do what they did to the music industry - to create a parallel distribution network.


Note: Please offer only positive, constructive comments - we are looking to promote a positive atmosphere where collaboration is valued above all else.




PARTNERS