Construct 3 - many questions (native exporterts)

:facepalm:

first of all - if you export to PC - i guess you want to give your game over through STEAM or something like that (origin).

if you go through these - they install C++ automatically, you just have to set them up.

also - most of today games install some kind of C++ redist package because IT IS NEEDED. - you just don't see it installing every time because once installed no need to install again.

and trust me i've not seen a game that can't be run fluidly on any PC that can run GTA V in 60 fps. (p.s. maybe he plays GTA V on lowest with 60fps and actually has a lot weaker pc then you think).

also:

• for earning extra money - would not pay
• for good performance - already we have
• for comfortable "one click" export - that thing does not exist
• for independence from third-party plugins - ahahahaha.. you're a funny guy. there is no such thing as independence.

paradine

• for earning extra money
• for good performance
• for comfortable "one click" export
• for independence from third-party plugins

I Agree.

These are all excellent points....

paradine

Personal License - 129.99$ (and I guess that most users use this one) - one time

Education License - 49.99$ monthly or 359.99$ yearly

so... from business point of view it's perfectly logical that Scirra does not care about native exporters. Why bother if bigger money (monthly/yearly) is from education subscriptions? Also making native exporter means more programmers = higher monthly costs = less profit = high risk.

And Ashley is right that at some point HTML5 browsers/wrappers will be good enough. So people can wait months/years

There is a very accurate comment from www.slant.co:

[quote:2c0nhbbm]Unless you are creating a game strictly for browser/HTML5 usage, exporting to desktop or mobile is risky, as Scirra have no control over your final export quality. Since desktop uses NodeWebkit and mobile is Crosswalk, Phonegap or CocoonJS there is no guarantee that your final export performance and quality will be up to scratch for pro level 2d games. These 3rd party "browser wrappers" are very prone to breaking and introducing lag and bugs that can't be controlled from Scirra's side.

I know how to fix it - installing Visual C++ redistributable solves the problem

I've not heard of this before, and it's a bug if it's the case. Have you filed a bug report? Ideally the NW.js exporter can work at best performance without having to install anything extra (other than the DirectX web setup thing, which is a pain, but we had to have that for Construct Classic as well, which used... a native exporter).

I don't think we'd make more money with a native exporter: it is an enormously expensive project, requiring more staff, more development and testing time, and other far-reaching implications (like third party plugins essentially become unportable unless the developer feels like doing 5x as much work for free). We'd probably have to put up the price of C2, or charge per-exporter like some other companies do, running up a high cost for the customer if they want all the export options. Given that it has all export options built in, C2 is one of the cheapest tools on the market.

Independence from third parties never goes away unless we write our own operating system and device drivers. We could for example choose XNA, Haxe, Flash, or something else, and equally be hosed by problems in those frameworks.

It's true we don't have control over the performance of browsers. It already works great on most browsers though. The performance of modern browsers is improving at an impressive rate. I haven't heard any complaints about the performance on desktop for as long as I can remember now, and I think that's enough to prove HTML5 is not fundamentally slow. The only reason mobile is sometimes slow is due to a Crosswalk bug that hung around for a while (and should be fixed in due course so it performs identically to Chrome - it uses the same codebase), and possibly the fact Cordova still doesn't use JIT on iOS by default (which should be fixed in iOS 9, and despite this I have very rarely heard of performance issues on iOS, so it seems to be OK already!) As I've said before... anything which has a fix on the horizon isn't much of a reason to give up on the technology entirely.

I've not heard of this before, and it's a bug if it's the case. Have you filed a bug report? Ideally the NW.js exporter can work at best performance without having to install anything extra.

Ashley

I have not filed a bug report because NW.js is not a part of C2 and also such bug report will not appeal bug report's requirements.

If you are interested in NW.js bugs, I also found how to solve the problem with random freezez - you have to add "--disable-force-compositing-mode" to "...\Construct 2\exporters\html5\nwjs\package-win.json"

To clarify a bit further....

The biggest bottleneck of C2 is most assuredly non-native exporters. It is the biggest worry, the biggest pain, the biggest provider of uncertainty, and the hardest hurdle to overcome of C2. It's not just me, everyone has been saying this for a long time.

I think it is worth every effort to bring native exporters to this engine; I would rather have that than all of the new features that could be dreamed up combined!!!

It is not our "code". It is not our misuse of the events system. It is the reliance on 3rd party exporters that destroys more projects than anything else by far.

I speak not from personal experience alone, but from the many experiences of countless other C2 users all throughout these forums.

Native exporters would make C2 a world class game engine, otherwise it will sadly never be a consistent/reliable professional tool.

Do not count me into "EVERYONE".

Every feature has cost. Ashley had told again and again that it will be a huge risk for native exporters.

Using other game engines which has native exporters like unity3d would be a better solution, imo.

rexrainbow

I hear you loud and clear, but the cost of not putting native export into this engine is already greater than the cost or risk of putting it in, imo.

rexrainbow

the cost of not putting native export into this engine is already greater than the cost or risk of putting it in.

It is better to proof this statement more clearly to Ashley.

But I did not think this statement is true.

I would wager the single biggest reason people are leaving/have left C2 is for this reason alone; Poor exportation which causes poor performance....

If I am trying to ensure the success of C2, I would rectify this problem posthaste

STARTECHSTUDIOS

It proofs nothing.

Users will leave, yes, it is a risk. But it does not mean the risk of users leaving is greater than making native exporters.

Otherwise we will continue having the same difficulties with Construct 2 that we have had from the beginning......

I believe they can do it. I believe they ought to do it.

Imagine for a moment..

A larger developer sees that an easy to use engine like Construct 2 can export natively to all devices. They go ahead and give it a try, especially since the cost/time of production is significantly reduced, which it will be.

A few larger developers make some really big games that get a lot of attention and success..

Other developers see their success..

A bunch more developers jump onto the C2 bandwagon and it skyrockets in popularity and users.

How can this happen if developers are initially scared to come near C2 because it cannot produce a reliable product because it depends on 3rd party wrappers exclusively?

I would rather have native exporters than any other feature, all the way.

I'm for having native exporting. Relying on 3rd party exporters is an easy way to kinda shift the blame to them if performance isn't up to par as expected. But then again, how much of it would affect the development time of C3? Possibly quite a bit. In which case i would probably be on my way to using something else in the mean time that serves my purpose. But for me, my initial target is the desktop in which C2's performance has been fairly impressive considering its all HTML5. But i can't speak for those building on the mobile platforms though.

Also, I wouldn't mind having different native platform exporters being implemented over time though. Not everything has to be ready all at once. But if there is a movement towards that direction then i'm all for it.

Ideally the NW.js exporter can work at best performance

My game(with a lot of WebGl FX) in Google Chrome work much better then in last version(from the Scirra Site(PS: when you will update it?)) of NW.js

Chrome FPS: 58

NW.js FPS: 40