No. C2 is the last version of Construct I'll ever use. I'm currently learning C# and once I learn it, I'm not coming back. There's a few games I started in C2 that I want to finish, but I'm ok with remaking them in C# if I can't finish them by the end of the year.

I feel betrayed by Ashley with the announcement of C3, and I'm not supporting him any longer. There's no reason for C3 to be in a browser other than it being an excuse to charge a subscription and call it a "service." Not allowing people to own a copy of the software they pay for and locking them out of full access of their games if they don't or can't pay yearly for the subscription is wrong in my opinion.

I'm sure in a few years years, he'll ask where did all those people who were against the subscription model go, just like he keeps asking where all those people who supported Flash went years ago, and I'll answer him right now so he doesn't have to wonder for long... We moved on to better things.

Best of luck with C3.

This about sums up my experience. But if you say it out loud, and they're using your game as a showcase piece for C3, expect them to pull it.

¯\_(?)_/¯

That only supports two motors, and controllers have more now. And if I had to hazard a guess, you're better off on asking 3rd-parties to add support for things that would be useful for game deployment.

This applies mostly to mobile device vibration. I think the gamepad vibration spec is still under consideration. Gamepads have multiple rumble motors and this spec only references a single vibration target.

Ashley

Are there any plans to add this to C2, since you've said it uses the same runtime?

If you think Construct 2 can't handle graphically intensive games, then as ever, rendering is bottlenecked on the GPU. So if you switch tool because of that, the hardware isn't going to be any faster, and the performance won't be any better.

I think some people switching tools have hardware-bottlenecked games and are eventually going to realise it was never C2's fault. I do see a lot of games bottlenecked on the GPU, and everyone knee-jerk blames C2, HTML5, Chrome, or anyone or anything else. I don't know why it's so hard for people to believe they've fully utilised the hardware? The engine is designed to let you do just that. I'm happy to be proven wrong, please send me your projects and all that, but it usually only confirms the point. I imagine some people will wander from tool to tool always thinking everyone's engine is awfully slow, never recognising that hardware is a limited resource.

Just to pre-empt how this discussion usually goes: now someone's going to shift the goalposts and talk about some random bug or some quirk that we fixed, or some other problem they had at some point, or start listing their personal laundry list of things they want changed. That has nothing to do with GPU performance. On this specific point, C2 is as good as a native engine, and I stand by that.

I shouldn't be running into bottlenecks on a 970. Or a 1070. Even the low-end target of a 750 (which should be lower, but can't be because of issues with C2) for Sombrero. If I'm running into fillrate issues in C2, that I don't run into elsewhere? That's a C2 issue. Period. Maybe the F2B renderer would have helped, but it was abandoned quickly and hasn't been brought up since. No point in waffling about on it - C2 is slower than the competition in getting things on screen. The reasons aren't especially relevant in the end.

So, no. No shifting goalposts. C2 simply isn't as fast as native, or whatever you want to call what other tools are doing. This is aside from issues with getting games running on as many of the platforms people buy games on as possible, which is also less of an issue with other engines, aside from the frankly embarrassing "support" for the Wii U, which was anything but, or the longstanding (years?) mentions of XBox One support that are still nowhere to be seen in terms of actually being able to RELEASE a game on the platform, with the features gamers expect. If I had to hazard a guess, we may end up relying on third-party support for that platform as well, much like Steam4C2 is much better than the support Scirra provides for Steam features, despite both being based on Greenworks.

I'm not talking about issues with HTML5, either; I'm talking about C2 specifically, and I suppose C3 considering it's basically just C2 with a different IDE, higher costs, more complex plugin development, and less flexibility for developers to do their own local builds with their own toolchains for NWjs on desktop & mobile.

You'd think that every dev that's made anything of scale in Construct having to move on to other game creation tools would be enough of a hint, but stand by your point as much as you'd like I suppose. The people buying games don't care about a game's tech, as long as it works as expected and provides good performance. It doesn't matter how easy C2 may be to use to make games if they have far higher hardware requirements, and are limited to less platforms than similar games based on different tech, limiting their market.

Anyone who ever got their hands on the WiiU + dev kit had learned quickly that C2 games weren't going to run well on it (especially anything non-turn-based/action oriented)

Jayjay

If memory serves, since I've long ago returned my WiiU devkit, this was due to Scirra's stubborn refusal to support the way the Nintendo Web Framework handled hardware acceleration, which was available for HTML5-based games. And didn't a third party actually have to finish implementing the framework, since what Scirra provided was the bare minimum of feature support, and not what NWF was capable of, even outside of hardware acceleration?

You say that, but there is an overwhelming amount of people who say otherwise. A lot of C2 developers have switched to Unity because of performance. Who should we believe?

Performance aside, I think C2 and C3's biggest problem is third party wrappers. I haven't found a wrapper that I haven't experienced some trouble with. If C3 was native, you wouldn't need to rely on HTML5 wrappers. Construct is fantastic for browser games, but it's a real pain trying to get it to work on other platforms.

Listen to the developers who end up having to move on. We're far more familiar with the real-world performance of C2 and the endless issues with getting it to run well on multiple desktop platforms, let alone mobile or console (which have no real support) where performance just isn't there for anything graphically intensive in C2. We also have less of a vested interest in sweeping the issues under the rug.

Changing the subfolder an object is in does not change the order in which they're stored in the XML file, or it's ID. You can look at the XML files to see this.

As for "presumably" - yeah. No. Presumptions don't help solve the issue. Especially when they're not accurate.

> *quote snip*

>

> I didn't mean "behaviors" in the sense of C2 Behaviors. I meant functionality (through events) shouldn't be affected by what folder something is in. Poor word choice on my part.

>

The events are only being indirectly affected. The functionality change isn't related to the events at all. You get different results because the behaviors (both platforms and the sine) evaluate in a different order. This causes the positions of the objects to be different than they otherwise would when the event sheet is evaluated, which then changes the result of the conditions. You can see this when the player 'lags' behind the other sprites. The platform behavior attempted to solve this problem by doing its move logic in 'posttick' while other behaviors use 'tick', but all this really did was move the problem, which is made clear when you have a platform object stand on another platform object.

There are ways that this could be changed so that you don't have to think about the tick order of behaviors, but I wouldn't expect to see them in Construct 2, what with Construct 3 being the primary development focus now.

C2 doesn't export objects in folders, it's all in xml files, where they're stored in the order they've been created, regardless of the "folder" they're tracked in through the IDE.

For the 96% of devices, WebGL is native performance. It's bottlenecked on the hardware.

This is 100% untrue blaming-shifting nonsense. Performance on even powerful desktop GPUs is around half of what native provides for larger desktop games, and saying half is being generous, and reaching only around 50% of native performance involved a LOT more work than it would using other game development tools; hell, there's not even a way to set the canvas resolution easily in a way that takes into account object positioning, because you've somehow convinced yourself it isn't necessary (even though native apps support this with switching monitor resolution out of the box), and only offer "low" or "high" settings. Blame drivers all you'd like, but it's what literally every PC uses, so complaining about and/or blaming them is pointless navel-gazing. Blaming the only ways to export games for poor performance is highly disingenuous, since they're the only way to export and sell C2 games. I can't even imagine the gaps in logic that allow someone to arrive at your performance comparison conclusions.

You've hitched Scirra's wagon to HTML5, and that's fine. But let's not pretend it's even close to a mature technology, from a software/development standpoint all the way through hardware support, for the creation of medium-large games. The performance simply isn't there, and you're flat-out wrong to suggest it's remotely close to performance of native with anything more than a very, very simple game with absolutely no bells & whistles.

>

> > Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

> >

>

> Yikes. That is no good. Load order shouldn't affect behaviors like that.

>

> Ashley, have you had a chance to look at this yet?

>

The behaviors need to be updated in some arbitrary order. Construct 2 tries to hide some of this from users, but since it can't automatically figure out what your intended behavior is, you will inevitably have to deal with it at some point. At least like this, you have some level of control over it.

This is why I prefer to use events whenever I can, since I have complete control over the order those run in. Behaviors could have this same level of control too, IF they provided the option of disabling their javascript tick functions and using an action to trigger them instead.

I didn't mean "behaviors" in the sense of C2 Behaviors. I meant functionality (through events) shouldn't be affected by what folder something is in. Poor word choice on my part.

Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

Yikes. That is no good. Load order shouldn't affect behaviors like that.

Ashley, have you had a chance to look at this yet?

Ashley this is a bit of a big issue.