Construct 2 - Realistic State after 1 gazilion downloads

Sorry, but in my experience it's simply not true that Crosswalk runs faster than CocoonJS. Crosswalk does simply perform like the mobile Chrome browser would, while CJS is accelerated and can actually reach native-like performance in otherwise hopeless cases.

Your game may work good with Crosswalk, but it's also not crucial for that type of game to have smooth 60 fps or anything close to that. Don't get me wrong, I do like Crosswalk, but I also like to stay realistic about the way it performs currently.

I had FPS counters for both my CJS and Crosswalk build, practically the same, except CJS has stutters (probably due to too much memory use) while Crosswalk is smooth. And its 50fps on older devices, with Samsung S4 or Nexus 7 pegged at constant 60 fps. It is crucial for a fast paced physics shooter to have fast frame rate.

Because of how well Crosswalk worked, it inspired me to make another complex game, sandbox space RTS: Trade ships flying around to and from jump points to stations, patrols zooming about the sector, pirates looming and even big fleet fights between major powers. Missiles with trails, point defense lasers shooting missiles down etc. Heaps of particles, and rotating asteroids, planets and moons. So far its running very smooth on Tegra 3 devices.

Performance wise, I have zero complaints. Whats lacking are features, ie. Monetization, Social (Google play features).

As long as everything's running in javascript, the performance is never going to be as good as it could be, javascript is simply much slower than any native C++ code and theres nothing that can change that.

This is not the case at all. Yes, interpreted javascript is slower than C++, but that means nothing.

There are JIT compilers, for instance, and nothing prevents a native compilation from javascript to raw x86 code, generating equivalent performance to C++. The only limit is how "clever" the compiler is.

If you really want performance, the argument never ends: why not create the entire engine in C, which is much faster than C++? Why not create the engine in assembly? Why not create the engine in x86 instructions? There's no limit to how deep the rabbit hole goes - it's always a tradeoff.

Thing is, if you want to create a tool that is easy to program and can make use of the best (and bleeding edge) technology available, javascript is your best bet. Server side, there is very little that can go faster than javascript (node.js is way faster than .net, for instance). Desktop wise, we're playing catch-up, but we're almost there. Mobile, we still have a ways to go, but it will get there. The latest devices are already good enough, it's just a waiting game now, before they're widespread.

I might add to this that yes, C2 has some problems on mobile (it is more mobile that have problems with HTML5 but whatever):

(Before everything, I do HTML5, I bought C2 for that and not for pseudo-native applications or something else..)

-the fact is that if you plain on doing Web HTML5 you'll still struggle with that anyway, and would have to do even more work, but yes, it can improve, I agree on that point (even though it shouldn't have to improve on old devices that haven't what it takes to even read HTML5 I think, but just my opinion).

On the other hand, you have mobile via wrapper, yes:

-CocoonJS is something I never liked, I just ignore it, not a thing I'll ever use in my life, I'd rather not making .apk nor iOS apps than using it.

-Crosswalks is chrome for android, and since I am doing HTML5, it is perfect for my needs, my tests (without audio I must say) were great, maybe it is because I always program in a safe way, so i can optimise easily, I bet that crosswalks is already better than CocoonJS for some games, and it'l improve even more, not worried.

As for the marketing of C2, I agree that it could be clearer, but if you plain on buying it, the free edition is already a good bet to learn to use it, you can export to HTML5 that you can test on a mobile browser so you have a first look, and for cocoonJS, I'm not sure if you can package C2 HTML5 exports with it to test (I mean license wise, pretty sure you can upload HTML5 files to cocoonJS for testing in theory), I think we need an awnser to that question, so peope can test it first.

QuaziGNRLnose - at some point you can keep improving performance and it doesn't matter, because it's fast enough already (something Fimbul was getting at). CC was fast enough in many cases already, even when it used sub-optimal algorithms. In C2 we've had to work harder to get there since JS does have a performance overhead, but I believe it's fast enough: we still see many games bottlenecked on GPU performance, not CPU, and the number of CPU-bottlenecked games that go from unplayable to playable thanks to the performance improvement of a native engine is probably small. If you have any specific examples of games that cannot get good CPU performance out of Construct 2, please do send them over and I'll profile it and see if we can optimise the engine. Generally though people make vague references to poor performance in C2 but never send me such projects, or if they do, they are GPU-bottlenecked.

It's a long thread so I'll mention again: writing a compatible native exporter using SDL or whatever amounts to writing a new browser engine, something we are far too small to reasonably tackle in a way competitive with what the likes of Google, Microsoft, Apple and Mozilla can do. Writing an incompatible native exporter is just not very useful (see CocoonJS for an example of how annoying compatibility issues can be, and that's still got a fairly high level of compatibility). A smarter idea would be to rewrite the engine in asm.js, which can come very close to native C performance, and is still improving. But that would mean a complete rewrite of the engine, and possibly for no gain: GPU-bottlenecked games will see no improvement, and in many cases our carefully hand-written JS engine is fast enough anyway.

As for the security issues, I think you underestimate them. It is a problem with native tech, and the problem simply does not exist on the web. I think there is a huge difference between downloading an unsigned EXE from a website you've never heard of before compared to downloading a digitally-signed installer for Steam from Valve. Some administered systems may forcibly prevent unknown executables from running. Some non-technical users may simply give up if they find out they have to "configure DirectX" (we know this happened in some cases with CC games), or get scared off by a security warning (which is there for a good reason). There are several hurdles here, none of which exist with HTML5 games.

Writing an incompatible native exporter is just not very useful (see CocoonJS for an example of how annoying compatibility issues can be, and that's still got a fairly high level of compatibility). A smarter idea would be to rewrite the engine in asm.js, which can come very close to native C performance, and is still improving. But that would mean a complete rewrite of the engine, and possibly for no gain: GPU-bottlenecked games will see no improvement, and in many cases our carefully hand-written JS engine is fast enough anyway.

Ashley - I have to disagree on this point. I really think you're underestimating the value of a game engine without a complete browser feature list, and overestimating the value of those browser features. Looking at the tons and tons of games out there, an overwhelming majority of them could be made without a complete browser engine because they were made without a browser engine. HTML 5 tech for games is pretty new - so the games made without a full browser engine are the vast majority of all games ever made. That's clearly enough to make games with!

For example, I obviously can't speak for everybody, but none of the games I've designed and worked on have really needed anything that CC doesn't have (aside from exporting to other platforms and now multiplayer, which aren't exclusive to browser tech). Not one, and that's dozens of game ideas.

One of the main points is that you're making the choice for us, and you're choosing the option a lot of us wouldn't choose. If instead of writing the engine in asm.js and getting one platform, if you remade the engine in SDL or haxeNME or monkeycoder or some such, then you would only have to remake it once to get to a lot of platforms and - I admit I don't understand this process completely - but then couldn't you use emscripten to easily and automatically export to asm.js as well? I seem to recall reading it only took a week for them to get unreal engine 3 converted through it to asm.js. It would make the native exports AND the html5 export better! All for one code base rather than one for each of them (of course some tailoring would be necessary for each platform).

Doing that would be the best of all worlds - those who want more speed but not all of the features a browser supplies could have them, and those who want the extra browser features could use a faster web export through asm.js. Perhaps we could even continue using the third party plugins we've got if we want to export to HTML 5 (though I understand the third party js plugins would not have asm.js speed since they were not run through emscripten). It would give us the choice and option for either (and it's a choice a lot of us really, really want to have), would solve a lot of issues, make C2 look more like a serious development platform and would make a ton of us very, very happy!

As for the security issues, I think you underestimate them. It is a problem with native tech, and the problem simply does not exist on the web. I think there is a huge difference between downloading an unsigned EXE from a website you've never heard of before compared to downloading a digitally-signed installer for Steam from Valve. Some administered systems may forcibly prevent unknown executables from running. Some non-technical users may simply give up if they find out they have to "configure DirectX" (we know this happened in some cases with CC games), or get scared off by a security warning (which is there for a good reason). There are several hurdles here, none of which exist with HTML5 games.

There are tons of games out there which have the same hurdles, yet the PC remains a thriving place for games - in fact, indie games are thriving more than ever. A web browser by itself just isn't a proper platform for delivering a medium to large commercial game. People don't want to start up their web browser and go to a web page to play something they've purchased, by using an exe you can more solidly ensure compatibility since web browsers are in such a state of flux, and node webkit isn't totally immune to needing to update direct x either because it uses ANGLE and therefore direct x for rendering by default and comes with a dx installer because of it.

Regardless, if you did what I mentioned, it would again give us the option and choice. I respect your opinion on the matter but disagree, and I think we should have the options to make our own choices about which method of delivery to pursue. We could even do both and let the customer decide!

I really, really think you're underestimating the utility and value of the move. What's more, many of your current customers really want it, and I truly believe would lead more people to view C2 as a more serious dev tool and would translate to more sales. I would totally even be willing to pay for the upgrade, perhaps a perfect time to make it Construct 3. I hope you'll reconsider!

I always wondered why Scirra didn't use haxeNME. From what i understand it's what Stencyl uses, along with many others.

I just want to add that I would easily throw down $100 for good working native code exporters...or just something that worked directly from inside C2...easily $100! So get someone working on it!

Some great posts by Arima that I totally agree with! I can't help but think that Scirra would be best to hire an extra guy, get him to recode C2 with Haxe or asm.js output in mind, while Ashley continues to work on C2. Then by the time it is finished, release it as C3. Scirra makes a ton more money as people upgrade/buy...the community is happy and Construct is then future proof. I know that Haxe html5 output is still not finished, but eventually it will be and there are some impressive commercial games that have come out recently using this framework.

Funnily enough I was reading the Unreal4 megathread over on the Unity forums, where people where arguing about the merits of visual programming and Blueprints. One user posted an interesting reply , praising the merits of C2 and how viable it was as a visual programming solution. But in the same breath he vowed to never use C2 again because the performance was so terrible. Like it or not, there is a lot of this sort of talk going around the web. C2 has this very love/hate vibe amongst users. Of course if your only intended output is HTML5 for the web then it is near perfect!

HTML5 tech is new, so it's going to have performance issues depending on the machine and browser used.

With compatible browsers, if C2 exported ASM.JS functioning code it should increase the logic speed so the only issue would be drivers optimizing the calls.

If there was plans for an ASM.JS option for plugins/export, I'd be all for that.

I think you are underestimating the amount of time and effort to create (i.e. rewrite the entire engine) with a native exporter. As Ashley has previously stated, by the time the new engine is finished, mobile processors will be running javascript quick enough for more advanced games.

I think a BIG advantage in writing plugins/behaviours with javascript is that functionality can be developed alot quicker than a compatible exporter could be.

Perhaps a middle ground might be to include more asm.js code (we already have box 2d with asm.js). But writing and maintain both versions would slow development down to a snails pace.

Unity and other options exist to create native apps. C2 is easier to use, but thats the trade off for mobile develop (at the moment).

Arima - by "compatible" I'm not just talking about the same feature list, I also mean that the features that are supported function identically. If they don't, then ported games will be broken and it will often be extremely difficult to figure out why. For example some part of a platformer might collide differently and break the game, due to a round-down instead of round-to-nearest somewhere deep in the engine. Getting exact compatibility so games actually port with good success rates is months and months of painstaking work by itself. (This would also be complicated by some "interesting" features of Javascript, such as all numbers are doubles - simply choosing an int or single-precision float anywhere in the engine could cause incompatibilities. The list would go on.) Then not having the same supported feature list is the other half of the problem, and if some unsupported feature is critical to your game, tough luck.

I don't think many people in this thread appreciate the work that goes in to maintaining a large engine which thousands of games depend upon. Maintaining backwards compatibility with updates to the same engine is hard enough. I consider it a pretty significant technical accomplishment that we have so far made well over 100 updates and kept the rate of breaking changes very low. This is an "invisible" success which users quite rightly take for granted and don't think much about, but involves careful planning and good engineering. Lots of other tools out there frequently break things. Many games come to depend on very subtle aspects of the engine - the "quirks" - and they very much have to be left in or re-written compatibly otherwise you break whole categories of games. The idea of rewriting even a compatible subset of the engine in a different technology is a monumental technical challenge far beyond that of even just backwards compatibility with the same engine.

asm.js only covers the JS logic and would still have lots of dependencies on browser-platform features, such as: the WebGL shader compiler, asynchronous image and audio format decoding and streaming, the Web Audio API, user inputs (touch, mouse, keyboard, orientation, accelerometer, gamepads, user media, etc), WebRTC, AJAX, WebSockets, v-sync, web workers, XML parsing, form controls, platform-specific integrations (Facebook, file I/O, Windows Store, consoles e.g. NWF, etc), other unsupportable features like third party plugins and the Browser object's javascript execution, and probably more I can't think of. All of that needs to be rewritten in native code in a compatible manner, which is still a monumental job. This is why I compare it to writing a new browser engine, and so far nobody does that well apart from the major players in the industry.

However if we stick with the web platform, we can have it all: a compatible, fully-featured and high-performance engine on all platforms. Mobile needs to catch up a little, but we can already see that happening, such as with the performance results on a Nexus 5 and the fast-improving Crosswalk.

The one thing that puts C2 head and shoulders above everything else is the commited involvement by Scirra in the community. Where else can you speak directly to the head man/men and get meaningful, constructive answers. They may not always be what we want to hear but thats life.

Ashley - I do understand and appreciate that it would be a big challenge, but Its true that I don't understand all the intricacies involved of what I'm arguing for and the amount of work it would be. I see things like haxeNME or monkeycoder which advertise being able to compile to multiple platforms, and I guess it makes it seem easier than it is.

Regardless, I still think it would be a good move long term, but I also acknowledge that I might be wrong, and respect the decision to stick with HTML 5 for now. I do hope it will get as better as you think it will, but I can't say I'm entirely confident about it. Maybe even if you're unwilling to go native, perhaps at some point a rewrite to entirely asm.js could be considered instead.

Either way, thank you for being receptive to the discussion!

Watching this thread from page 1 to 30 I concluded that Scirra should make an official "tutorial + capx + Android PlayStore published-proof-game showing the "best way" to export and publish a game that platform. (The rest of the many other platforms for another day).

For example using their "Space Blaster" game as the game to export. But optimized for moviles, giving info about important optimizations to target that platform (Android).

Then you have the same game, one made for desktop and one modified with any optimization needed for you to compare and learn.

This example should be able to be downloaded from the PlayStore so we can see that "It can be done" right there in our moviles.

We can then test performance and reliability knowing that every step in the process, from making the game, to the exporting was made as it should.

If all this is made by Scirra it will give confidence to viewers and customers, much more if the same is made by any other user (I know there's already exporting tutorials made by users).

I'm not discouraging user-made tutorials about exports, just saying that and official tutorial will do a lot to proof that it can be done and at the same time mitigate any "you made it wrong" criticisms. Then if you try and fail for whatever reason, you have a reliable source to check the process. And you know that the export isn't just plain broken.

This should be done with all wrappers/exporters to all supported platforms but, at least, one platform should be tackle.

I read the entire post, found valid points for detractors and defenders of Scirra course. While both sides can be right at the same time I saw that there's already games made with Construct 2 published at Steam, Android PlayStore and Windows phone.

So I can't believe that exports can't be done. At lest to Android phones and desktop with good enough quality and performance. At the same time some rough edges are undenaiable but, at least to me and seeing games released, are not a brick wall or a reason to say: "It can't be done".

Testing games released on Android (made with C2) i found that they not only worked fine but also worked fast.

I tried games made by — like "Firewall: Puzzle Shooter" and "Ninja Legacy Lite" in a Samsung S3, a Samsumg Galaxy Y Young and an Android tablet "MD7096" wich is so patetic that can only be released in Argentina (cof.. cof..). Anyway, in those devices, witch only one can be considered fast, all games worked well and fast.

I showed those to my girlfriend who found nothing to complaint, about speed or suspicious behaviour. She knows nothing about Construct or what the hell i'm doing throwing boxes against circles in a strage program.

I didn't test the Steam games yet but shouldn't be any major problems on this platform.

Conclusion:

A good tutorial about the process of exporting and publishing to Android (at least) made by Scirra itself, using a well made, no-complaints-sensitive example like Space Blaster as the test subject and this test game downloadable from the Playstore should proof enough, should mitigate fears and will serve as an example to follow and compare.

Firewall: Puzzle Shooter performed too well in all mentioned crappy hardware mentioned (poor S3) to just say: "We cannot export and publish to Android" and grin about it.

There's some nasty problems yes. But there's more than just an elusive future that doesn't deliver. I belive that with a good example many fears will dissipate, many known problems will be obvious enough to be carefull until are solved and also many games will find their way to the PlayStore too. Some people made it. You can too.

Any other not mentioned platform/brand/store will be discused another day.

Hopefully this can help both sides or at least ease fears... and hopes.

Hillstrom Great post, it summarizes how I feel about C2 and mobiles.

Because C2 is so easy to use but still requires someone with experience to optimize, it is very easy to quickly make a very poorly optimized game that even struggles to run on powerful hardware.

I cringe a lot when I view other people's CAPX, they do a lot of calculations per tick when its not required, or do complex maths to perform a function that can be achieved with simple variables.

A very common example is this: Enemy healthbars.

They typically have every tick, set Bar Width to X. Completely unnecessary because that's every frame. Does the enemy ever get damaged again and again every frame? Hardly. Therefore it's a waste. Just throw it under Every 0.2 seconds instead. The visual difference is barely noticeable but as enemies add up, the calculations are a lot less work. There's also something that should be added to ensure it only updates the bars when needed, ie. when enemies have been injured only, otherwise it will update for all enemies when its not required. So it is placed under a trigger/event to check, If Enemy.Health < Enemy.HealthMax, then set Bar width. It's just a simple thing to do to minimize CPU cycles being wasted.

Currently a few things really hurt performance that you should avoid, WebGL effects, don't touch it. I see ppl use it to change color or tints on sprites, no. What a waste of resources.

But certainly there should be an official list of what to avoid doing to get good performance on mobiles. I don't think there's been much focus on mobiles by Scirra TBH, I learnt a lot from "Remember not to waste your memory" tutorial, but there's actually a lot of other pitfalls, some of it linked to C2 features, such as WebGL and some behaviours, or the way you go about making your events.

I am still a noob when it comes to programming or C2, others here who frequently help on the How Do I?... forum are vastly more experienced. But its because I started with a focus on mobiles, everytime I add something, I always make sure its done the most efficiently as possible.