Construct 2 - Realistic State after 1 gazilion downloads

Discussion and feedback on Construct 2

Post » Sat Mar 22, 2014 12:57 pm

@Silverforce i was talking about web mobile, not wrapper cocoon/sdk mobile....
Image
B
30
S
5
G
1
Posts: 125
Reputation: 3,231

Post » Sat Mar 22, 2014 1:03 pm

lwgames wrote:@Silverforce i was talking about web mobile, not wrapper cocoon/sdk mobile....


Was your flappy clone running on mobile Chrome browser or the default browser??
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,616

Post » Sat Mar 22, 2014 1:47 pm

@QuaziGNRLnose - I just want to point out a few disadvantages of Classic and advantages of HTML5 that you didn't mention.

CC created desktop executables. It's interesting to point out that from a security standpoint, the user is putting a great deal of trust in running an executable they downloaded from the internet. For this reason the latest versions of Windows' default settings use "SmartScreen filter", that basically warns you not to download EXEs if they are not "commonly downloaded", and you have to click through "more info" -> "run anyway". Then CC used optional DirectX components, which often required a separate download and execution of an installer that could take several minutes to run. Both of these serve as pretty big hurdles to getting real players to play your game, especially casual non-technical users (which I think still applies even as a hobbyist). On the other hand HTML5 is secure by design, and can be immediately run in the browser without any security prompts or installers. I think this is a much more significant advantage than most people give it credit for.

We spent a great deal of time optimising CC, but we still didn't get as fast as Chrome. I don't think the reasoning in the blog post is right any more: I think the main reason is Chrome has a sophisticated multi-threaded/multi-process engine, and can run rendering commands in parallel to the next frame execution on the main thread. We never made CC's renderer multithreaded, partly because parallelism is difficult to get right. So Chrome (and subsequently node-webkit & Crosswalk) have a big performance advantage over CC there.

We have also done more optimisation work in C2, including collision cells, parallel pathfinding calculations in a Web Worker, and more recently optimisations to skip redundantly evaluating expressions in the event system. I think this means in some cases C2 will provide a better experience when scaling up to large games.

CC was also at the mercy of the quality of the graphics card driver and in some cases glitched or crashed depending on the state of system updates. Software rendering is slow but can be the difference between working and not working.

Especially given the security and installer hurdles of node-webkit, I'm surprised by the level of demand that remains for it. Still, it should serve well as a "native app" if that's what you're after.
Scirra Founder
B
403
S
238
G
89
Posts: 24,660
Reputation: 196,167

Post » Sat Mar 22, 2014 2:30 pm

Silverforce wrote:
PixelRebirth wrote:
Silverforce wrote:@lwgames

You are seriously doing something wrong if you cannot get a flappy clone to work great on mobiles.

Took me 4 hrs to do a flappy clone with my own art: https://play.google.com/store/search?q= ... apps&hl=en


These games are all using CocoonJS, which is currently the only way to get good performance on mobile devices in many cases. But of course CocoonJS is coming with its own bag of problems. That's probably why Scirra is promoting the use of Crosswalk, which doesn't do anything to speed up HTML5 games compared to just using the mobile Chrome browser. Which may be relatively fast, but can in no way rival the real thing. So I think it's fair to say that there is indeed still a general performance problem with HTML5.


Actually, my most complex game is done with Crosswalk via Intel XDK, because CocoonJS falls on its face with big games with lots of assets (450MB loaded into memory!!)
https://www.youtube.com/watch?v=N4krwUmmb3c <== flawless on older phones with a 1ghz dual-core and 512mb ram.

Crosswalk actually runs smoother/faster than CJS as it is, the only downside is its lack of Ad/IAP support, but its a temporary downside from what @IntelRoberts is saying.

Yes, we have lots of room for improvements but as it is, you can create great games with the functional parts. Will you be able to make whatever you want run great on mobiles? Heck no. Figure out what works and what doesn't and optimize.


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.
B
23
S
6
G
11
Posts: 1,047
Reputation: 8,065

Post » Sat Mar 22, 2014 8:04 pm

@Ashley

I think it's moot to argue that running an executable is trusting the user to put faith into your executable. This has always been the case for any game, any program, anything downloaded off the internet. Windows' poor choice of default setting to prevent the lowest common denominator of user from being tricked, which will happen anyway for those people who blindly download and run software shouldn't detract from genuine applications using a system to its fullest by accessing as much privilege as they can. It'd be pretty sad if we were headed to a future where only "registered" developers get the privilege to have their applications actually use your computer to its fullest, and everyone else is forced to run through a non-essential protection layer or use a workaround/loophole like html5 that's supposed to make running the code seem "safe" because its the trusted browser running the code instead of a standalone application. Anyway, this isn't about Microsoft's bad choices, something i think everyone who'd understand agrees on.

If an exporter using SDL were made, the games would be cross platform, and genuinely perform well since the whole goal of SDL is to make things run everywhere. The license of SDL would completely allow this as well, and SDL would make things work 'everywhere', using the systems to their fullest, but of course i understand the work involved in making any kind of new exporter, i'm merely suggesting this as something that seems to mesh with your goals and provide the best of both worlds so to speak.

As for installing directX etc. This is something that's also to be expected when installing any kind of game. It's never been jarring to any PC user to see a directX prompt while installing a game, its been expected for years.

In anycase, im aware of that performance test, but rendering a ton of sprites faster isn't really impressive or incredibly important (of course it is a good thing). You admitted yourself that there aren't many optimizations to these aspects in classic, and they were never really necessary because the calculation of sprite vertices has never been a significant factor in affecting performance, games with 30 sprites on screen can have performance issues if you're doing enough with them. It's lovely that C2 makes many optimizations in order to squeeze as much performance out of html5 as it can, i'm fully aware of this and it is impressive that you get as much out of it as you do, but the fact remains that when i make a significant number of expressions run for enough objects, C2 seems to fall behind at least in my experience, but perhaps this has changed since i did my tests. You're fully aware that if you made the same optimizations in a native C++ engine like CC that you did in C2, the results of that tests would be completely different.

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. Theres benchmarks (http://www.i-programmer.info/news/86-browsers/3492-javascript-is-slow.html) you can find on the internet and floating point calculations will just always be significantly slower (http://stackoverflow.com/questions/17036059/javascript-is-4-times-faster-than-c, see comments), no matter how optimistic you are about it's future gains, and you've acknowledged this yourself.
B
79
S
13
G
8
Posts: 1,977
Reputation: 9,947

Post » Sat Mar 22, 2014 10:23 pm

PixelRebirth wrote: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).
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,616

Post » Sun Mar 23, 2014 12:59 am

QuaziGNRLnose wrote: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.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Sun Mar 23, 2014 5:46 am

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.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
22
G
18
Posts: 2,123
Reputation: 17,150

Post » Sun Mar 23, 2014 11:51 am

@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.
Scirra Founder
B
403
S
238
G
89
Posts: 24,660
Reputation: 196,167

Post » Sun Mar 23, 2014 6:34 pm

Ashley wrote: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!

Ashley wrote: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!
Moderator
B
95
S
34
G
33
Posts: 3,007
Reputation: 27,876

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 14 guests