C2 Jump innacuracy controversy

M'kay, first of all, im late to the party since this has been reported by Scirra themselves months ago. I did a search here in the forums and didn't found anything, so apologies if it has been already discussed apart from a few comments on that blog post.

The thing is, platform jumping height in C2 is not consistent. I ran into this today (because weird bugs love me) in my project since my character jumps just enough to reach a certain number of tiles. To my surprise, while testing on a mobile device with worse performance than my pc I found out that I could only reach that height after a lot of tries. Upon further testing on pc, I saw that it fails to reach that kind of jumps sometimes. It also seems to jump a bit higher if you have horizontal speed (so it's specially problematic trying to jump over a wall while just next to it).

After employing a lot of time trying to see what may be wrong with my project, I found that blog post and saw that it was a C2 problem.

What I find kind of annoying is that while a fix is mentioned, because of possibly breaking old projects, is apparently not contemplated on C2...but C3 will have (already has?) an option to select between new precise calculation or C2's faulty one. Why not give C2 that option too?

Now, I understand that maybe it's not an easy fix, and that C3 takes priority since it's a newer product and the future of Construct. Construct 3 is pretty good for newcomers and veterans alike, but a lot of us already have C2, does what we need of it, and are in no hurry to jump to 3.

But this kind of sneaky bug can break a game (I could have released my project without noticing and players could find inconsistent (worst case impossible!) jumps not present on my testing. And the player is more likely to put the blame on devs instead of the engine, making us look bad.

Also, I don't think it's fair that C2 gets stuck with a bug considered "embarrasing" in Ashley 's own words . Consistent jumping is just basic stuff.

After a quick look on 3 for this optional fix I couldn't found it, so maybe it's still on the works and C2 is on his way for a fix too, so it may be a moot point, but it would be good to know!

4 solutions;

• live with it
• upgrade to C3 (currently in beta)
• move to another game engine
• build your own custom platform engine in C2 using events

It's only really a minor issue. Most games are not affected by it. It causes maybe something like +/- 2px difference. Given that dt has small random variations that can alter the game as well, you generally should design your game with enough tolerance anyway, so that this kind of offset does not meaningfully impact the gameplay. With Construct 2 being in widespread use for ~6 years, it has affected few games, and for the most part accuracy to within a few px is just fine.

It was also a pretty complex change in the end, we basically ended up rewriting all the movement math used in behaviors, and it caused a few extra bugs while we got that right (like this and this, and would not be surprised if there are more since we only just fixed that second one). We're focusing on C3 for all new improvements, and that kind of maintenance overhead when making a new improvement is the kind of thing we only have the resources to put in to C3 going forward.

Most games are not affected by it. It causes maybe something like +/- 2px difference.

Just my rotten luck...bugs really like me!

I'll work around it then, I guess.

> Most games are not affected by it. It causes maybe something like +/- 2px difference.

>

Just my rotten luck...bugs really like me!

I'll work around it then, I guess.

I don't know where is my previous post, that I've updated couple of times (I hope it wasn't deleted), so I'll just double it here again.

Hey, I've just discovered the same bug in my game too. Have you, by chance, found any way to eliminate it? I'm already too far into the development, so moving my game onto C3 is not an option for me (and I also don't have a budget for it). Update#2: Ok, I think I've managed to bypass that bug by tweaking the jump height and the gravity of the player, but the bug is still there. I think that it should be fixed. After all, a lot of people still use Construct 2 and people will continue to buy it, so it is really worth looking in. With all respect to the developers, I must say that this is a very nasty issue that concerns the very basic functionality of the engine. I hope that you'll understand what I'm trying to say here. Thanks.

It's only really a minor issue. Most games are not affected by it. It causes maybe something like +/- 2px difference.

It's a meaningful difference for many pixel art games . Also due to it's sneakiness it can go unnoticed when people simply miss jumps without knowing it was an engine inaccuracy that caused it, causing the game to "feel bad"

Inaccuracies like this have forced me to do an extensive extra rig for the player to ensure jump consistency.

You can get around it case by case, like for height accuracy you can record your ground Y position on jump, then if your jump peak falls short of your projected max jump height and the jump button is still held down, you move the player to your max height position based on the initial jump Y position.

There's more to it, but for each game a few special case helpers should at least alleviate the issue, if not remove it completely.

In the end, jumping games often have a lot of smoke and mirrors going on anyway to improve game feel, like snapping, late jumping, placing the player on a platform they should've missed, conditional control overrides that try to guess the player intent and so on.

Having the default behavior as accurate as possible will improve game feel for C2/C3 games in general even if they have minimal "helpers" implemented.