Construct 2 - Realistic State after 1 gazilion downloads

When we first released Construct 2 no browsers had hardware acceleration and the games only worked on Chrome and Firefox. We had threads just like this one, but saying that HTML5 sucked for desktop browsers, go make a native engine or use Flash instead, etc. etc. I think by now it is obvious - as mentioned in this thread - that desktop browsers generally work excellently. I am totally convinced we cannot beat node-webkit for quality of desktop exporters. So I would like to assert that there is no need for a native engine on desktop (barring dumb decisions over hardware acceleration on XP and Vista which I hope they reverse). In fact I would go so far as to say that having written a native or Flash engine for desktops in the first place would have done a great deal to hold us back. Here are some of the technical problems raised by writing a native/different tech port:

• exact compatibility with a browser is probably impossible, without actually writing what amounts to a new browser engine. So inevitably there will be a list of features that are incomplete or simply not supported.

• exact compatibility with the features that are supported is very difficult. There are likely to be subtle bugs or variations in behavior that trip up games in obscure ways and make ports more difficult. All third party addons can probably be assumed to never be supported.

• the rate of improvements to the engine and editor would have been significantly slowed while we were bogged down by the technical debt of having to maintain multiple codebases in parallel. We probably could not have got to where we are today if we had taken on that extra work.

• the whole point of the exercise is to improve performance, but on GPU-bottlenecked games, the GPU is still the same, so making a native engine would still not actually improve performance at all in that case.

• eventually the work is redundant, because HTML5 on desktop is good enough, but we would be obliged to keep supporting the native ports since some users would by then depend on them.

In short we'd just trade one set of complaints for another: difficult to know which features work on which platforms, annoying random bugs when porting, things aren't progressing fast enough, etc. If you look at some other tools you can see they are definitely affected by those problems. I do think it's actually a good thing for users that we made this decision on desktop. And this may be a tough pill to swallow right now, but we're making the same decision on mobile, and I'm convinced it will pan out just as it did with desktop.

Mobile performance is already excellent on many devices: my Nexus 5 can get 20,000 sprites on-screen at 30 FPS - faster than many desktop systems. Crosswalk is effectively the node-webkit for Android, and matches that performance. Crosswalk will support IAP, ads and screen orientation lock within a few months - we're working with Intel on that, and it only first released recently as beta, so it was always going to take some extra time to sort out all the features everyone wants.

We often get complaints about mobile performance which are clearly limited by the GPU hardware, such as the fillrate. For example if 'Low quality' fullscreen mode improves your game's performance, the engine is doing identical work, except the GPU hardware has less work to do, so it's clearly hardware-limited and nothing would be gained with a native engine. In this case we usually have a tough time explaining that it's not a problem with Construct 2, you just designed your game in such a way as to exceed the hardware capabilities of the device. In these cases, a native engine would not be faster, because it uses the same GPU. For low end devices you have to be extremely careful, and a native engine won't stop you throwing more sprites at the GPU than it can handle.

So we could make a native engine, but it would have incomplete feature support, probably introduce obscure bugs when porting, slow down overall development at Scirra, not actually improve performance on GPU-bottlenecked games, and have ongoing technical debt even after HTML5 becomes excellent on mobile. There is no magic bullet that makes everything perfect, and a native port would just trade one set of problems for another, and I don't think they'd even be a "nicer" set of problems.

There are some cases where performance is a problem, particularly the Android stock browser and iOS native apps. These are often solvable with software updates. Just as with desktops being slow due to no hardware acceleration, subsequent software updates fixed that and now in many cases it's super fast. Chrome for Android is replacing the stock browser steadily, and future iOS updates could introduce features like WebGL and JIT for apps. There is a lot more going on in the tech world, all moving in that direction. So working on native ports could even become redundant fairly quickly. That's why we think it's best, even with our plans to expand the team this year, to stick to the HTML5 engine and work on other compelling and highly-demanded features like multiplayer. I know some of you won't like this choice, and we'll likely keep seeing threads like this for some time. But I would encourage you to spend more time thinking about where things are likely to be in the near future. Things are not standing still; they are literally changing month by month. If we didn't think HTML5 was an absolutely solid choice for the long-term prospects of our engine, we'd already be working on native ports.

Ashley

wow what a great post!

However i'm still going to work on native, you guys wont have to change anything in Construct 2 for the compiler to work.

Basically the program grabs all the necessary data it needs from the .xml files and converts to native. You are however right in saying that's going to be hard to make sure what you see in Construct 2 will appear the same in Native.

Some features in native, like physics and platform behaviors, will need the math to be adjusted to match C2 levels.

Other things will be a little harder, but i'm confident most features can be brought across.

Ashley

Just to be clear, you don't mind me making a native compiler?

I promise i wont drag you down!

I can absolutely understand the position of Scirra and I do believe it is conceivable that HTML5-driven interactive content will be the golden solution for every platform in the future. HTML5 already came a long way in the last few years and is a very viable replacement for native on desktop.

That being said, an outlook to the future cannot solve current problems. So I can also understand the frustration some users may have realizing they cannot deploy on mobile platforms with acceptable performance or run into other problems (audio...).

Admittedly I see myself somewhere in between. I can mostly achieve what I want with Construct 2 in it's present state and don't necessarily feel held back by the lack of a native mobile exporter or mature wrapping solutions. That doesn't mean I wouldn't welcome such a feature.

That's why I was hoping Scirra would be doing something about improving the exporting options for mobiles when they hired new people. Sort of a middle ground to make everyone happy. Then again if Scirra commits all resources sticking to their guns, good things are bound to happen...

For now I would bet on the collaboration with Intel (Crosswalk), which seems like the most promising wrapping solution. It just needs to move at a faster pace than CocoonJS ever did.

Other parties making custom compilers could also play a role. I'm certainly curious about what tomsstudio can come up with.

Well I am not new new to C2 but I finally decided to get a license and dedicate time to learn. I have GM Pro and Fusion 2.5 I like GM cause I can switch to coding when I want to but when I look at the price tag of exporting to different formats I just can't bring myself to justify paying 500+ more for a 2D engine when the 3D engine that I have exports to all platforms and cost way less. My 3D engine is great but its great for what it is 3D, it takes more work to make it work for 2D even though I have done it in the past. I just got tired of doing it that way. So I wanted to have my 3D engine for 3D games and then my 2D engine for 2D games. The only thing was that my 3D engine spoiled me because when it exported for different platforms I didn't have anything extra to do except sign my package. But I eyed and eyed C2 and eventually said what the heck.

I made a small pinball game and I was expecting the FPS to be terrible on the mobile but it ran at 50+ and thats with the physics on. And I had no issues with music. So I will keep playing and see what Team Scirra has for me in the future.

tomsstudio - I don't think it's a good thing. I think you are severely underestimating the technical complexities of accomplishing this in a useful way. Consider Ludei have ~20 people and CocoonJS still has its issues. I think you will simply encourage others to believe it is easy and make them question our decision when we actually fully understand what it would take to create a stable, compatible engine with feature parity.

I personally think Scirra might be in a bit of trouble when Clickteam releases MMF3. From what i understand it's feature set will match Constructs, it's editor runs on multiple operating systems, and it has native exporters. If it's as good as it sounds, for a serious developer i can't imagine a reason to use Construct over it.

The only downside i can see is Clickteam's reliant on community support, their slow bug fix's and lack of communication in general. I do like the frequency of Scirra updates.

First, you can get 30-35fps on crosswalk, but on same games is not enough, endless runners with 30 fps its a no go, at least in my experience. Still its promising, you can use iframe(load any ads you like, not the one cocoon or god knows wants), load by layout, that can be very good, custom permissions, but it is months away. Of course if you have dont many continuous actions for the protagonist, it works, yes. I see a lot potential in crosswalk and i understand why Scirra stopped using Cocoon Js, they are pretty horrible, and they lock you in. For example you cannot use iframe, so you are locked into their advertising partners, or you have to develop your api for ads, which is another horrible thing. The support is also terrible, i had to find out by myself why the hell the android app crashes on resume/lock. Its because how Cocoon JS handles music, so no music.

I bought C2 for nodewebkit, to make desktop games, and it can do that. I stopped for now, because of the budget and time limitation, so i went to test the market with small games, until hopefully i get a budget to make real game, that means: Desktop small indie games, no mobile cash grabs.

Now i never talked about fps, yes we have ways to have a decent outpout, but not without crashes, missing lock screen or audio. Which is not Scirra fault, its just because they are third party, and Scirra refuses to make a native, or NON native official exporter/s.

I understand Ashely strategy, i just dont get where the money from the last 2 years went? A programmer hired for 1 year to make an native or non native official exporter/s is that much for you guys. You sold quite a lot of copies, C2 is everywhere on net.

Of course its not my place to ask what you do with your income, but i cant stop wondering, after so much success, no official exporters present, you employ a buggy free forum software, instead of buying xenforo or vbulletin, its still bugged on dual login, i have to log in everyday, maybe its the cookie, or you guys dint fix a common bug in phpbb. It just feel weird sometimes... like mucho talk but not real investments

"That being said, an outlook to the future cannot solve current problems" it was the same retoric 2 years ago, HTML 5 will be great in the next years, it will be the holy grail, 2 years later, well HTML 5 will be great in the future... Yes, i am sure it will have a big place on the market, not as big as Scirra and other bloggers like to promote, at least not at first, but what about now? What we do now that we bought this software? We makes games that the engines wants, but not those that engines promotes that we can. You really should remove that marketing crap from the landing page, its so deceiving. "It can export to ALL platforms here, but * with some problems lol.

It can make decent html 5 web games, YES IT DOES, cant make serious income with them, unless you invest some serious money in graphics, but its a start, so. CHECK

It can make desktop games, YES IT DOES, with problems on XP and VISTA, but it can. CHECK.

The rest ? Incomplete. It can in theory, but with some limitations.****

I think ill stop here, i or we tell again that the engine seriously needs an official exporter native or non native, but official and its supported by Scirra and optimized for their engine, and we get again another rethoric. I wont even bother to talk about the GPU non sense and mobile performance. I never told that is C2 fault for that, and in some cases it might be, its because we are using third party. Again Ashely sends to knock on doors. Crosswalk will be better in X months, Html 5 will rule the world in X years. Play some html 5 mobile games to see how it rules the world...

I understand you cannot make a native exporter, but why the hell we dont have a non native official exporter like crosswalk after 2 years?

1) You lost lots of money which you could earn by selling this addon and support your community too.

2) Lost of sale and made your customer base knock on doors...

This is goin nowhere, ill just stop posting on this matter...i am already derailing... every time Ashley talks about HTML 5 future, i get a headache.

Ashley

I may not as smart as the team at scirra, but i'm not severely underestimating anything. I know how complex its going to be, i may fail, i may not.

I originally joined this thread to defend C2 by saying that i'm working on a native compiler, not that i have one already. Yes its going to take a while, it even be completely pointless if your right about intel and crosswalk.

But i'm dedicating my own time in creating something that can only benefit construct 2. It doesn't require any time or resources on scirras part. If i do succeed in making a workable version, i don't see that hinders scirra in anyway. People will still have the option to compile to whatever target they choose, whether that is Crosswalk, XDK, Cacoonjs, etc.

I'm not trying to re-invent the wheel, i'm bringing existing technologies together to make something new.

I love Construct and only want to see it succeed,

but i thought with so much support in the plugin section that scirra would be happy for someone to have a go.

I will continue with my work, and if people want to use it, then they can, if they dont, doesn't hurt anyone.

i agree 100% with ashley and the whole mobile thing.

if you see your games from a business standpoint you have to make hard decisions before you even start creating one asset . decisions about what you want to create and what is you target group. it is insane to believe that you can run your game across thousands of different cell phone models without any compromise.

the biggest mistake most of us do in here is that we take software like c2 and think that we can do everything with it because it is so easy to use!it gives us false power and makes us believe that game creation is easy.

think about it. you use an iphone. you can text.surf the internet,make a phone call .how many of the millions of people that use it every day know anything about how it all works? just because we use it doesn't mean that we know anything about power consumption,antennas,chipsets,os,touch sdk, etc etc etc.this is the same with c2

so asking to just press a button and suddenly all of our sloppy or not work to run at 60fps on an 3 year old cell phone is work best suited for harry potter and not ashley.(unless he is harry potter)!

that is the reason why i believe he should focus on improving c2 and only officially support fixed hardware with a life span of many years like xbox ps4 and wii u (he already has).

Founded on Reddit:

"I personally love MMF2 but unfortunately ran into heavy performance snags whenever I exported to Android. Things that just simply shouldn't happen like having more than 10 objects move at one time causing frame stutter. I was spending more time debugging and working around its limitations than producing so I had to switch. Still I highly recommend it for prototyping and or PC development."

"Thanks! One or two of Construct creators used to be pretty involved with MMF2, and I guess they had enough of the limitations and bugs and did something about it. They're both very similar in terms of event scripting though, and both have their ups and downs."

"That would be Ashley Cullen, or Tigerworks as he was known back then. He had an RTS game made in MMF2 (Terminal Orbit) in the works for a few years, but it was never released. I remember he started developing plugins to help in the creation of it, which I guess is what led him to start Construct."

http://www.create-games.com/project.asp?id=89

Other issue is that events are going in one big loop,

so 100 events may be good for simple game,

but 10.000 events (I guess) could kill even desktop

Then you're doing it wrong. There's no reason to loop through every event every tick.

also bullet behavior that isn't 100% smooth both on mobile/desktop

Sure it is. Look at your code and see what's slowing it down.

also saying "use Crosswalk" is not serious at this moment

and +18MB apk size can dramatically decrease number of downloads on Google Play

It's not 5 years ago. 18MB is nothing. The last mobile game I downloaded was 100+MB, and some larger titles top 1GB.

but yeah... anyway: there is no competition with anything similar to event sheets

The new version of Stencyl is mobile-friendly and no longer limited to Flash only export, if you're looking for a C2 alternative. Though having used both and compared the upsides/downsides, C2 is an easy choice. If you hate yourself, there's also GameSalad, but I wouldn't recommend that to my worst enemy. MMF and Gamemaker don't have the featureset or ease of use while still allowing some semblance of commonly coding syntax of C2 either. They do a little, but not to the extent of C2. If you've ever done real development, this makes getting up to speed on how things work an extremely fast excercise.

As for Unity: I've also got a Pro license for Unity. Have since v2 was first released. I use it on an almost-daily basis for non-game projects for my day job (freelance interactive designer/developer). And when I was looking at the best choice to make the 2D game project I'm currently working on, I chose to use C2. And I've yet to find a better 2D solution for desktop (my target for my current project) or modern mobile devices that both allows me to reach the level of quality I'm reaching for and still have the kind of control I require over how things work while still abstracting some of the low-level code that I'd prefer not to have to deal with. HTML5 may not be 100% perfect, but it's a heck of a lot better than Flash (which I've used for animation since it was called FutureSplash, and for development since Flash 3) in both performance and ease of use. In fact, this debate over HTML5 isn't drastically different from what Flash itself had to go through in terms of acceptance.

I'm not the type of a person to be a software apologist - I have no personal loyalty to any bits of code - but if you don't think you can make a full-fledged 2D release with C2 that has the potential to be competitive in a tough market, then you're doing it wrong and it's not the software's fault.

I understand you cannot make a native exporter, but why the hell we dont have a non native official exporter like crosswalk after 2 years?

1) You lost lots of money which you could earn by selling this addon and support your community too.

2) Lost of sale and made your customer base knock on doors...

This is goin nowhere, ill just stop posting on this matter...i am already derailing... every time Ashley talks about HTML 5 future, i get a headache.

Because there's no point in having one when JS is interpreted at near-native speeds. "Near-native" being a technical term for "nobody can tell the difference in practice so don't pretend you can."

1) Uh, what? Sell add-ons if you want, but if your goal is to make money w/ add-ons, your best bet is Unity. C2 is for making games.

2) Why would you lose sales? Why would you blame the software when you didn't design it properly for the target hardware?

If you're getting a headache, it's due to the cognitive dissonance between what you're being told is true and what you'd prefer to believe is true. HTML5 is fine and there's a reason support for it on desktop, mobile and console - MAJOR consoles of the NEW generation now ALL support HTML5-based games & applications - has been very rapidly increasing for the past few years.

"That being said, an outlook to the future cannot solve current problems" it was the same retoric 2 years ago, HTML 5 will be great in the next years, it will be the holy grail, 2 years later, well HTML 5 will be great in the future... Yes, i am sure it will have a big place on the market, not as big as Scirra and other bloggers like to promote, at least not at first, but what about now? What we do now that we bought this software? We makes games that the engines wants, but not those that engines promotes that we can. You really should remove that marketing crap from the landing page, its so deceiving. "It can export to ALL platforms here, but * with some problems lol.

You don't know what you're talking about. At all. HTML5 + JS is a sign from the heavens that development, game or otherwise, doesn't always have to be a giant pain in the ass. And WebGL? Holy cow. Have you ever tried to write a straight OpenGL fragment shader? I'd rather pull my toenails out with pliers, but how elegantly it's handled through WebGL/C2 is a breath of fresh air.

Arima "I don't recall reading about this. How it would work?"

Well The real strength of C2 when it's been compacted to the C2runtime.js isn't the JS it's the API. After the code is "compiled" it's link to the C2 IDE is non existent. There is no reverse enginearing back to C2 EventSheet XML. In fact once "compiled" the result is no different in structure than most other programming languages.

Know that C2's other strength is that the api is mindblowing robust. Unity probably the words biggest engine has nothing on C2 behaviours and plugins. I don't stay and hold my belief that C2 HTML5 technology is great. I hold that C2 IDE and API are fantastic and that in given time Ashley is right; there won't be problems... but they linger for now.

However in the mean time JS code is just code and can be reversed engineered to another language. *cough* Java/C#. *cough*. It is doable. However I think after some thought when I brought the subject up. Is that while all the plugins are converted to compact effecient code and can be convereted without too much trouble. The break down is supporting all the other browser parts(DOM, WebGL, Canvas2D, WebSockets, WebRTC, AdvancedAudio, Controller, Keyboard, Touch, Vibrate, General Browser Features). Those browser parts don't convert to convertable code. Instead the "wrapper" would have to once again write all those browser parts and if your doing that you have practically built another browser.

The big benefit of such a task is the code truly won't be JS anymore it would OS machine compiled. C#Win8, java for Andoird, Objective C for iOS and Mac, C++ for Widnows/Linux.

...

you know what would really be super cool as I was just thinking about this. What if we/I/someone else created a gaming cloud based converter. let me explain the theory.

someone puts up a piece of working code. Identifies the language.

Then the converter attempts to start converting.

When the converter get's stuck; the converter then posts a help request. Posting what piece of code it got stuck on.

Then others can examine the problem and write a solution. This includes a slow way to flesh out the api.

When a solution is given the converter will take all solutions given in a period of time and test the performance. Keeping the fastest and or more memory effecient.

Now the effort of conversion would be a lot of work for 1 person or a group, but what about hundreds or thousands.. That would be a nifty idea. JS has not effect converters to another language. This would be a nifty experiment.

"Yes there is, I have no ability to code traditionally at all."

You got me there big time

huh, I forgot to hit the post button last night.*

Hate to sound like an ass as always seems to happen, but I notice these threads usually wind up revealing the need for better game logic.

Perhaps whats needed is some sort of program that teaches how to do events properly. Something complete with site badges and all.