Construct 3 - many questions (native exporterts)

>

> I really think some people have the impression that if we write a native exporter, hardware specs will magically increase.

>

Ashley please just make one game with unity and then you see native performance is really different and so much better !

I won't see any performance benefit if the game is fillrate limited on a weak Intel GPU! Again, as I said before, hardware limits don't change even if you change the technology you use. It seems that most people don't understand this?

But you can play games like grimrock and even gta4 on Intel HD Graphics 4000 GPU.

3D games use a radically different rendering model which is actually lighter on overdraw than multi-layered 2D games. Also because most top commercial hits are 3D games, some hardware and drivers are probably better optimised for 3D than 2D!

Maybe all we need is an option to force desktop resolution in fullscreen to something lower to cope with weaker fillrates

That's effectively what "low quality" fullscreen mode does, and it should be a big help on fillrate-constrained devices like Intel GPUs. A fillrate-heavy game is going to have trouble on an Intel GPU regardless of the technology you used to build it.

Should we vote on which native exporter?

.....pretty everyone in this thread would be unhappy with the results.

Or worse someone will "socially engineer" what they want.

I won't see any performance benefit if the game is fillrate limited on a weak Intel GPU! Again, as I said before, hardware limits don't change even if you change the technology you use. It seems that most people don't understand this?

hardware limits don't change but game performance is changing !

make one simple game with unity and make that exact game in construct 2 and run it on same device you will see hardware is not so limit as you think !

my note 2 have a great hardware it can run even GTA with no lag (it can run supper high quality games) i mean even big games need less memory then c2 simple games need on android

but when it comes to c2 games it laggy even in simple games

you just can use c# instead of javascript for engine

then you can compile that c# to almost anything (its hard but can be done)

i know how to program and i can use unity or... and i will use them

but your c2 is a great software it can make billions you just not so serious about it

so i suggest you hire people and programmers to develop it and spend some money

i will promise you will get so much more then now

html5 still too young and i think its need more than 2 years to be like a native app

Vote for something that cannot realistically happen ? No, thanks.

I think people massively under-estimate the cost (or time, "same" thing) to develop these "native" exporters ; plus the on-going maintenance overhead as platforms keep changing ; plus the fact that in a given family devices themselves behave differently (e.g. many sub-categories of Android devices, etc.)

If people like the Construct ease-of-use but want native tech for whatever reason, the ideal pipeline today is :

• develop prototype in C2 ; this way all the gameplay-related risks can be mitigated
• use a platform specific tool/engine/framework to develop the full game ; this way all the technical-related risks can be mitigated

Yes that's more work, yes that's more complicated, yes that takes longer.

But "easy creation" + "complex product" + "cross-platform" is a risky mix.

[quote:2nt1w883]so i suggest you hire people and programmers to develop it and spend some money

i will promise you will get so much more then now

And start competing with bigger products that have already poured $millions to get where they are ? That's terrible risk management, business strategy and financial advice.

The differentiation factor of C2 is that it's more focused and easier to use ; but also obviously, as a result, more limited in certain areas. If it loses this differentiation factor, it dies.

Vote for something that cannot realistically happen ? No, thanks.

I vote for apples, though I need oranges, ... but want the strawberry on top too !!

really .... construct 2 vs unity ...

apples and oranges ....

And why do you think talented developers create their PC games on Unity?

Why don't they use C2 to create PC games?

The answer is clear for everyone - they need native export.

Nope, their ability to program in code, in something like android studio, instead of construct 2, offers them that option.

They never 'needed' it to begin with, they just had it. It is inherent to the used programming language.

For every successful android game developer (programming in native language) there are 100's who never produced a game because their games fail in ... well .. lots of ways and run like crap. They lacked insight, skills, creativity, endurance ... you name it.

Saying a construct native exporter will surely produce better games; is like saying anyone who can type a line of text is surely a good programmer able to write good games.

... right ?

but your c2 is a great software it can make billions you just not so serious about it

so i suggest you hire people and programmers to develop it and spend some money

i will promise you will get so much more then now

A business is not that simple. Scirra aimed for a gap on the market and made a very good software to fill it up: HTML5 game creation environment with visual programming. In my opinion it's fine to give suggestions for Scirra to let them see what the community wants, but at the end it's up to their will and opportunities how they manage their business.

>

> but your c2 is a great software it can make billions you just not so serious about it

> so i suggest you hire people and programmers to develop it and spend some money

> i will promise you will get so much more then now

>

A business is not that simple. Scirra aimed for a gap on the market and made a very good software to fill it up: HTML5 game creation environment with visual programming. In my opinion it's fine to give suggestions for Scirra to let them see what the community wants, but at the end it's up to their will and opportunities how they manage their business.

es 2 years ago yes there was a gap 2d html5 was a gap but

unity have 2d and html5 now

and there are other engines too so it's time to change

It's interesting the number of threads that turn into exporters because of performance X reason. Personally I think the big weakness is that C2 isn't friendly for complicated game development. Object structures, team asset management, lack of modularity, lack of Object>Sheets so on etc are so problematic. Personally and this is just an opinion if these problems were fixed

Object Structure = Scene Hierarchy with Object Pattern(ie part of scene graph of objects are saved as it's own object, similar to container, but more flexible)

Team Asset Management = art, audio files should automatically sync when updated with the requirement of manual updating to associated links.

Modularity = better re-use of code chunks.

OOP = More logistical design for creating a game that offers better more friendly development patterns to non experienced programmers. There is a reason why OOP is more common than Imperative programming. It's easier to understand, read, write and control in development software.

Better Plugin control = Moduals and plugins should be per project and stored in the project folder. So that when working in a team the plugins and modules are already ready to go.

Sprite Object replaced with SpriteBehavior that uses controlled texture atlas. This would increase performance, reduce memory, and solve poorly made projects. This also means that SpriteAnimator should also be a beahviour so that SpriteRendering and Sprite Animations are not linked.

If these problems and I did say problems were dealt with. I don't think there would be such a cry for native exporters. I feel confident that the average performance of games would significantly increase. But this is all speculation.

Lack of performance is a symptom, not the cause.

>

> >

> > but your c2 is a great software it can make billions you just not so serious about it

> > so i suggest you hire people and programmers to develop it and spend some money

> > i will promise you will get so much more then now

> >

>

> A business is not that simple. Scirra aimed for a gap on the market and made a very good software to fill it up: HTML5 game creation environment with visual programming. In my opinion it's fine to give suggestions for Scirra to let them see what the community wants, but at the end it's up to their will and opportunities how they manage their business.

> es 2 years ago yes there was a gap 2d html5 was a gap but

unity have 2d and html5 now

and there are other engines too so it's time to change

And why are you the one to decide that change is required ?

The other tools generally suck at their potential with rapid development, where as Construct still tops it all ...

Why is it not time for you to switch to unity ? seeing as you are quite enthusiastic about it

And why are you the one to decide that change is required ?

The other tools generally suck at their potential with rapid development, where as Construct still tops it all ...

Why is it not time for you to switch to unity ? seeing as you are quite enthusiastic about it

i like c2 more

and really c2 is fast and i just say need better performance

hardware is not so limit as you think !

You are still missing my point. If a game is slow because it is drawing more to the screen than the GPU has bandwidth to handle, then it doesn't matter what technology you use. You could write it in carefully optimised C++, or even hand-tuned assembly instructions, and it would not be any faster at all, because the bottleneck is in the GPU hardware. The only way to optimise in that case is to draw fewer objects, which you can already do in C2.

This thread highlights exactly my resistance to making native exporters. People identify that the game is slow on weak hardware, specifically call out a case where GPU hardware limitations are the bottleneck, and then ask for native exporters as a solution. In the described situation, the suggested solution will not help. Developing native runtimes to try and fix that case is pure folly.

As I've always said before, WebGL uses the GPU pretty much identically to a native app. Javascript has some performance overhead, but it's generally not the bottleneck except perhaps in a minority of exceptionally complex games. And with modern devices like the iPhone 6S benchmarking close to laptop CPU performance and continuing improvements to Javascript JIT compilers, this overhead is becoming even less significant. Were it a significant problem, something like WebAssembly would solve it in a far more practical and portable manner.

Anyway few people seem to understand the hardware issues involved here, so I guess we will face continuing calls for native exporters to fix hardware limitations :-\</p>

Anyway few people seem to understand the hardware issues involved here, so I guess we will face continuing calls for native exporters to fix hardware limitations :->

You could try and make an example ....

But then again ... you would throw all your skills into the mix ... which would get you a decent performing game ...undermining the thing you are attempting to achieve

Seriously though, a good example .... could potentially quench all following questions relating to desires for a native exporter ...

I think the time spent on making an example would be far less then the time already spent on answering similar questions ... not to mention those not yet asked

Is the endless cry for native exporters even because of performance? I thought the issue was 3rd party reliance and the inability to export to consoles and such. Even exporting to Mac and Linux via NW.js seems to be pretty troublesome.

I have had no problems with desktop performance for retro and HD games alike. I've seem some horribly optimized HD games that still ran very well. There's the v-sync issue of course, but that's not a C2 or HTML5 problem to my knowledge.

Mobile performance was terrible last I checked, but that was like 3 years ago using CocoonJS or whatever. I'm with Lennaert on this one. Someone just needs to make a good mobile game example.

It seems to be a mix of things that keep coming back ; easier exporting processes and deployment pipelines, performance, platform-specific features, etc.

Most of the proposed "solutions" don't actually fix the problems (cpu/gpu optims when gpu/cpu limited, etc.) or are unrealistic (take ownership of all the device specific exporters, etc.).

I think jayderyu made an interesting list of ideas to improve the creation and authoring process in a previous post ; that's the kind of things that would make a difference and that I'd rather see in future updates.