Construct 2 - Realistic State after 1 gazilion downloads

tomsstudio - as I've tried to mention before in the thread, WebGL effects are only the tip of the iceberg. You're going to have a long list of major unsupported features. We would offer more help if we thought it would result in a commercial grade product.

tomsstudio - as I've tried to mention before in the thread, WebGL effects are only the tip of the iceberg. You're going to have a long list of major unsupported features. We would offer more help if we thought it would result in a commercial grade product.

I'm going to have to disagree with you here Ashley.

WebGL is daunting, ill admit.

Multiplayer will be the longest feature to code in. I will probably require help from someone on this.

But all the other features i have looked at in Construct 2 are already in development/or already have modules.

Your help would be appreciated, but not necessary

Like i said before, i truly do love construct 2, i appreciate the work you and Tom have done, it is truly amazing, it has inspired me

Oh, and Arima - you argue "there's too much uncertainty", but with a native port you'll have uncertainty over supported features instead. As I said before, a native engine is not going to be a magic bullet where everything works perfectly, it will tradeoff performance for other porting incompatibilities.

I also absolutely cannot see why examples of single bugs like memory management is an argument for the extraordinarily expensive and time consuming development of native engines. It is *obviously* much easier to fix those problems first before even considering it. This is an ongoing work in progress, but we will get there.

With modern devices with an up to date browser and OS, performance is already outstanding: as I said before my Nexus 5 can outperform some of the desktop machines in our office on some benchmarks. There's an argument to make a native engine to support older devices, but a native engine could easily take so long to develop to maturity that the next generation of phones and software updates would have already filtered down and far reduced the problem. This already happened with desktop. I dread the idea that we spend a year holding up everything else to write a native engine, and then by the time we're done HTML5 performance on mobiles is not a problem. What a colossal waste that would be!

Oh, and Arima - you argue "there's too much uncertainty", but with a native port you'll have uncertainty over supported features instead. As I said before, a native engine is not going to be a magic bullet where everything works perfectly, it will tradeoff performance for other porting incompatibilities.

I also absolutely cannot see why examples of single bugs like memory management is an argument for the extraordinarily expensive and time consuming development of native engines. It is *obviously* much easier to fix those problems first before even considering it. This is an ongoing work in progress, but we will get there.

With modern devices with an up to date browser and OS, performance is already outstanding: as I said before my Nexus 5 can outperform some of the desktop machines in our office on some benchmarks. There's an argument to make a native engine to support older devices, but a native engine could easily take so long to develop to maturity that the next generation of phones and software updates would have already filtered down and far reduced the problem. This already happened with desktop. I dread the idea that we spend a year holding up everything else to write a native engine, and then by the time we're done HTML5 performance on mobiles is not a problem. What a colossal waste that would be!

Ok Ashley i agree with you.. in 3 years the most phones would have 2-3gb RAM very fast CPUs better HTML5 support etc.. but with my comleted games now ? That's my only problem with this engine and the main page promises.. Just waiting for Intel crosswalk updates ( when ? how much longer ? I wait from the 1st day for the mobile exports to be REAL ..) or a native exporter from some hero..

(A little too intense here but please forgive me, everyone has it's dreams and this is the only way to push construct 2 development the way i need it )

The main problem with C2 is that it was based on un-fully tested and implemented future web tech that won't be fully realized for 5 or maybe even 15 years from now. This is what us Construct classic users were worried about. A lot of pieces had to fall into place from third parties to work, and for the most part on desktop it did. But there is still no unified cohesiveness when it come to gaming standers on all browsers on every platform. Gaming standers on all browsers on every platform is the selling point for Scirra on the front page. This is the strength and weakness of C2, because in the future web gaming will be a powerful stander but you're asking people to pay for that now. I think Scirra may have done the right thing by going the HTML5 rout in the long term by that I means using C2 in the future years. In the short term C2 will be the point of anger and frustration for developers not making game for desktop.

Guys please one must remember that it is your wish to use C2 or not. NEWT you said Well, nobody is making you use C2, perhaps you should try some other software. hey no need for this. He was only making his point cool it guy's and use C2 as you like or not to use your choice

Well if you want something now, a commercial-grade native exporter is certainly not going to happen overnight either.

Potato Ejecta is a third party exporter and already has built in C2 support on export if I remember correctly...

I think HTML5 has been a great springboard to get Construct 2 where it is Today, indeed Chrome has been it's special move...

Maybe not now, maybe not this year,but long term I seriously think it would be better for C2 to detach from HTML5's apron strings, peer out from google's wing and become not only "The HTML5 game creator" but "The game creator"

Relying on third parties has set Construct 2 back a few times now, fingers crossed that won't happen again...

Many of the forum members wanting to see a native exporter have moved on from Classic, maybe we have seen the grass can be greener...

There's an argument to make a native engine to support older devices, but a native engine could easily take so long to develop to maturity that the next generation of phones and software updates would have already filtered down and far reduced the problem. This already happened with desktop. I dread the idea that we spend a year holding up everything else to write a native engine, and then by the time we're done HTML5 performance on mobiles is not a problem. What a colossal waste that would be!

The appeal is that once the task is done it will be under Scirra's control. When it's 3rd party control and that 3rd party doesn't make C2 a priority there will always be serious issues cropping up, like the recent and sudden drop of support for XP and Vista. It just makes it difficult to justify using C2 on anything other than just messing around. People will try it, buy it even, find out it isn't a serious platform, and move on. If you were to track your users I would imagine you would find that this is a common pattern. Why not hire someone, do a kickstarter or something, so that it doesn't hold you up? I would be more than happy to donate toward development of exporting tools that are quality controlled by Scirra. I imagine many of your customers would be as well.

Scirra needs to create a subscription based model.

I'm not talking high, maybe $50 - $100 per annum above the personal/business purchase price, which includes multiplayer, exporters etc.

If Scirra did this, I would stop using Construct 2 and I think probably many other people would as well. I'm not saying it isn't worth it - it probably is - but it would be the final push I needed to stop using game engines and learn to code properly dammit. Just my 2p.

I do have a quick question, though. I only really want to make fairly large and complex games for desktop PCs - I'm not really interested in ads, mobiles or any other platform - and lot of this discussion is a bit over my head For users like me, are Construct's export options (which is Node-Webkit I guess) good for what I want to do?

Apologies in advance if this is exactly what everyone's been talking about, and I'm being thick...

Oh, and Arima - you argue "there's too much uncertainty", but with a native port you'll have uncertainty over supported features instead. As I said before, a native engine is not going to be a magic bullet where everything works perfectly, it will tradeoff performance for other porting incompatibilities.

I also absolutely cannot see why examples of single bugs like memory management is an argument for the extraordinarily expensive and time consuming development of native engines. It is *obviously* much easier to fix those problems first before even considering it. This is an ongoing work in progress, but we will get there.

With modern devices with an up to date browser and OS, performance is already outstanding: as I said before my Nexus 5 can outperform some of the desktop machines in our office on some benchmarks. There's an argument to make a native engine to support older devices, but a native engine could easily take so long to develop to maturity that the next generation of phones and software updates would have already filtered down and far reduced the problem. This already happened with desktop. I dread the idea that we spend a year holding up everything else to write a native engine, and then by the time we're done HTML5 performance on mobiles is not a problem. What a colossal waste that would be!

Actually you don't have to fix those issues.

In five years, Moore's Laws and browser-side performance improvements will fix those issues.

I still find it bizzare that my web browser itself (not related to Construct 2) takes up far more memory then it did when I only had a 1 GB RAM desktop. Sloppy browser design.

>

> Scirra needs to create a subscription based model.

> I'm not talking high, maybe $50 - $100 per annum above the personal/business purchase price, which includes multiplayer, exporters etc.

>

If Scirra did this, I would stop using Construct 2 and I think probably many other people would as well. I'm not saying it isn't worth it - it probably is - but it would be the final push I needed to stop using game engines and learn to code properly dammit. Just my 2p.

I do have a quick question, though. I only really want to make fairly large and complex games for desktop PCs - I'm not really interested in ads, mobiles or any other platform - and lot of this discussion is a bit over my head For users like me, are Construct's export options (which is Node-Webkit I guess) good for what I want to do?

Apologies in advance if this is exactly what everyone's been talking about, and I'm being thick...

Not talking about subscription model for the software, only a few additional plugins like multiplayer (which I believe is being hinted to be subscription based because of the time it takes to maintain and build additional functionality)

Your quick question is the very reason I use construct 2. It is really good for desktop games and you don't need to be concerned with anything that is in this thread.

They are discussing trying to squeeze a desktop game onto a mobile phone and make it run the same. Which you can understand is the cause to he frustration because currently nothing makes this process easy.

Node-webkit is perfect. And html5 export is perfect (outperforms competitors in html5) which means it outperforms competitors in desktop too I would say because game is still run from a stripped down chrome.

You are good to go. Some really big, games coming to desktop using construct2.

Fantastic, thank you

Arima

Is your disappoint to do with mobile technology generally or C2 using an interpreted language. There are major problems with developing for a mobile platform when compared to desktop.

I'm aware of the performance difference between mobile and desktop hardware. The problem is how much JavaScript lags behind native.

How important is WebGL Effects on mobile to everyone? Cause these are really, really hard to code .

I might have to hire someone to code it for me.

On mobile they're less important to me currently because they slam performance so hard so I avoid them anyway, but as hardware improves I'll want to use them more. Maybe the first version can skip them?

Oh, and Arima - you argue "there's too much uncertainty", but with a native port you'll have uncertainty over supported features instead. As I said before, a native engine is not going to be a magic bullet where everything works perfectly, it will tradeoff performance for other porting incompatibilities.

I don't think that's an issue of uncertainty because before starting on a project we could check to find out what features are supported on each platform. That actually sounds like certainty to me. And again, native can support the vast majority of what most games need.

I also absolutely cannot see why examples of single bugs like memory management is an argument for the extraordinarily expensive and time consuming development of native engines. It is *obviously* much easier to fix those problems first before even considering it. This is an ongoing work in progress, but we will get there.

Well, I didn't mean that was the only reason, I meant for all the reasons combined.

With modern devices with an up to date browser and OS, performance is already outstanding: as I said before my Nexus 5 can outperform some of the desktop machines in our office on some benchmarks.

There's an argument to make a native engine to support older devices, but a native engine could easily take so long to develop to maturity that the next generation of phones and software updates would have already filtered down and far reduced the problem. This already happened with desktop. I dread the idea that we spend a year holding up everything else to write a native engine, and then by the time we're done HTML5 performance on mobiles is not a problem. What a colossal waste that would be!

I understand, but that's the same problem that performance is always behind the competition. Also, again, I suggested hiring someone instead of tackling it all yourself so it wouldn't hold up all the other features so much.

I still believe that C2 should have native to truly be considered a serious dev tool so we wouldn't have to rely on hope for the exporters. I mean, imagine visual studio or whatever you're using to develop C2 suddenly decided that you couldn't deploy your creations to XP and vista anymore. That'd be insane, right? You wouldn't want to rely on a tool that pulls stuff like that. That's basically what happened to us with chrome and node webkit. I guess I could stick with the old version of NW but what about bug fixes and all the enhancements I'd miss out on, like the improved controller support, and what if C2 is updated to require the new version of node webkit? Then I'd be stuck on an old version of C2. These kinds of things are just unacceptable and are simply going to turn people away from C2, which I very much want to succeed and thrive to it's full potential!

Anyway, I've made my argument, and I don't know what else I can say to convince you, so I'll stop trying for now. I'll continue to use C2 regardless, and look forward to Tomsstudio's exporter as well as the ongoing improvements to C2 itself.

Node-webkit is perfect.

It's not. Node webkit has no hardware acceleration for XP and vista.