Halfgeek's Forum Posts

  • The question is, what kind of game do you want to make and is it possible with C2 and Crosswalk? If it isn't, you either change your game or you look elsewhere. That is the price you pay for using a HTML5 easy to use game engine. The price is compromise because again, HTML5 isn't there yet.

    I certainly know people have problems, there's no need to say it, everyone troubleshoots and fixes bugs. The fact remains that if some have managed to make complex games work, then there is hope for myself personally, and so I try my best to make it work also. Either that, or I go learn proper programming and do it all native.

  • When did I say Crosswalk doesn't have bugs? Are you kidding me? I noted it was improving quickly.

    When you design for mobiles you compromise, especially so with HTML5. You make do with that works and redesign your game. If that doesn't fly with you, then go with a more native engine. HTML5 just isn't matured yet.

  • 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.

  • 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.

  • 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.

  • > 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.

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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.

  • So your gripe is the exporters wasn't working well a year ago, sure, I agree with that.

    But now and moving forward, I disagree. Both CocoonJS and XDK exporters work great now and XDK is improving so quickly (its already better for Android, minus the Google Store support).

    So here and onwards, I don't see C2 as holding *Android* devs back. iOS is another story because its limited to CocoonJS and that means its limited to small games, so indeed, its holding devs back who wish to make grand games.

    But successful games comprise of many smaller games too.

  • What exactly is the fault with C2 that limits its ability to make successful mobile games?

    "where's ouya?android?layout by layout?"

    Ouya I don't know, but Android?

    Small game: CocoonJS works excellent. Look at Magnetized, Street Kungfu (new, but gameplay works flawless!). If someone can do that, why can't you? What's your excuse?

    Big game: Intel XDK works fine for me with its layout by layout memory management, others have used Leadbolt Ads on it too while waiting for AdMob.

    Layout by Layout?

    It already does that by default. It's only CocoonJS that does NOT. Intel XDK/Crosswalk does. It's already covered on the previous pages.

    So tell me again what's holding YOU back from making a successful game with C2??

    Making a game that runs well is not an issue, others have done it, I have done it. Making a SUCCESSFUL game is entirely another issue, because $$ success is entirely dependent on YOU.

  • Who would read it? Only other C2 users, no? But sure, i'll add it to the list.

  • I think the best way for the death animation is just to make a heap of varied sprites, each enemy say have 5 death animation and you can cycle through that. It achieves visually whats there, this would be the least CPU intensive method.

    The other way is just to spawn a lot of physics objects, 4-5 different object types per mob, ie. helmet, shoe, body gibs etc... PC will handle it fine, mobiles, no way.

  • spy84

    You say there's not many C2 success examples.. can you tell me why that's the case? Is it the engine itself that limits success?

    Because your insinuation is that somehow its the game engine's fault.

  • The best way is to learn from an example CAPX project that has a similar gameplay to what you desire. If its real time RTS theres a good tutorial in C2, just open up the example.