Construct as a unity editor extension.

Your article is the case against Construct Classic.

No, it's a case against making native engines for Construct 2 and sticking to HTML5. It addresses your points.

Trying to follow this thread as it is seems to get a bit out of topic. But what i guess people are saying is...

They love the event sheet way of doing games but not so happy about the c2/c3 as an engine?

I can get where they are coming from, as i would like to try make 3D games, but Scirra has no intention of adding 3d support, and probably would't make an event sheet plugin for other engines. Using event sheet is the only way that makes sense to me. So I'm kind of stuck here, LOL.

All in all I think Construct is a great product though, but I also wish every engine had an event sheet. Kind of like music software has a sequencer/key editor, because I don't really feel like growing a neckbeard and start drinking jolt cola, and learning how to "code" lol.

+1

Hear hear!

I am working in Unity at the moment because our current project is 3D. I would be thrilled to work with event sheets. And, although it is probably a pipe dream at this point, I would love to see Scirra take a stab at combining their awesome event sheet editor with a 3D engine.

The sooner I can get back to working in Construct instead of Unity, the happier I will be.

> Your article is the case against Construct Classic.

>

No, it's a case against making native engines for Construct 2 and sticking to HTML5. It addresses your points.

I honestly don't see how it answers my points. An (although beautiful) low-collision count top-down racing game and a few tech demos dont hold up to actual CPU-heavy games/platformers on Steam whose developers are telling you HTML5 is not matching up to expectations set by similar tools (eg: Classic and Fusion and GameMaker)

The ones that are already porting to other engines (including us) are finding we can fit more visual FX and complex code into the game yet have smoother performance and support for lower end hardware and even mobile and consoles.

Plus it also doesn't answer: Is C2 really that much more optimized than CC? Because if it is then it stands to reason that CC can't be used as a "native" benchmarking tool.

I asked before how many work years it would require to have a native exporter

For 100% compatibility with the C2 runtime, essentially never - not before we went out of business pouring all our efforts in to trying to essentially rebuild a significant proportion of a browser engine, which are made by huge corporations with thousands of engineers working round the clock. So, you say, why not throw away the features which are hard? Because lots of people use them, want them, and buy C2 licenses for them, and then it causes a huge compatibility nightmare with porting projects. These consequences are worse than any of the problems you think this might solve.

I honestly don't see how it answers my points. An (although beautiful) low-collision count top-down racing game and a few tech demos dont hold up to actual CPU-heavy games/platformers on Steam whose developers are telling you HTML5 is not matching up to expectations set by similar tools (eg: Classic and Fusion and GameMaker)

There was a bunnymark benchmark recently that showed C2 in Chrome equalled or exceeded those engines. So I am confident in saying JavaScript performance has reached the point where it can equal native.

Ashley Bunnymark was not optimized for each platform. It was a rough comparison at best and there were many people seeing higher results for native anyway.

It is a good comparison of sprite rendering which you have done well with due to WebGL. It would have been nice if WebGL was supported on WiiU for sure.

Ashley Bunnymark was not optimized for each platform.

I think it was a fair test. I'd be happy for you to provide an alternative test if you want, IIRC someone was hosting the tests openly on GitHub, and the tests were independently created (not something I put together to prove a point). The test is also CPU-bound on draw calls so I think it's a reasonable comparison of each engine's CPU performance. I think it's reasonable to also say that if JS can rival native in this area, then it can in other areas. So if our engine is slow in any respect, it's probably not because of the use of JavaScript. Perhaps we could make improvements in some parts of our engine, but the point is it's probably not slow because of JavaScript. So in this day and age, I think it's naive to say we should change language to improve performance, especially when the costs of doing that are extremely high.

I think html5/javascript is a good platform to invest in. I do feel at times that the more complex a construct game becomes, the more unstable it runs. There are various small things that have been noticed by users that effect a game's performance, such as function calls requiring more processing, multiple tilesets, etc. And all these things add up, especially if you aren't aware of how to avoid the problems. And who knows what else there is.. There have been many times where I implement something, and get a weird feeling that it should run better than it does- maybe because construct adds extra stuff to ensure a more universal possibility.

I'm more interested in construct allowing more customization for users, so they can better control how their games can be developed and how they run, etc- there is still so much that can be improved, and construct is already a really great tool.

Posted this in the other thread as well, but since it's also relevant here:

Can confirm jank in — 's post on my GTX 1070 + i7 6700K:

CC: at 950/frame, 28fps (running in background/not in focus), no jank

C2 / NWJS: at 600/frame, 33fps (running in foreground/in focus), jank

Amazing how proof gets ignored hey!

The conversation was continuing over here but then got buried:

I don't think it's being ignored willfully, but I do hope it's on the back-burner of things to look into (as if a performance increase comes out of it, then we all win!)

Everyone thinks that making a native engine will magically fix everything. It's not the case.

But everyone DOES think it.

>

> Everyone thinks that making a native engine will magically fix everything. It's not the case.

>

But everyone DOES think it.

I don't just think it, I KNOW it thanks to remaking our entire game in the Unity engine

>

> >

> > Everyone thinks that making a native engine will magically fix everything. It's not the case.

> >

>

> But everyone DOES think it.

>

I don't just think it, I KNOW it thanks to remaking our entire game in the Unity engine

My point is:

a) listen to your customers.

b) do what's right for them, not for you.

c) even if they're all wrong, listen to what they're saying and why they're saying it.

Obviously c has worked out great so far.

Obviously c has worked out great so far.

Newt got it

Zebbi I meant that I already know native will be better because we have already tested and proven it for ourselves. Especially on consoles (and even mobile but we wont be planning a release for that platform)