Frustration with moving platforms

I have been heavily developing several games for 3 months now and feel that I know Construct2 quite well. So far I have been able to work out every technical problem that has surfaced...except for one.

Getting a non-floaty feel to moving platforms has thus far eluded me! The built in platform behaviour, in general is great and suitable for most platform uses. But when a sprite lands on a moving platform it always lags and looks very "floaty" for both horizontal and vertically moving platforms. I could never put out a professional game that had that look, since you don't even see that in classic games of 20-30 years ago!

I have tried to code my own platform behaviour, but have run into many issues. It seems that even pinning an object to a moving platform looks laggy, whether I use a sine behaviour or a manually created sine expression.

I have also played with using physics to create platform behaviour, that does work but once again won't stick to the moving platform properly.

Even just using a basic expression to constrain a sprite to a moving platform results in lag as can be seen by this basic example:

dl.dropbox.com/u/94794009/Contruct_examples/platform%20lag%20example.capx

I really love using C2, but this is driving me up the wall and can really limit what I can do with a platformer. If anyone has any solutions or has written a custom platform behaviour I would appreciate any feedback!

cheers...

zendorf

Probably not a good answer for everything, but how about applying the same sine movement to the player and turning it on when on the platform.

It's like an "off by 1" bug in Platform(or more basic: Custom Move) plugin:

Current.X = Self().X + Base().X

But Self().X and Base().X is not evaluated at the same tick, so there is an offset between the Platform and it's base, and this offset is becoming more visible when Base change it's acceleration or direction.

Thanks for the replies.

Wisher, I had suspected that they are not being evaluated on the same tick. Is there any way around this?

As can be seen by my very simple attached file, even manually constraining a sprite to a platform with sine movement exhibits this same problem. It is not limited to just behaviours though, as it also happens if I put in a manual sine expression for a platform(ie no behaviours).

Seems that any way of linking two objects is an issue, since using the pin bahviour on an object also has the same problem. It is a worry that I can't constrain two objects without any slippage occurring. Would love to know a solution :)

zendorf

Unfortunately, I have no experience in javascript, and decide which objects should evaluate in the same tick is completely depends on the plugin's designer, so what we can do is wait and pray Ashely can fix this bug when him available.

Yeah, it looks like a side-effect of the fact that behaviors are calculated at the bottom of the event sheet. Ashley is this correct? Anything we can do about this?

Well, I managed to fix the "off by 1" bug through the eventsheet. but I think this approach is very ugly and inefficient, so I still hope Ashley can fix the native code for more clean solution.

https://www.dropbox.com/s/4nxvv5mc9emqvqf/OffByOneBugFix.capx

Wisher, thanks for the file, it is an interesting solution. Not sure how practical this is as I was not able to get it to work with multiple platforms. Don't know how this could be applied to a sine style platform movement, but I am playing around with your file and it does give me some hope!

Ironically I recently came up with a dynamic lag setup using arrays, that I was using for some enemy behaviour. The enemy would be 60 frames behind the position of the player. Was wondering if this could be applied to platforms so that they are one frame/tick behind the player movement. Seems like a very unnecessary thing to have to do though!

Squiddster, you may be right that some behaviours may be calculating on a different tick to the other events? Which leads me to an example that I hope Ashley can look at, since it illustrates some weird, inconsistent behaviour:

dl.dropbox.com/u/94794009/Contruct_examples/lag%20bug%20example1.capx

In this example I have 5 leaders and followers with slightly different setups. Really, all followers should be sticking to the leaders perfectly, but as can be seen this only happens in two cases...3 and 4.

Examples 2 and 4 are setup with the same behaviours. The leader has a sine behaviour with a pinned follower. It can clearly seen that example2 is lagging but 4 is not! The difference was that example2 initially had a platform behaviour on it, that was then deleted. Also it had been cloned from example1. Seems that deleting a behaviour leaves some remnants?

Also, examples 3 and 5 have no behaviours, but have a manual sine expression for the leader and a position expression for the follower. As can be seen, 5 is lagging, whereas 3 is not. The difference was that follower5 initially had a pinned behaviour that was deleted.

This is doing my head in, trying to replicate the bug, so I really hope that Ashley can take a look at this file. This sort of inconsistency is unacceptable in a game engine.

cheers...

admins, is there a way that I can move this thread into the bugs/dev forum or should I start a new thread there?

cheers...

Ok, so I filed an official bug report for the pin and set position lag. Not sure if others consider the platformer behaviour lag as a bug or just a limitation ,and if I should submit it officially? Considering how many buy this software to create a platform game, I can't believe I am the only one that is annoyed by it?

There is no reason not to submit it as a bug, I suggest you post it at the bug sub-forum immediately.

This bug is related to tick group managment, and in this level the developer have to be very careful not to break the other mechanisms while trying to fix it. so we better give Ashley more time to think it over for best solution.

Since I have already posted a similar bug report related to the pin and sine behaviours, I will wait to see what becomes of that. There is obviously a timing issue with behaviours mixed with standard events being calculated on a different tick.

How deep in the game engine this code is, who knows? I can only hope that the powers that be fix this issue sooner, rather than later :)

Just wanted to give a big props to Ashley and Scirra for fixing this issue in the latest beta! It works perfectly now, from the quick tests I have done. This will make a huge difference to anyone creating a platformer.

I am not used to seeing bugs fixed so quickly in the professional software I use, not even apps that cost 30x what C2 costs. C2 has definitely been the best purchase I have made in a while :)