Construct as a unity editor extension.

While the idea is not that bad, Scirra just can't afford to spend resources on something like that. I believe it is more important to polish C3 and start working on the new runtime.

Jayjay

Like me, you are for a long time here. You should know by now that Ashley is dead set on HTML5. It doesn't matter how many facts you present, or if the whole community begs for it.

Why build and focus on an "events plugin" for an industry standard game engine that exports natively on almost anything and let thousands of developers maintain and upgrade the engine, when you can reinvent the wheel and do all by yourself

Yes, C3 is a marvelous piece of software, don't get me wrong, but there is a reason why all the bigger games developers moved to other software.

glerikud

Look at Playmaker and think again (there is also a "little" game named Hearthstone that uses it)

And how you spend more resources focusing only on the event system instead of the whole software (let's not even talk about browsers compatibility now that even the IDE is browser-based).

Browser makers are as performance-obsessed as any game engine - especially Chrome. Did you know, for example, it queues all WebGL calls, posts them to another thread, and runs them in parallel as JavaScript execution resumes in the main thread to start processing the next frame? That's an incredibly complex multi-threaded architecture that helps effectively eliminate the overhead of the graphics driver by overlapping it with the next frame's logic. That is so complex to implement that some native engines don't even try, and we get that for free in Chrome. I don't think you properly appreciate just how sophisticated modern browser technology is, and it's one of the reasons we now see C2 benchmarks in Chrome actually rivalling or even exceeding other native engines on the market. And still, we have people here who think we somehow have a slower or inferior engine in some way due to HTML5. You need to catch up - our HTML5 strategy has worked out great, and that is the reality today; it's not 2012 any more.

Anyways, even just using Unity as an engine is a colossal amount of work. It's basically the same as us writing our own native engine, but using Unity as the framework. It's a forbidding amount of work for a startup and will push back everything everyone else wants by months, and - for what? Performance won't be that much better, if at all (I've read several criticisms of the poor performance of Unity for 2D games since it carries a lot of overhead from being a 3D engine). I think all it gets us is PS4 support. I agree that is important and can see how significant that is for many indie games, but that's not something we can justify that amount of work for right now. There's also a chance they could add HTML5 support anyway, like the Xbox One has, making such a project pointless and extremely risky in terms of investing our resources. And hey, at least you can publish to Xbox One with the Xbox Live Creators Program, it's not like you have no access to consoles at all.

Just a thought.

Given how complex Unity is, I think it would be a better idea if such a thing as an editor extension would be better off being made by someone who has extensive experience with Unity.

That being said, what, if any additions to the new runtime, and sdk can be made to make something like that, or some other type of exporter doable?

Well, first things first

Back in Flash days, you would make a game, copy 2 lines of code from CPM Star and have a single file to distribute. It worked in every browser.

HTML 5 so far ( after how many years ? ) is shit compared to that. The whole bullshit around the game ( wrappers, distribution, monetization ) takes twice as long as making the actual game.

Anybody wanna address that first?

Scirra should have just answered the post with a simple statement that they have no time\desire to do what the OP was requesting.

Despite the rhetoric here, both C2 and C3 rely on third party components either to run in a browser or to run on any other medium.

C2 and C3 are great for browser games - like well they are HTML5, but for any other type of use they are only good for prototyping.

If you are serious about making games that do not run in a browser you have to use other tools - it is that simple.

While the event system is awesome, sometimes you just have to bite the bullet and learn other tools, which will require coding.

Despite the fact that Chrome is an awesome piece of engineering (apparently), Google like any other company out there simply DON'T care about how others use their tools\products - the jank problem was absolute proof of that. Firefox, or any other browser maker will be no different.

As already said, there is a reason why the big devs have moved on to other tools to develop their games, which amazingly are still the pull-strings on the home page - think about it....

C2 and C3 are great for browser games - like well they are HTML5, but for any other type of use they are only good for prototyping.

Why do you say that? I already pointed out how our engine is more or less as fast as other native engines. Everyone keeps bringing up v-sync, talking about a bug that was literally fixed in 2014. It's not been an issue for years. With today's tools and capabilities - what's the issue? There literally is none as far as I can tell, people are just dredging up old and years-ago fixed bugs to try to make their case. As far as I can tell this is nothing to do with technology, it's entirely just people's perception of it - which means there's nothing for us to actually fix in our code...

I've ported most of my game to Gamemaker so I feel I can speak with some confidence about this. From my observations, Construct builds seem to run about as fast, if not faster than, Gamemaker builds on desktop. C2 definitely outperforms GMS on one of my old laptops, where I get 55-60 fps for the former, and 45-50 fps for the latter. But jank remains an issue. My C2 builds may outperform my GMS builds on slow computers but GMS never does the tug-and-jerk screen update thing. Never ever. It runs smooth or it doesn't. Consistently.

In my opinion, this is a pretty big deal and I urge Scirra to really look into it, not just hand-wave it away whenever the subject comes up. I won't go back to Construct for several reasons so it doesn't affect me either way, but it's a shame for an otherwise great product to be held back by these sorts of things.

Adding to what ErekT said.

Doing this will reveal just how bad it can get:

The project has just this + platform behavior and 3 solid planes.

The square will keep randomly changing to black and white in Chrome and NW.js export.

On some NES games there's bits that fake transparency by having sprites flash on/off at 60fps.

Doing so on C2 is gonna reveal the random here and there long delta when the sprite holds on or off for 2 frames.

I don't really get the dt>1/40.

Seems like that would look janky by default.

I don't really get the dt>1/40.

Seems like that would look janky by default.

The point is that dt>1/40 should never trigger. If my little jumpy square switches colors, it means something's wrong.

Yeah, no, you're going to have a 10 ms variance with javascript no matter what.

Issues like the jank and other oddities are really annoying- especially when Scirra pins the blame on the user's fault.

Also, did you people see how they did this in the latest c2 beta: "Platform behavior: 'Is by wall' is now true if the player has an obstacle directly above them"

edit: nevermind- I forgot that it has an option for left/right wall.

i think the closest thing for this to happen is the new copy and paste system. Ashley or any smart developers here (not me

Ashley might not need to develop this because of the available sdk for c3.

could also be copy and paste to Lua language (because its looks more text like) and paste it to defold or cocos

a lot of possibilities, a lot of work also

Last I checked, most browsers could v-sync reliably to within 0.1ms. I'd be interested in any .capx examples I can try out. It's also important to say which browser and OS you're testing on.

Prominent - I don't understand what you're upset about - previously, you could be standing by a wall, and "Is by wall" was false if you happened to also have a ceiling above your head. We fixed it so it's true again, as some other users noticed and insisted ought to be the case (and I agree). There is a backwards-compatibility risk which I carefully considered and was worried about, but I think you have to admit it makes more sense this way. Do you disagree? Should "Is by wall" still be false if you are by a wall, but happen to have a ceiling above you?