Construct 3 - many questions (native exporterts)

From the Asset Store
Casino? money? who knows? but the target is the same!
  • Y'know everyone's rambling about native exporters but do they have any idea what they're asking?

    A native Windows export would be great, sure, but it's 2015, man. You think that's going to cut it? Hell no.

    There's Windows, Mac, Linux, Android, iOS, PS4, PS Vita, XBone, WiiU, 3DS, and Browsers... And those are just the big platforms of today. What's going to be out there 5 years from now? Many of these platforms might even be obsolete by the time Scirra finished making exporters for them!

    Better yet, take a look at Unity's native exporters

    BLAM

    Most game engines couldn't compete with that if they wanted! Scirra included. So they stick with HTML5...and you can't say C2 isn't the best HTML5 game engine out there.

  • i'm not for native exporting. i'm against it.

    while they waste 6-18 months of development for native, we could get massive features and stuff, so no point.

    funny thing though is - if you follow up the news - bits and pieces of javascript are compiled into native sources (asm.js anyone? firefox anyone?)

    so that subsets of javascript run natively. performance increase is massive and games run fluently (firefox demonstrated).

    what does that mean ? we could make a JS/HTML5 game and run it everywhere. PC/PS/mobile and all the other stuff from post above.

    funny thing though - while you guys whine and complain, you could have already made 3 games and earned your first 100$. stop complaining and make games.

  • paradine - you're right, it makes more sense to file a bug directly with NW.js. Have you done that?

    The biggest bottleneck of C2 is most assuredly non-native exporters.

    Everything is a tradeoff. Making native exporters does not make everything in to a magical perfect world - it will trade performance characteristics for far slower development time, longer bug fixes, more difficult maintenance, slower rate of new features being added, and even new kinds of bugs (for example, browser engines implement a long list of graphics driver bug workarounds, which we will have to reimplement if writing our own engine). All of this would probably also make the product more expensive. My point is I'm asking is that all really worth it? Is HTML5 performance really that bad? If HTML5 will be perfect - literally native-grade - within say 2 years, why bother taking a detour now? (If that sounds ridiculous, consider that in 2011 when we first launched, no mobile browsers ran HTML5 at all, then for a couple of years they ran it incredibly slowly, now they run it reasonably fast but with the odd frameskip. It's really come on so ridiculously far in the past few years I think it's perfectly reasonable to imagine it being native grade within 2 years.)

  • Ashley

    [quote:1lzkra4f]If HTML5 will be perfect - literally native-grade - within say 2 years, why bother taking a detour now?

    It's nice that Scirra is earning money on technology that might be reliable after next 2 years, but you should also ask yourself one question: Would you risk to sell C2 made game, i.e. exported to desktop or Crosswalk, knowing that you can't do anything IF your customers will have problems with your game? And that they will i.e. laugh at you and give 1-star reviews hearing excuses like "We can't fix this problem now, please wait a few months for Chromium team..."?

  • people have problems with every game.

    it's developers OBLIGATION to make a clean bugfree (or at least non gameplay intrusive) bugfree game. if you're going to blame c2 for your bad deveopment skills then i have some bad news for you...

    also - look at the latest batman arkham knight - what a piece of crap that game was on PC. it ran ok on PS, xbox, but was crappy on PC. you don't see them whining about export and shit. they just went to remake the bad parts, and trust me there's a lot more to be done on game devs game then on their engine side. and guess what - that was supposed to be NATIVE game. that ran like crap.

    point is - if you make a html game that runs badly - you probably made some things that make it run badly. not even native will help you. example:

    people using 2048x2048 images and rotating it or something like that. <- this is idiotical because it uses around 900MB/s bandwidth. also add 3 more images like that - 3,6GB/s. good luck finding a card that can process stuff that fast (unless you have titan X or such). there's a lot of other stuff that people complain that is C2 bug / fix / not native but people have low knowledge and usually do things wrong and start accusing others because that's the easiest thing to do.

    so i recommend you leave programming/dev area if you can't dive deep into your problems and learn and fix them. i've spent over 14 years in programming( c,c++,c#, JS, Java and more), i know when to detect difference in my bad code vs performance heavy construct being used wrongly. problem is that most of people here do not. especially because they expect magic with events and not understanding what works behind them.

    p.s. to anyone who wants to understand performance better - export your game without minimize, open c2runtime.js, go through code and read online javascript problems and performance issuses - you might learn something instead of whining how "rotate behaviour works slowly".

    i'm really tired of reading noobs and nooblets on this forum whining about the same thing over last 9 months.

  • [quote:2dvrtptq]i've spent over 14 years in programming( c,c++,c#, JS, Java and more)

    With such experience you should join Scirra dev team.

    I'm serious

  • Ashley

    [quote:2fet3nbx]If HTML5 will be perfect - literally native-grade - within say 2 years, why bother taking a detour now?

    It's nice that Scirra is earning money on technology that might be reliable after next 2 years, but you should also ask yourself one question: Would you risk to sell C2 made game, i.e. exported to desktop or Crosswalk, knowing that you can't do anything IF your customers will have problems with your game? And that they will i.e. laugh at you and give 1-star reviews hearing excuses like "We can't fix this problem now, please wait a few months for Chromium team..."?

    Imagine we made a native Android exporter, then your game crashes on a bunch of devices due to an obscure bug in the Qualcomm Android graphics driver. (This should not surprise anyone, it happens.) This is exactly the same situation: some third party is screwing up the game and there's not much either us or you as the game developer can do about it. In fact, it's worse, because even if Qualcomm are receptive to bug reports (which I doubt given my past experiences with other vendors), when was the last time you updated the graphics driver on your phone? It effectively never happens. So there is basically no hope of it being fixed, short of waiting for everyone to throw away their old phones and buy newer ones. Then people would probably be on the forum with posts exactly like yours, but just talking about Android compatibility instead of Crosswalk, and instead of "please wait a few months", it's "hopefully next year's devices will work".

    Moving to native doesn't solve the problem of third parties screwing up the game. In comparison, having a company the size of Google handling device compatibility and pushing updates out every 6 weeks is pretty great compared to what happens with drivers, which is what a native engine would be directly interfacing with. Also drivers are not the only third party involved; a native engine would probably need a few third party libraries to cover some features which a browser has built-in (e.g. graphics, audio, networking...) and these libraries could have their own list of issues, and so on.

    No platform is perfect, and I think it's easy to think the grass is greener on the other side. Remember we do have native tech experience with Construct Classic's runtime, and the C2 editor itself. Graphics driver bugs in the C2 editor have been a major ongoing pain with many extremely difficult problems and is still one of the top causes of crashes in C2, and that's on Windows which is more mature and less fragmented than Android.

  • i've spent over 14 years in programming( c,c++,c#, JS, Java and more),

    I guess. either that's not truth or you are a bad programmer, othewise why would programmer use engine without coding?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • paradine If you can do the same thing 10x faster with an engine like C2 you probably use it instead even if you know how to code. And I guess that if he wants to add something he could with his knowledge in coding.

    I use coding when I work in unity and unreal engine. But for 2D they can't even compare with the speed of C2

  • Ashley

    I can't agree with your logic that we would whatever depend on third-party plugins.

    I guess, it's better to depend on 3 third party plugins than depend on 5 or more.

    It's like I would say "Ashley, I want to buy my own house, because I want to be independent from my parents", and you would say "Paradine, it's senselessly, because you will still depend on air to breath."

  • My small test proves that native export is required even if you make a simple game with no behaviours and only one simple event.

    My test contains 5 moving 64x64 squares. The only behaviour they have is "wrap".

    APK - it runs 40-45 fps and 8-13% cpu on my mobile device (Apk is made via last version of intel XDK and crosswalk 11)

    HTML it runs 58-60 fps and 9-11% cpu on the same mobile device

    .CapX

    This test proves that Intel XDK kills about 15 fps in a very-very-very simple game.

    And now imagine what will happen with complex games.

    P.S. Later I can show you the same test built via native apk-export - you will see the difference. It is great.

    I played a little with your file, could you test this for me exporting over intel xdk and check the results ?

    Now, the FPS might not be optimal ... but ... do me a favor and check how you experience the movement

    edit:

    > i've spent over 14 years in programming( c,c++,c#, JS, Java and more),

    >

    >

    I guess. either that's not truth or you are a bad programmer, otherwise why would programmer use engine without coding?

    Been programming for near 20 years ... I can write in lots of different assembly languages and a buttload of scripting languages ....

    C2's potential for rapid development wipes the floor with each and every language I have used.

  • paradine - i use c2 because of simplicity and it's all i need (i love 2D games). that's first reason. 2nd reason is that my experience with directX programming is lesser. i could dwell into it for about 2-3 years and another 2-3 years of depth math problems with matrices and transformations to be able to build ONLY ENGINE (graphics) for a game. so yeah, it's a waste of time + i have no need for that. 3rd - i'm very good with desktop / mobile apps written in C# XAML/WPF and such, and web apps in Java. and 4th and last - i have a steady job and makin' games is my hobby - so i definitely don't have time to waste on what i mentioned in point 2. oh, and no 5. - today people use (let's say AAA games) already built engines that were developed by hundreds over a few decades (unreal, crytek, etc..) Oh want physics ? (havok) etc..

    the point of programming is not to do something, it's to do something right. you should really know some concepts of good programming that can be applied to c2's game building, though it's much more simpler.

    here's some help for you:

    https://en.wikipedia.org/wiki/Software_ ... nt_process

    https://en.wikipedia.org/wiki/Requireme ... activities

    https://en.wikipedia.org/wiki/Software_architecture

    https://en.wikipedia.org/wiki/Software_design

    https://en.wikipedia.org/wiki/Coding_conventions

    http://www.ibm.com/developerworks/websp ... erks2.html

    and more...

    once you dwell deep into this and understand all of it, and start applyin' it, you will see the difference in your programming / coding / eventing

    mcuh more clearer. oh yeah, also it's a rabbit hole with no bottom. i've jsut thrown here some links but i'm sure you can find much much more. don't get me wrong, i don't think you're stupid or something, i just think people need to learn this so they can understand stuff more.

  • I just see other engines which run smoother without all the hiccups, and skip-ups that C2 has had problems with. (especially on mobile.) I would like an Android native exporter.

    If C2 looks, feels, acts, tastes and behaves like native grade, then I will be happy. Very Happy...

  • saiyadjin has a very good point. Yes, there are performance issues with browser engines that are not our fault...but I think there are a lot of problems that simply stem from bad design, and a lack of understanding about what limitations mobile presents.

    I think a lot of that bad design stems from people thinking that, with C2, you can be lax about how you design your game, because the editor and the engine will take care of you.

    Well...it won't.

    A lot of people that they can build a full game as easily as a prototype.

    But...you can't.

    It's a lot more work. A LOT more work.

    You have to plan things out, organize your events sensibly, take notes, keep a changelog, modularize your logic to avoid the nightmare of WET design, make sane intelligible comments, keep those comments up to date (harder than it sounds), work out a consistent workflow for asset management, understand best practices for triaging bugs, understand common logic patterns, ...the list goes on...and on...and on.

    The difference: with 'proper' game engines, you have to know most of this stuff to get anywhere in the first place. C2 is more lenient, but because of that people end up with inefficient, redundant, brittle logic that is poorly organized and nigh indecipherable. This still works...until something breaks and they have to try and make sense of their hot mess.

    At this point the whole project generally falls apart, and there is rarely any way to put it back together short of starting from scratch...hopefully with a clearer vision of the goal, and a better understanding of how to put the pieces together.

    //Rant(ish)

  • I think a lot of that bad design stems from people thinking that, with C2, you can be lax about how you design your game, because the editor and the engine will take care of you.

    I'll second the point. I've made enough game and other programming goofs to know that good design means good programs, and even the best engine can't save a bad design from eating all the system resources.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)