Different Jump strengths on different machines.

Hello, I've got a platformer game under production. I've decided to put the code for the game's main character in it's own event sheet. And from there, I put together a big test room for me to gauge the character's maximum comfortable jumps and whatnot. You know, basic things to help build tighter levels.

My problem is that character jumps further on some machines than others. In fact the character's ability to jump seems tied to the processing power of the machine the game is running on. The slower the processor, the better the jump.

Test machines so far are:

a 2 year old Cintiq Companion Tablet (slowest)

a 3 year old desktop pc, Intel i5 3570k (mid)

a brand new desktop, Intel i7 6700k (fastest)

The player character is using Jump Sustain (no special coding) for more natural jumps and I'm thinking that is where the problem lies. On the Cintiq (where the code was made) the character can use clear hurdle of 360 pixels, with about 15 pixels to spare. On the 3 year old desktop, it clears with about 2 pixels. On the new machine, it clears with NO pixels to spare.

The issue REALLY becomes a problem when I put double jump into the mix. The Cintiq can clear a hurdle of 720 pixels with little issue, the mid range can clear it on a really good jump, the fast machine CANNOT because you would literally have to have a perfect double jump.

I'm trying to make a game with tight, responsive controls. But that seems moot if I make the game for mid-range machines and it becomes unplayable on high-end machines, or target high-end machines and it becomes super-easy and floaty on low-end machines.

A possible solution would be to ignore Jump Sustain in favor a fixed jump. But that just kills a lot of the gameplay value for me. Does anyone else have a suggestion?

If anyone is curious, the specs for the player character are as followed:

Max Speed 440

Acceleration 800

Deceleration 1500

Jump Strength 850

Gravity 2500

Max fall speed 1000

Double jump Enabled

Jump Sustain 250

You can always force 60fps using system commands to ensure the mechanics and physics work the same regardless of hardware.

Only old devices will be considerably slow if you didn't make sure to code properly to improve performance vastly.

That's an intriguing way to handle it. Is the framerate of the game running directly tied to how often physics calculates, then? If so, could I instead force the game to run at 33fps or something lower than 60fps in order to even out things without killing performance on lower systems?

I'm researching things and seeing that dt (Delta Time) is not framerate dependant. Maybe if I find a way to change the values for jump sustain to dt instead of milliseconds, things would be standards across all systems. Or am I thinking in circles?

I'm just going to keep adding edits as I find stuff I guess all the calculations for behaviors do indeed use dt already. So that leaves me back at square one, with no idea why I'm getting different results on different systems. And there seems to be no easy way to throttle fps to 30fps, just keep them from going under 30 fps (or under 60fps) which would make the game play in slow motion on lower systems. Not a great option either...hrmmm...think think think...

Further edit: Well I tried your suggestion of setting the minimum fps to 60fps, and that does seem to even out the experience for each of my test systems, just not the way I expected. The high end system now mimics the jump strength of the low end system (i.e. the largest jump), where I was expecting the low end systems to mimic the jump of the higher end system (the lowest jump). This boggles my mind as I would expect the higher frame rates on the more powerful system were what caused the smaller jumps, so forcing all games to process at that level should have made all the jumps small...getting a headache.

Anyway, despite my confusion over this, your suggestion has fixed my problem as far as I can tell. So thank you Sethmaster

Using deltatime would fix your issue.

Relying on X seconds, it will vary based on framerate and system power as you have discovered.

Applying deltatime to your jumping, and controls in general - you should notice a perfectly measurable jump no matter what the system specs are.

Built in behaviours already use deltatime, but if you're modifying the default behaviours or not using them at all, you may need to apply deltatime to those modifications or to your custom movements across the board.

~Sol

This is a long-standing issue with the platform behavior; nothing to do with using dt in events.

There has been a number of threads about it already, like this one:

There's one solution by JohnnySix at the bottom of that thread. Last time I implemented/tested it was 2 years ago so I dunno how well it works now but it's worth a shot.

If you use the system action "set minimum framerate to 60" then the jump height will be exactly consistent at the expense of going in slow motion on weaker machines that can't run at 60fps.

This is a long-standing issue with the platform behavior; nothing to do with using dt in events.

There has been a number of threads about it already, like this one:

There's one solution by JohnnySix at the bottom of that thread. Last time I implemented/tested it was 2 years ago so I dunno how well it works now but it's worth a shot.

Ah, good to know... I assumed he wasn't using behaviour driven control for his jumping. Well that's a bummer... :/

~Sol

I think I figured it out. The platform behavior uses imperfect approximations of the physics equations for projectile motion to save processing time (which is done pretty often in computer games). The approximation is usually good enough, but as dt gets bigger, so does the error. Thus, machines with different speeds have different frame rates, have different dt's, have different amounts of error. I made a sample capx with the exact calculations for Y movement. X Movement still depends on your machine until you reach max speed, when it should always be the same. The minimum frame rate at the top is just to adjust for testing purposes. Unfortunately, the new method was incompatible with behaviors, so everything is events, down to the collisions. I doubt anyone is actually going to want to use this in the long run, but if you do, be advised you can only use rectangular collision boxes.

So-called "Perfect Jump"

Eh, Steve!

I greatly appreciate all the input from everyone on this topic. I'm an artist, not a trained programmer. (I have a methodical nature that seems to work well for it, just lack the "language skills" of using direct code) So it's great for you to break this issue down like you have.

My intentions for the game are to release on Steam, and WiiU later(probably NX at this point). So I think pegging the fps will be the easiest and best solution for me, as I won't be worrying about performance issues on mobile platforms.

I've really been enjoying the delicious frustration of game making, thanks to Construct. Learning skills I never knew I had. So thanks again to Scirra and their awesome community