Construct 2 - Realistic State after 1 gazilion downloads

I'm of a view that what others can achieve, so can I, if i am talented enough. When I see other C2 games running flawless on mobiles, I don't blame my tools.

I'm of a view that what others can achieve, so can I, if i am talented enough. When I see other C2 games running flawless on mobiles, I don't blame my tools.

Your view is simply misguided. Some things work, and using strictly those things will produce good games. But many don't. I mean, if I'm trying to make use of playback rate in my mobile game, that's just not supported in mobile chrome at all, but is in desktop chrome. There's nothing I can do about that, so that layer of polish necessary to make my game something I'm proud of is not something I can do. If you don't need that in your game, obviously you'll think there are no problems. There are many things like this in C2 and the various HTML5 implementations and wrappers.

Also, given that C2 has been around for so long, can you list 10 mobile games that are complex and run well on Android and IOS? Can you list 5? Where are these inspiring examples, I want to be inspired too.

—

yesterday you wrote "In summary, my opinion is that for smaller games, CocoonJS is actually fantastic for Android and iOS, but bigger games is where it falls flat on its face due to poor memory management, but its something Crosswalk can do (for Android only). Know the limitations and work within and around them."

today you wrote : "Both CocoonJS and XDK exporters work great now and XDK is improving so quickly (its already better for Android, minus the Google Store support)."

sorry but im a bit confused..improving is far away from stable.and i have to agree with Juryiel that if people wouldn't complain about them every month (or every day?) things might be worst than today...

i dont say c2 is crap im saying that it have major issues and other game engines work better in mobile gaming.

There is a trade-of with features and ease of use, if you want more features Juryiel you would have go towards a more native engine.

I have used AndEngine with the Android SDK briefly before switching to C2, it does many things great. But its a bitch to use. So while it could make a better game, but I could not (due to limited talent) using it. I could make a better game with C2, that's why I switched.

spy84 it's going to come down to HTML5 itself, other native engines work better for mobile gaming because HTML5 itself is still maturing, and as such its improving constantly. The question is why are you wanting to use a HTML5 game engine in the first place? Obviously for the cross-platform and browser-games. If you want something dedicated to mobiles, then yes, there are better options.

Edit: I see C2 as "having your cake and eating it too" for non-chefs, but we all know thats not realistic and it's more along the lines of "having a cake-like dessert and eating it too". Only that doesn't mean it's not tasty. For the real chefs, go native.

Edit2: As for complaints, I do it heaps too regarding CocoonJS, you can see me posting heaps about it, its lack of memory management, its horrid permissions, stupid blinking logo. I also complaint in the Intel XDK thread, the massive 25mb overhead, which is now reduced to 16mb, the sound bugs, which is now fixed. etc. Feel free to complaint but ultimately, you work with what you have and if you choose to go with HTML5, you will have to deal with the compromises but gain a very good easy to use game engine.

There is a trade-of with features and ease of use, if you want more features Juryiel you would have go towards a more native engine.

I have used AndEngine with the Android SDK briefly before switching to C2, it does many things great. But its a bitch to use. So while it could make a better game, but I could not (due to limited talent) using it. I could make a better game with C2, that's why I switched.

It's not about more or less features. It's about the features that C2 already has that don't work on all of its supported platforms. And the 'features' I'm talking about are just basic stuff, not really features at all. Massive stutter even though the game runs at 60fps when creating 3 sprites / sec and destroying another 3 / sec on a tegra 4 device. I expect better. Until recently sound issues were horrible, and were only fixed like this week mostly, though some still remain. There are many other basic issues that you may not run into in your specific game. In my game, sprites don't show up correctly on all devices (I test on 3 or 4 different ones all of which are between 1.5 years old to brand new, and haven't even gone to iOS yet, I dread that) when I'm overlaying one on top of another. Works on most devices so you might not see it, but that's only because your testing is poor. Look, honestly, I'm not interested in how well your specific game runs and neither is anyone who is having issues with how THEIR game runs and what bugs they are running into given their specific needs. Your experience doesn't somehow make everyone else's problems not exist. Can I work around the bugs? Sure, but my game would be sloppier and less polished, OR I would need to add in many more hours of work to implement workarounds, so at that stage I'm just better off using other tools.

You work under the assumption that Chrome has this awesomely ideal webgl implementation when that's just not true. Compare Chrome to Firefox, you'll see Firefox gives significantly less FPS. But a better html5/webgl implementation that is game specific could do much better than Chrome, which Crosswalk is based on.

And I do use more native engines. That's not the point. Unless you meant to agree that C2 is not ready and people should therefore use other things until it is.

And I'm still waiting to see these inspiring mobile games.

Also yesterday Arima didn't think a large complex game with heaps of assets was possible. But it is when he tried Crosswalk.

People don't think a complex game with heaps of object collisions, particles and large animated sprites are possible. But it is. These things are possible, so again, making a game that's large and complex is entirely different to making a successful game, because the latter requires luck, marketing and talent.

im going where i want mate.even if i am real chef even i am not.When i pay for something which says i export in android almost like native, i with no programming skills and no knowledge count on it. thanks to c2 i saw things i learned alot but i feel not very comfortable.sometimes i love it sometimes im wondering...

I love C2 so far. I'm not using it to make the next big game, though. I'm using it to make short, simple, fun web games, so I'm more the demographic than, say, someone like the OP who wants C2 to be something other than it seems to be.

Ashley has explained his reasoning on this issue to me before, and I bought it. I'd rather see new design-related features and minor tweaks to optimizaiton continuously pop up then see all of that go by the wayside while the very small team at Scirra (3 people?) try to tackle their own exporter, which would be inane because they'd basically be assuming that they could do a better job than Google and other companies who specialize in HTML5 exports.

If native exports mean so much to you, there is Stencyl 3.0 now, which is a nice tool by itself, but harder to learn (not THAT hard though). Then there's GameMaker, of course, but you'll have to pay a lot for their "YoYo Compiler" in order to have access to high performance exports. Furthermore, neither of those engines have C2's advantages (super easy visual effects, etc... Stencyl doesn't even have a particle system yet).

So, you do have options. It's possible that better exports will come in the future, and I'm sure they will! But it won't be Scirra themselves who bring them to us.

> There is a trade-of with features and ease of use, if you want more features Juryiel you would have go towards a more native engine.

>

> I have used AndEngine with the Android SDK briefly before switching to C2, it does many things great. But its a bitch to use. So while it could make a better game, but I could not (due to limited talent) using it. I could make a better game with C2, that's why I switched.

>

>

It's not about more or less features. It's about the features that C2 already has that don't work on all of its supported platforms. And the 'features' I'm talking about are just basic stuff, not really features at all. Massive stutter even though the game runs at 60fps when creating 3 sprites / sec and destroying another 3 / sec on a tegra 4 device. I expect better. Until recently sound issues were horrible, and were only fixed like this week mostly, though some still remain. There are many other basic issues that you may not run into in your specific game. In my game, sprites don't show up correctly on all devices (I test on 3 or 4 different ones all of which are between 1.5 years old to brand new, and haven't even gone to iOS yet, I dread that) when I'm overlaying one on top of another. Works on most devices so you might not see it, but that's only because your testing is poor. Look, honestly, I'm not interested in how well your specific game runs and neither is anyone who is having issues with how THEIR game runs and what bugs they are running into given their specific needs. Your experience doesn't somehow make everyone else's problems not exist. Can I work around the bugs? Sure, but my game would be sloppier and less polished, OR I would need to add in many more hours of work to implement workarounds, so at that stage I'm just better off using other tools.

You work under the assumption that Chrome has this awesomely ideal webgl implementation when that's just not true. Compare Chrome to Firefox, you'll see Firefox gives significantly less FPS. But a better html5/webgl implementation that is game specific could do much better than Chrome, which Crosswalk is based on.

And I do use more native engines. That's not the point. Unless you meant to agree that C2 is not ready and people should therefore use other things until it is.

And I'm still waiting to see these inspiring mobile games.

For starters, I am personally inspired by Magnetized and recently Street Kungfu, it just shows what one person can do quite quickly with C2. The former is already a success while the latter is new. I don't have a giant list for you, but I only need one, because if one man/game can do it, that gives me inspiration to work harder and be better. Again my view may differ to yours on this.

All of the issue you posted are not unique to C2 sorry, native engines have heaps of bugs too and plenty of device crashes. All you need is to view the feedback of users on even popular games made by massive companies. The fragmentation of Android is to blame. No matter what tool you use, you will be bug-hunting.

For starters, I am personally inspired by Magnetized and recently Street Kungfu, it just shows what one person can do quite quickly with C2. The former is already a success while the latter is new. I don't have a giant list for you, but I only need one, because if one man/game can do it, that gives me inspiration to work harder and be better. Again my view may differ to yours on this.

All of the issue you posted are not unique to C2 sorry, native engines have heaps of bugs too and plenty of device crashes. All you need is to view the feedback of users on even popular games made by massive companies. The fragmentation of Android is to blame. No matter what tool you use, you will be bug-hunting.

The difference is that developers of said engines / exporters, native or otherwise, are working to fix those bugs, acknowledge them, provide timelines for fixes, etc. C2 tells you to 'hope for a brighter future' and some sort of Messiah like Intel or Ludei because they themselves are unable to do anything, given their setup.

The difference is that developers of said engines / exporters, native or otherwise, are working to fix those bugs, acknowledge them, provide timelines for fixes, etc. C2 tells you to 'hope for a brighter future' and some sort of Messiah like Intel or Ludei because they themselves are unable to do anything, given their setup.

Intel XDK have been very good with their feedback handling, they have given estimated timeline for fixes and have delivered. Currently its able to handle large complex games, audio issues are fixed, screen orientation fixed and its improving quickly.

Certainly its true, Ludei have been left wanting.

>

> The difference is that developers of said engines / exporters, native or otherwise, are working to fix those bugs, acknowledge them, provide timelines for fixes, etc. C2 tells you to 'hope for a brighter future' and some sort of Messiah like Intel or Ludei because they themselves are unable to do anything, given their setup.

>

Intel XDK have been very good with their feedback handling, they have given estimated timeline for fixes and have delivered. Currently its able to handle large complex games, audio issues are fixed, screen orientation fixed and its improving quickly.

Certainly its true, Ludei have been left wanting.

And maybe Intel will be the solution. Maybe not. We're still not there yet, for me, I have a well-done, optimized, polished mini-game done but publishing is not possible at the moment because of remaining bugs. So again, your assertions that things are fixed are not really relevant to me. And because of that I wouldn't even dare think to start a serious project in C2 for mobiles.

I was actually originally hoping to port the MOBA-style combat engine I built in CC to C2, but it's a big project and given my mini-game doesn't perform, I don't wan tot invest the time. Instead I started porting it to unity.

And if you use a native engine and it has bugs... what then? Here you assume its the fault of the engine itself. What if its not and its the fault of your implementation? Because I see other people's game running fine on mobiles, i would therefore have to assume its not the engine's fault. It may be a wrong assumption to you, but to me, if I see others achieving something using the same tools that I am but I am not achieving it, I assume its me and not the tools.

Lets agree that things could improve more and leave it here.

And if you use a native engine and it has bugs... what then? Here you assume its the fault of the engine itself. What if its not and its the fault of your implementation? Because I see other people's game running fine on mobiles, i would therefore have to assume its not the engine's fault. It may be a wrong assumption to you, but to me, if I see others achieving something using the same tools that I am but I am not achieving it, I assume its me and not the tools.

Lets agree that things could improve more and leave it here.

Your assumption that 'if someone can do X I should be able to do X' is not just a wrong assumption to me, it's a wrong assumption period. If someone can do X I can also do X, but I'm actually trying to do Y and not X, so your assumption doesn't apply. That's the whole point. The fact that you have no problems because you're trying to do X doesn't mean that someone trying to do Y won't have problems.

If I have a bug in my own implementation, which is surely possible, I can send code to other users to look over or look over it myself. But I'm talking about known issues in html5/webgl implementations of chrome, on which Crosswalk depends.

If we're not talking about bugs but actual engine features, then if I use a particular native engine and I want to do Z and it doesn't do it, do I then blame that engine also? You do what your engine is capable of, if it isn't capable of doing what you need it to, then use another engine.