2D WebGL engine for mobile

[arnuschky]

Hello,

we're currently evaluating several game engines because we have to move away from our current one. Our game is a simple 2d game, which is, apart from some physics and particle effect, rather simple. Nevertheless, performance on canvas was not sufficient, so we are now looking for a WebGL engine that is well supported on mobile.

So, what engines are out there that are stable and mature? Required feature set:

 - 2d physics (preferably box2d)

 - particle effects, but we can do it ourselves

 - multi-channel sound

 - dynamic loading of assets

 - support for sprite atlases

 - preferably tested on CocoonJS 

 - multi-touch support with gestures

 

By dynamic loading of assets I mean the loading and unloading of spritemaps/textureatlases dynamically on scene change. This is a feature that is quite essential on mobile device with their rather limited memory, but very few engines support this.

Cheers,

Arnuschky

[Ezelia]

 Our game is a simple 2d game, which is, apart from some physics and particle effect...

well, box2d physics + particle effects is a combination that kills the performance, your issues are not due to the game engine actually.

and there is no WebGL engine specifically designed for mobile, for exemple Phaser is a multiplatform engine using Pixi Rendering engine witch support both Canvas2D and WebGL but since most mobile browser don't support webGL your only option is to stick with canvas.

btw, if you wrap your game with cocoonjs, it'll use hardware acceleration and a native box2d implementation so you can just write your game with any Canvas2D engine and use integrated coccoonjs box2d instead of the external JS implementation. 

[arnuschky]

You are correct, physics and particle effects kill performance. Unfortunately, we have found that it's not these two components that make our game slow (they are only "bywork" of the game and not at its core). It's simply the amount of actors on the screen, overlays, sprites etc. In any case, we are using CocoonJS with native box2d, but still, canvas is too slow.

 

That's our primary reason why we want to switch to a good WebGL engine.

[rich]

As you're having to create a native app anyway why not use something meant for doing that? Unity, Corona, etc?

[arnuschky]

As you're having to create a native app anyway why not use something meant for doing that? Unity, Corona, etc?

 

That would be an option, yes. It's just that one the one hand we like the ease of the Javascript workflow, and on the other hand already invested quite a lot of work into the game. Rewriting everything using another language might not be worth it (even though switching engine comes close).

[arnuschky]

Furthermore: we develop on Linux, and if I understand correctly both the Unity and Corona SDKs do not work on Linux. We also would prefer an open-source project over a closed-source one.

[rich]

Understood, and without wanting to sound like a jerk, did you not do a feasibility test before you started work? I mean surely you could have told really early on "this just isn't going to be fast enough? Design for the platform, at the end of the day that will limit you more than any engine. If you change platform (browser to native) that's a quantum shift of a change, so expect plenty of rewriting imho.

[AshleyScirra]

Construct 2 covers all the points you mentioned including scene-by-scene image loading for memory management. However, CocoonJS does *not* currently support that even though our engine does, due to really poor memory management around Image objects, and they've not changed it despite much protesting from me for a long time! C2 is also Windows only and closed-source.

[arnuschky]

Understood, and without wanting to sound like a jerk, did you not do a feasibility test before you started work? I mean surely you could have told really early on "this just isn't going to be fast enough? Design for the platform, at the end of the day that will limit you more than any engine. If you change platform (browser to native) that's a quantum shift of a change, so expect plenty of rewriting imho.

 

Yes, you are very right about that. Of course we did an initial feasibility test, but as always with tests you can't avoid testing for the wrong thing. We ran into this tight spot due to several reasons:

 

 - immature technology/frameworks resulting in more limitations that initially anticipated

 - serious feature-creep on our side

 - lacking experience on our side with mobile development

 - lacking support for mobile in the html5/js frameworks

 

We tried to avoid the snag we're in by using an engine that supports canvas and WebGL (it's called CAAT). This gave us the option on upgrading to WebGL once CocoonJS supports it. Unfortunately, CAAT's development has come to a halt and its WebGL support is broken. We can fix this support of course with some serious effort from our side, but it doesn't get us around the problem of relying on a dead engine.

 

The other big issue is that resource management is essential on mobile, and simple not possible in a straightforward way on html5/js. For example unloading of sounds isn't possible at the moment. 

 

So yes, we might need to take the hit and switch to a new engine or even language - but if we do that we must be 100% sure that everything we need works. 

[arnuschky]

Construct 2 covers all the points you mentioned including scene-by-scene image loading for memory management. However, CocoonJS does *not* currently support that even though our engine does, due to really poor memory management around Image objects, and they've not changed it despite much protesting from me for a long time! C2 is also Windows only and closed-source.

 

Yes, I think I saw your posts on the Ludei forums. They added the dispose() method which seems to do the trick - at least it worked fine for us for unloading our sprite atlases between scenes. We considered using Construct as well, but feared that it's rather rigid framework wouldn't fit our needs. And the Windows thing, of course.

[rich]

Fair enough, I don't envy the position you're in! Personally considering your list of requested features I think you're going to have a tough time finding a browser based engine that will be flexible enough, but the Linux requirement removes loads of native apps packages like Unity too.

 

Rock and a hard place

[arnuschky]

Thanks, we just came to the same conclusion - especially after doing an afternoon of reviewing CocoonJS using different JS games/engines. (Basically, it's not very stable and seems to be very non-uniform behavior across different devices.)

 

So we might go native, but as you say the big cross-platform SDKs are all Windows or Mac. Seems like I will need to buy a Mac at last.

[rich]

Well buying a PC would be a fraction of the cost! (I still use them for all my day to day work, just have a Mac for traveling and it's the only way to debug Mobile Safari!)

[arnuschky]

Well buying a PC would be a fraction of the cost! (I still use them for all my day to day work, just have a Mac for traveling and it's the only way to debug Mobile Safari!)

 

True, and if it would be only for compiling/testing, we would go that route. But as Linux users we have a lot of unix depended workflows that will work on Mac and will be a pain to move to Windows. In a pinch, I could get the majority of tools from Linux installed on Mac - doing the same thing with Windows is quite impossible. And we're console jockeys, actually clicking on things is just horrible.  

[Aduros]

Have you checked out Flambe? It hits all your requirements: https://github.com/aduros/flambe

 

It's being used by some really impressive HTML5 games and apps: https://twitter.com/FlambeGames

[jamesaustin]

Have you considered or evaluated the Turbulenz Engine?

 

From the items you list it supports:

1. 2D WebGL rendering engine
2. 2D physics
3. Particle Effects
4. Multi-channel sound
5. Dynamic loading of any assets
6. Support for sprite atlases (see Save the Day)
7. Multi-touch
8. iOS and Android native application support via Turbulenz' native solution (or CocoonJS if you prefer)
9. SDK and tools all run on Linux
10. Open source
11. Support for mixing canvas API rendering on top of non-canvas rendering

[Ezelia]

True, and if it would be only for compiling/testing, we would go that route. But as Linux users we have a lot of unix depended workflows that will work on Mac and will be a pain to move to Windows. In a pinch, I could get the majority of tools from Linux installed on Mac - doing the same thing with Windows is quite impossible. And we're console jockeys, actually clicking on things is just horrible.

 

We was in the same situation, but managed to get a *nix/win workflow working just fine using cygwin to get linux tools on windows + native ports.

nothing is impossible for linux nerds most of the time the only obstacle is more ideologic than technical.

[arnuschky]

Thanks everyone for the suggestions. 

 

We looked into Turbulenz, and while it seems to be "as good as it gets" in terms of professional, mature and well-supported engines for HTML5 games, we decided not to use it.

 

The main reason behind this is that going HTML5 on mobile is insane. We simply realized that when you go mobile, the focus should lie on a stable base platform as there are soo many different devices out there and fragmentation (especially for Android) is huge. Support is a nightmare in such a scenario with an unstable platform.

 

For example, we decided against CocoonJS for example because after 1 year of fiddling and talking to their support they are still not capable of fielding a product that is even remotely stable or supports all the necessary features. (Turbulenz offers a similar solution, but it's an early beta and we don't trust it enough.)

 

This is partly due to the fact that HTML5 and javascript have been build for a different environment than mobile. For example, there are many facilities that deal with slow networks, which is not an issue when you load from an SD card. On the other hand, there is little control over resources and memory management, something rather essential on mobile.

 

In the end, putting a HTML5 game on mobile is fine if the game exists already and is used on the internet/with a normal browser as well. Starting a game targeted at mobile using HTML5 is just not very practical.

 

FYI, we decided to go with Marmalade Quick to get a stable base platform paired with a rapid development cycle similar to HTML5. Only drawback: windows...

[rich]

I agree with your conclusion, but just for a little balance I've seen whole teams spend weeks having to balance out code and compiler directives to get Unity games to work consistently across devices, re-writing shader code, modifying X, Y and Z just to keep it stable.

 

In short: nothing is 100% foolproof. But I do believe you at least started off in the right camp. I don't believe it will be a pain free exercise though.

[arnuschky]

I agree with your conclusion, but just for a little balance I've seen whole teams spend weeks having to balance out code and compiler directives to get Unity games to work consistently across devices, re-writing shader code, modifying X, Y and Z just to keep it stable.

 

In short: nothing is 100% foolproof. But I do believe you at least started off in the right camp. I don't believe it will be a pain free exercise though.

 

Yes, of course. Pain is part of the game. We just realized that with our previous solution we spent the majority of our time with infrastructure works and still didn't end up with something stable.