Need help with custom movement (Platformer)
I feel like i will break my brain because i simply cannot understand why the following is happening:
Can someone please help me figure out how to make it so player can easily get up and down in the places with red circle ? Currently player have to go back and forth until he will finally fall or get up which is extremely annoying.
Added mfa to the attachment.
You're moving multiple pixels at a time on X, which can cause the box to shoot over the gaps except in very specific situations because Y hasn't had a chance to calculate yet. Since you're using floats anyways, Y will take a frame to even start falling, making the situation even worse. Fixing this while retaining your Player shape would require either:
A) A check 1 pixel down/up on each loop, that will let you know whether or not there's a gap there
B) Finding a way to combine X and Y loops so that they fire one after another (i.e instead of your loops firing like this: XXYY they would fire like this XYXY)
Both are probably more trouble than they're worth. The easiest solution is to make your Player box skinnier or the gaps wider. This is more natural and smooth to play with anyways, and is what 99% of platformers do since needing to be pixel perfect to go through gaps can be (scratch that, is ) incredibly frustrating.
@casleziro Thanks for the answer ! Sadly i need to keep the player size the way it is. Ill try to get it to work using your tips.
Meanwhile if anyone feels like they have some time then i would really appreciate if you could also try to get it to work and send your version on mfa.
I got no clever solution, I'm just curious. Why do you want the player to be the same size as the gaps?
@chrilley In my opinion it looks and feels the best when player cannot wobble in some tight spaces. Also somewhat of a ocd in general.
Hi Wii1Mii,
I have an idea but I haven't worked in The Games Factory in some time.
Basically, you will have to let the game know where the player will end up before the player gets there. You could set up the logic like this for a "go forward if key held, but reverse back to original tile if key released early" :
1. If player holds right key, add 1 to variable like "go-right" going right, and forbid the variable from becoming "2". Boolean. If player lets go, variable becomes 0.
2. While player holds right key, add a variable per millisecond like "hold counter" and also begin advancing player's character by one tile (this can be achieved by measuring the width of a tile/player character in pixels and having a function like "while go-right is 1" and "difference of [movement variable] is less than [tile width]" then "advance X placement" and "tally each pixel moved to the [movement variable]"
3. When hold counter reaches 250, "cancel movement" is inactive, otherwise, if player releases key before 250 (one quarter of a second), the "cancel movement" is activated.
4. When movement is overridden by player holding key briefer than 0.25 second, this causes the player to return to [original position] recorded (original position should be updated after each movement). It can be instant or gradual by having a reverse of the "advance one tile" movement. This would visually appear like sliding slightly right and then sliding back in place.
5. After the completion of a successful advancement to one tile forward (use an acceleration and deceleration formula if you want), check for ground (or ceiling escape) before the player arrives. You can fire an invisible collision if you must, but this way it only fires once per tile width rather than constant checking.
6. If player character is on ground, do not activate the "drop" or freeze left/right movement. If player character is not on ground, activate "drop" and prevent left/right movement so your square drops straight down.
7. If jump has been held, use the same principles as forward (side to side) movement and have the jump "activate" for a moment after player taps the "up" or "jump" key. That way, the jump activates as soon as the player arrives at the channel to jump through but not before. And a press of "jump" too early will not register in the tight corridors you want to prevent jumping.
8. This will require more checking and delays while in the air to monitor possible escape routes/platforms while in the air, but should be simple once again to only implement each time a tile width is achieved/surpassed rather than constantly.
It should function in such a way that holding down right arrow (or reverse the function with left arrow) will cause continual advancement, one tile at a time.
You can even have acceleration and deceleration by making the movement variable advance by greater and greater numbers, i.e.; add 0.5 pixel per millisecond, then 1 pixels, then 1.5 or 2, etc. (as "go-right" or "go-left" are active) and cap it at some point, and then reverse it back down as it is inactive. Acceleration and Deceleration shouldn't be too big of a game changer since you're checking and adjusting to a final position exactly on top of a tile space. rather than arbitrary position on tile fractions.
--
Another way would be to monitor the current X position and compare to a known number of possible shafts. Measure a tile and divide the player area into that many segments, logically. I mean, you could take for example a space of 200 x 200 and say there are 5 40-pixel tiles to a dimension. When a player's current X position (compared with an original X position) is divisible into the play area by an even 40, or is some number of limited pixels greater than that (like 10?) have the player character do a ground check. If the ground check fails, set that character's position to an exact multiple of the tile (e.g.; 40 pixels times number of tiles over). Even if this visually causes the player to briefly reverse in order to fall down.
I think the original idea is better, though, because you're basically having the movement all set up to occur before it occurs. If the player will fall by advancing, then it is predicted, and advancement is barred so there is no jiggly falling. This would mean that each movement ends exactly on a tile, though, and there would be no "halfway hanging off a tile"
--
Finally, a tricky way and visually sloppy way to do this would be to have the visual appear square but the actual collision model to have slopes, or be slightly smaller underneath. So you keep the player control the way it is but change your platforms physics then paste over the appearance of square platforms on top.
---
Let me know if any of this sounds okay or if you have questions about my logic. I am not familiar with the program but I used to make tons of Klik & Play and The Games Factory games.
After tinkering with it for a while, it seems adding the feature to the movement is still over my head. But i did manage to make a somewhat cheap hack that fixes it. I placed invisible block that stops player if player is +-3 pixels over the center. Its bit more complicated but works well. If anyone ever will need help with this issue just msg me and ill try to clarify how i fixed it.
Huge thanks to everyone who posted here.
Special thanks to sprink for that wall of text
Hey wii1mii
I don't know exactly how you solved
but there's a rather quick solution for the "fall in gaps" thing in your setup:
why_1.mfa
(just 3-4 additional lines)
I guess for jumping inside gaps, something similar could be thought of
Huge thanks ! That's exactly what i was looking for.
My fix makes me feel stupid now
Posting Permissions
Reply With Quote