Comparison report - "Battle of the Lua Game Engines"

techdojo · September 2012

http://www.gamefromscratch.com/post/2012/09/21/Battle-of-the-Lua-Game-Engines-Corona-vs-Gideros-vs-Love-vs-Moai.aspx

Final Verdict.

For a Pro developer: Go Moai, unless you have no in-house C++ talent, in which case, go Corona.

For a new developer: Go Gideros, especially if you want to do mobile development. If you don’t like it, Love is always a great option.

Can't say as I agree with the verdict for Pro developer - at least with the Corona choice.
Other than documentation what is it that Corona can currently do that Gideros can't?

bowerandy · September 2012

I actually think this is a pretty fair review. I do agree with you that Corona shouldn't really be a pro-choice over Gideros but the fact that they have so many games published must give a certain confidence to a new developer.

best regards

OZApps · September 2012

One line from the article under Gideros states

API itself a bit less intuitive ( to me )

and also continues to state

 Good choice for beginner who wants to support mobile, lack of major published games a bit of a deterrent for professional developers, as is the lack of source code

The reviewer is definitely not from a object oriented background otherwise Gideros API fits right in.

Secondly, the availability of source code... now even if the entire source code was made available, what would majority of the developers using Corona, Gideros or Moai do? If they did want to do something with the underlying layers, they would have already done something by now, not looked at Lua frameworks Moai's source code is available and so is Codea Runtime, LÖVE to name a few, why hae these not been taken and integrated to form a new framework or a custom engine?

The other factor of maximum number of apps released, it is also due to the fact that a lot of developers used corona in the past when that was the only Lua based framework and have not released any new Lua based apps for various reasons. However there are some wonderful apps created using Gideros from Alex, Phongg, HGVyas.

I do agree with @Andy that Gideros can make pro apps, the things that kept it apart from Corona was the access to MapKit, Video, WebView, etc. Most of which were not available for Androids, so if we use the Andy-Wax-Plug-in, we have access to all of that and more, I posted an article on how to use twitter in 3 lines of Lua, now Corona does not have that as yet.

There are many other factors that help the cause of Corona like being based in the Silicon Valley, where access to media and audience are plenty. Plus the factor that catapulted Corona into the limelight was not the Pro or the polished features, it was Bubble Ball. The list of features have remained kind of stagnant since then.

@Andy, the fact that most new devs look for code samples and most of them fail to realise that 90% of the code samples that they are looking for are Lua based than framework specific. Many developers have already posted their code onto the community code for Corona. Plus on the topic of number of apps, if you look at how many of those apps are current and valid, you will get an idea on the situation. Yes, it is still a mental comfort to know that there are apps made with a certain framework.

One unfortunate thing that remains is that an app is as good as it looks. Some of the Corona apps that look amazing (graphics) are shoddy as far as code is concerned and there are some average apps that have amazing things in the background but fail on the graphics.

phongtt · September 2012

One thing from my observation is that (IMO) Gideros still doesn't have enough visibility that it should be / deserve to be

I joined several forums and social groups of new developers/indies, and I saw that they hadn't known about Gideros, but just Corona, until I (shamelessly) introduced it to them

ar2rsawseen · September 2012

I think you can see what author didn't like if you look at Gideros code example he provided.

To sum it up:

Text size is provided with font (which is not intuitive) and can not be changed
Center positioning is complex, because you can't set AnchorPoint for text
Color is provided in hex (probably providing color names would be more intuitive)
Confusion between touch and mouse listeners

All of this points can be fixed with proper abstraction layer. Maybe it's a time when Gideros needs a framework to provide this abstraction layer and combine all popular methods/hacks on this forum? What do you say?

phongtt · September 2012

That's a good idea.

As from another perspective, I think Gideros should have a better knowledge base system such as code snippet with easy and quick way to search for a solution (whether a very simple one or more complicated one).

And the documentation page should better have a left-pane navigation, I think it's more convenient, don't you think so?

ar2rsawseen · September 2012

@phongtt +1 for left panel fixed positioned navigation

ar2rsawseen · September 2012

Had a little free time on the train and based on the @phongtt suggestion, here's the result of my free time

http://appcodingeasy.com/gideros_docs/reference_manual_modified.html

I don't know if I copied everything, it's just a concept for now, that would maybe give inspiration to @teamgideros

techdojo · September 2012

Woohoo way to go @ar2rsawseen!

GregBUG · September 2012

@ar2rsawseen! wow!!!

DRS · September 2012

Thanks a lot!!!

Tom2012 · September 2012

Having used C'rona and been a paid subscriber for some time I would say that Gideros, by a long way, is the better solution. Here's why I choose Gideros over the competing tool.

- Instant device testing
- Local builds
- I got a reply to my first email in about 5 minutes!
- Performance
- IDE
- Classes
- Scene manager

Serapth · October 2012

Hello all, as the author of the comparison, I thought I would chime in with a small bit of explanation.

First and foremost, I was quite impressed by Gideros, it was perhaps the biggest shock of all the programs I looked at, as it was also the one I knew the least about.

Second, this was by no means a comprehensive review, think of it like a car review. There are two kinds of car reviews. The type where an author takes a car out for a drive, perhaps thrashes it around the track a few times, then writes up his or her impressions. Then there are the reviews where the author lives with the car for 6months or more, then writes about their entire experience and what the car was like to actually live with. This guide was very much the former type.

This means I am not encountering those annoyances you only encounter when you actually live with something every day. Therefore the comparison is based almost entirely on initial experience *and* perceptions. This isn't so useless as it initially sounds, as anyone evaluating a new technology isn't going to spend half a year with each... at least, not if they actually want to get something done.

One of those key metrics in place of experience then is shipped products and as bowerandy already said, to a developer evaluating a prospective technology, this is *HUGE*. No matter how crap something might be when you jump in to it, you have baseline assurances that it is at least capable of accomplishing X. Fortunately, this is probably the easiest thing to fix over time. It doesn't take a massive catalog of games to inspire confidence, it takes one or two very good games. On my internal scorecard, Moai actually won this category, not Corona, and Moai only has a handful of games shipped. But a few of those games are simply put, the best most technically competent games available. What Gideros needs is a halo game ( as in, the halo-car, not Halo the shooter, although ironically Halo is a halo game too... ok, I will stop talking now... ), something that can be splashed on the front screen and pointed at while loudly yelling "GIDEROS MADE THAT!". There is a reason why all middleware pages splash their homepage with titles that shipped using their product.

As to the comments regarding the intuitiveness of the coding experience, ar2rsawseen nailed it. Perhaps I picked a project that didn't mesh with Gideros ( I chose the example before I started with any of the packages (except Moai, and it certainly wasn't an example that glorified Moai, which came in the longest and probably most complicated) to keep free of bias, conscious or otherwise. Of all 4 packages, Gideros was the one I ran in to the most WTFisms, of which ar2sawseen highlighted pretty much all of them. None of them were deal breakers, but every one did cause me to have to hit Google.

Again, this is heavily a matter of opinion, but code consistency is of incredible importance to me when choosing any kind of library. Of the four libraries I evaluated, the Gideros sample was actually the slowest to get the example up and running, while Corona was easily the fastest. (Which is somewhat ironic, as Gideros was by a mile the fasted to *start* developing). Simply put, the Corona api behaved as I expected it to allowing me to guess ( and be right 95% of the time ) how to implement something. Gideros was actually quite close, the overall code itself was quite nice, but then I just ran into annoying implementation details that I had to Google my way around and after the fact, couldn't understand the final logic behind ( like the lack of Anchor points on text objects ). Coincidentally, I got my start as a C++ programmer, so my brain is very much warped in an OO way of thinking, so it had nothing to do with that.

Finally on the topic of open source, it is actually more important on mobile than you might expect. This is an area where Moai shines. If you are a large development house like DoubleFine, you can look at the engine as a starting point when making your own engine. However, even if you are a smaller dev shop, source access is quite important. Even though the majority of developers aren't going to make changes to the core engine itself ( nor would they using an engine like UDK or Unity ), mobile is a bit of an exception. The plethora of Android devices make fully exploiting a device basically impossible unless you have source access, period. If the next Kindle Fire say... supports SmellOVision, at am at the mercy of the closed source middleware provider to support this new feature. To say nothing of the fact Google dumps support pretty much 100% in your lap, making troubleshooting extremely difficult if you are working in a black box.

Truth is, if Gideros open-sourced the client only, that would be enough for 9 out of 10 developers. I'm not sure how feasible this would be to actually do though. Of course, a source license option would go a long way to addressing these concerns, and would potentially give Gideros another revenue stream. Many times it isn't *actually* the source people need, just potential access is enough to cause developers to sleep at night.

All told, Gideros was a really impressive package and it's turn key approach, flexability, reasonable licensing and no requirement for a build server is why I gave it the nod as the best for amateurs.

The lack of code access and halo games though is the biggest hinderances that would keep me from "betting the company" on Gideros for making a commercial game, especially if I was the one paying salaries. Of course, there are massive ranges between Amateur and Pro ( welcome to the catch-all Indie ) and this is where the decision becomes very gray and very difficult. Truth is, the two biggest negatives for Gideros are fairly easy to fix; someone ships a AAA game powered by Gideros and Gideros offering a source license, and presto... problems gone.

Hope that makes sense?

Also, one of the biggest problems for Gideros is honestly lack of exposure. This isn't really fair, but without Corona's status or the high profile Kickstarter attention Moai received, Gideros suffers from... well, obscurity. This is one of those things that is just unfair in the technical world, but it is true. I do like Gideros though and intend to provide a bit more exposure in the coming days on GameFromScratch. If a Gideros knowledge expert wants to do a guest piece extolling the technical virtues of Gideros ( for a technical audience, not a marketing one ), I am certainly open to publishing it.

Mells · October 2012

Thank you for stopping by and expanding, @Serapth.
That totally makes sense.
As a member of this community, I appreciate and am sure your suggestions will be taken in account and will help to make Gideros even better than it is today.

ar2rsawseen · October 2012

Yes thank you @Serapth for more comments and your thoughts.
And hey, they already are being applied:
http://www.giderosmobile.com/forum/discussion/1780/extending-gideros#Item_1

It is really hard to look at Gideros from a new perspective, because developers who have been here if not from the start, then still from a long time ago, everything in Gideros seems natural (heck we probably all know how @atilim is thinking by now

).

So your comments are a great feedback to fix and provide easy to start options for developers that are new to Gideros.

bowerandy · October 2012

@Serapth, again, thanks for putting in the time to pen this reply.

Of course, a source license option would go a long way to addressing these concerns, and would potentially give Gideros another revenue stream. Many times it isn't *actually* the source people need, just potential access is enough to cause developers to sleep at night.

I totally agree and I wonder if @teamgideros would care to consider that. The availability of a source code licence (even at several thousand $$$) would go a long way towards alleviating the concerns of a true pro-house.

The difficulty for all these framework suppliers is how to appeal enough to the mass market (to gain traction) whilst still encouraging the professional market who, in the end, are the people with enough cash to make the framework commercially viable.

best regards

Serapth · October 2012

Yes thank you @Serapth for more comments and your thoughts.
And hey, they already are being applied:
http://www.giderosmobile.com/forum/discussion/1780/extending-gideros#Item_1

It is really hard to look at Gideros from a new perspective, because developers who have been here if not from the start, then still from a long time ago, everything in Gideros seems natural (heck we probably all know how @atilim is thinking by now ).

So your comments are a great feedback to fix and provide easy to start options for developers that are new to Gideros.

You and your response are a credit to the community.

gorkem · October 2012

Open source way is often used for business advocacy. It almost always attracts editors and increases PR level. Going open source definitely increases user base, however there should be a complementary service (in Moai's case, their cloud services) that will help their business grow. In a case where you only have the SDK open sourced and do not have a complementary product to sell will likely declare the end of business.

I haven't counted Gideros SLOC lately, but AFAIK it's now more than 200.000 lines (excluding external and 3rd party libs and auto-generated code). If a company wants source code of Gideros, then this means they really have lots of resources, to read hundreds and thousands of lines and try to come up with a better solution then what Gideros Mobile devs have. Open sourcing also needs more tools and integration points (e.g increasing commit frequency, agreements, disclaimers, conformance to licenses, more control on contributions, continuous integrations and builds etc), which means more resources and definitely more money.

In Gideros case, core software is extensible rather than being open source. This allows programmers put building blocks on top of Gideros, without trying to understand the innerworking principles, which is (most of the time) complex and time-consuming for a project of this size. Very few developers really want to focus on the core engine, as main aim fiddling with Gideros Studio is to develop games rather as quick as possible and go to market, than understand what's hidden behind the scenes. Therefore we wanted to focus on extensibility rather than being open source.

There has been some discussions between Atilim & me making core Gideros functions open source, and Atilim is silently working on seperating the main engine from the middleware. But this has a very specific aim: rather than increasing the confidence, it'll allow 3rd parties add other hardware, since this layer will be separated from Lua bridge, allowing it become a generic interface to the hardware. It's currently gas and dust but evolving slowly. This is where we see open source is of benefit to vendors.

I'm really interested in seeing how Moai really benefits from being open source - I mean how many developers there are in Moai forums really focusing on core internals? I dont want to be misunderstood here - I believe being open source gives a considerable credit to that project, but I'd be hesitant to open the "core" as it may pose risks if licenses are not carefully selected (especially during exit, if company ever thinks of it).

In short, I believe staying close to customer, building a strong ecosystem, answering what they need is much more important than being open source and waiting for people chime in just because you announced it. In todays fast paced world, completeness and extensibility of product and marketing (which we lack, I admit) is becoming superior to (only) being open source.

PS: As @bowerandy states, we could also be thinking of giving the source code for $$$, but does it really make Gideros on par with Moai's vision? I'm not sure, as only those who have money in their pocket will be able to see the source, and others will see Gideros as a closed source engine. I think things (especially perception) will stay the same. I may also be horribly wrong here anyway hehe

@Serapth your insights are very valuable - thanks for sharing this article with the community, and awaiting to read your Gideros Studio related articles

@Atilim I think the ref manual template Arturs provided is perfect, what do you think?

Serapth · October 2012

Hi Gorkem,

I just want to make it clear; I am not advocating one way or the other re open-source. Both methods of development have their advantages and disadvantages, as do they both have their associated business models. As a developer myself, I am all for getting paid for my efforts, something that much of the open source world isn't generally inclined to agree with.

However, I am reiterating, the lack of a code license option ( even if never used! ), is a detriment. It is pretty much the established norm for commercial engines to make a source license available ( think Unreal Engine, HeroEngine, but if you dig deep enough, almost every commercial engine has the option available ), even if it is under an NDA and at a per contract negotiated price. I am certainly not pushing for Gideros to go open source!

So, TL;DR

Opening up the source != open source.

gorkem · October 2012

Thanks for the insights. We'll think about how a licensing would be of benefit in case of Gideros Studio, why development studios want to license Unreal/Hero/ other game engines' source code - and of course how this business model can be applied to us.

phongtt · October 2012

Mmm... He doesn't seem to understand that Gideros supports plugins. Or am I misunderstanding him? :-??

gorkem · October 2012

I think you have written everything in a clean and open way. :-)

We simply do not target companies requiring whole source of Gideros Studio - just like many other mobile application development frameworks. Desktop gaming / desktop game development environments is another story I believe - companies can pay their staff to embed their own shader, improve performance, and implement, for example, new Tegra{4} support inside the desktop engine they buy.

This is currently not the way forward for Gideros SDK / engine and we do not see a demand. If companies ask for the source code, we could discuss of course.

paul_k_clark · October 2012

As @phongtt is pointing out Gideros has plugins. With plugins a software development house should be able to add any new feature or modify any existing functionality (by creating there own version of it). So (correct me if I am wrong) they would get most of the same abilities from the plugin system as they would gain from having the source code, plus the plugins would mean easier integration.

phongtt · October 2012

Hey everyone,

I'm interested in this battle, will you join Gideros army?

http://www.gamefromscratch.com/post/2012/09/21/Battle-of-the-Lua-Game-Engines-Corona-vs-Gideros-vs-Love-vs-Moai.aspx#comment-669732511

gorkem · October 2012

@paul_k_clark you are right. Plugins can do most things except in its current form, developer is not allowed to modify OpenGL layer at the moment.

"Modifying existing functionality" can also be done for Lua functions, which is already being implemented by Arturs, Andy et al.

bowerandy · October 2012

@gorkem, Lua is an incredibly flexible language which allows one to change fundamental parts of how it works. Witness the class system and @ar2rsawseen's new GiderosInit library, for example. Similarly, the ability to use plugins reduces greatly the chance of discovering a road block while developing. This is what gives me confidence that Gideros is a good tool to develop with. I know that modifying the OpenGL layer isn't possible right now so I wouldn't choose to start a project where I thought that might be necessary.

However, what open source or the ability to purchase source does is to give developers confidence that, if Gideros were to go under, all their development effort would not be in danger. You have quite a small Bus Number you see,

I'm not sure what happens at the end of your yearly subscription period. I'm assuming that I will continue to be able to compile my code even if I don't renew my subscription (perhaps you could clarify this, even though it isn't the subject of this post).

However, even so, if Gideros disappears (heaven forbid) and it is not possible to renew the subscription then most developers will want to have confidence that there existing code will still work EVEN IF iOS or Android changes in future. Only by having the backup of full source (paid for or otherwise) can you do this.

Now for most Indie developers, their time investment may not warrant paying a large amount out to guarantee safety. But having the option to do so is important. For example, I have spent 6 months so far working almost full time on Gideros related stuff. If I was to charge myself out at reasonable rates (say $750 per day) this is $97,500! So, if you were to offer me the option to insure my investment by allowing me to purchase the Gideros source (under a suitable NDA) for $5,000 or $10,000 - I might even consider it.

Actually, in my case I probably wouldn't, at least not for this amount. But for a professional shop creating apps with teams of developers, having this option will most likely be important. If nothing else, having such an option would be another check mark in a box for anyone considering using Gideros in future.

Just my 2p

best regards

gorkem · October 2012

@bowerandy if your subscription ends, your account will be downgraded to "free" license, and you'll work as if you didn't buy a license at all. You will be able to compile your code. This is exactly same as getting another account and start all over.

I enjoyed your post a lot btw, thank you. (urges me to think on this matter three times more).

john26 · October 2012

Regarding the open source thing, I was thinking perhaps you could allow collaborations on the source code with people you trust. For example, let's say someone wants to run his Gideros app on BlackBerry and knows the BlackBerry system. After signing an NDA and paying a fee, this person could have secure Telnet access to a sandboxed version of Gideros. He can then edit the source to allow the changes he wants but he is not allowed to copy, transfer or print files (the Telnet program would not allow copy/paste etc). At the end of the collaboration period, he can take away an executable with his changes but not the source code. You would then have the new source and can decide whether to merge in with the official Gideros and release as a new version. This seems like a win-win situation. Of course, you would only allow collaboration with those you trust and a (substantial) fee would discourage time wasters and casual pirates.

Instead of operating by telnet, the person could even work at your location if this is mutually convenient. You could have a policy of confiscating memory sticks etc!

Another thing is some people only want to read the source code but not change it. In that case you could prepare a PDF of the source code which cannot be printed, copied, or converted to a text file. It's possible to add this sort of DRM to PDF files. Then people can see the source but would not be able to recompile it giving you complete control over Gideros.

Of course, neither approach is completely safe, there is always the "analogue hole" whereby people can take screenshots and scan the result to recreate the source code in a text file. However, this approach is so tedious, most casual pirates would be discouraged. A serious pirate will crack anything, there's no point trying to stop them!

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Comparison report - "Battle of the Lua Game Engines"

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Comparison report - "Battle of the Lua Game Engines"

Comments