It is currently Wed Dec 13, 2017 1:48 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Tue Feb 07, 2017 8:33 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5895
Location: Canada
FrankenGraphics wrote:
If you would want... (a velocity crossfade beginning at the discontinuity)

No, I wouldn't want to do that. Not in my game, anyway.

The 2nd derivative discontinuity provides a slight feeling of immediate response to the release. Trying to soften this would take away that feeling, which I think is very important to have.

The remainder of the arc above the release point already provides an "easing off" which continues in a perfect parabola from that point. The shape of the parabola is identical to that of the full jump from a lower height, so that part of it remains consistent for all jumps, and by switching immediately to it, we get the maximum amount of time spent on its familiar, predictable path.

There's a balance between smoothness, responsiveness, and predictability that results from various choices. I don't think it would be appropriate for my game, but maybe you're making something that needs more extreme smoothness.


FWIW, I though the original version of Cheril's jump was unusual, but acceptable. The slow start to the jump is strange, but it doesn't seem to detract from the game, for me. In Lala, there's a few jumps out from narrow gaps where it might even be an advantageous shape. The most important thing to me is that the level design and challenges of the game are based around the jump, so I don't really understand the desire to change at this late point in time. (I do enjoy the discussion of various types of jumps, though.)


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 8:39 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5895
Location: Canada
I have a different question about something that happens in both Lala and Cheril, though. How does the game choose a respawn point when you get hit? It feels like it returns you to a "safe" place from a few seconds prior. How did you implement this?

It seems to choose the point pretty well. I never had a moment where I thought it put me in a bad place (though the temporary invincibility really helps with that), but I also was never sure exactly where I'd end up restarting from. How does the game decide where to put you?


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 8:48 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19341
Location: NE Indiana, USA (NTSC)
Rahsennor wrote:
I'm going to shut up now or I'll end up writing an entire essay on platformer physics. :roll:

If you have time, I'd be interested to see your essay on wiki.nesdev.com.

FrankenGraphics wrote:
If* you would want the breaking off to be less sharp, you could perhaps gradually 'roll down' to the clamping value over the course of a couple few frames, maybe four or six?

In other words, apply increased gravity until the upward velocity is below the clamping value. With a clamping value of zero (the peak of the jump), this produces the jump behavior in the Haunted games.


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 9:09 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1124
Location: Gothenburg, Sweden
rainwarrior wrote:
The most important thing to me is that the level design and challenges of the game are based around the jump, so I don't really understand the desire to change at this late point in time.


changing a core mechanic in the game at this point raises the need of further playtesting and hypothetically, perhaps also marginal corrections of the level layout, which could potentially be time-resource costly. But if one is willing to do that, and if there's a good enough purpose, i see no hindrances. The max reach of the jump seems to be the same, which should make the window for new-upcoming layout trouble small enough to handle. In any case, i think it's a productive discussion.

I think you're absolutely right that the sharpness breaking off the trajectory has strong merits. It gives both a more direct sense and a distinct edge to the control; hence the if in italics. As for my slow-progressing-while-learning-to-code roller derby project, cross-fading in order to transition directional velocity in some maneuvers is something i view as important (because of how roller skating works), but that's another context.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 11:21 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1124
Location: Gothenburg, Sweden
tepples wrote:
In other words, apply increased gravity until the upward velocity is below the clamping value. With a clamping value of zero (the peak of the jump), this produces the jump behavior in the Haunted games.


This made me realize my wording was inexact and open for multiple interpretations. I didn't specify what to 'roll down' in that sentence.
"you could perhaps gradually 'roll down' to the clamping value" should have been "let the clamping value decrease from a starting value (at [jump button] release) to a lower value over the course # frames"; If that makes sense.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 11:46 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19341
Location: NE Indiana, USA (NTSC)
That model is equivalent to "When A is released for the first time in each jump, multiply upward velocity by 1/4."

Say the normal jump velocity is 1000 decreasing to 0 at the peak, and the clamp value is 250 decreasing to 0 at the peak. Then A is released when upward velocity is 600. By that time, the clamp value will be 150.

Don't mind me; I'm just trying to golf down the size of each algorithm's required state. Here, I've reduced it to one bit: "has clamp already been applied since this jump began?".


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 12:44 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1124
Location: Gothenburg, Sweden
Hmm.. what i'm trying to achieve by this is analogous to the terms 'hard knee' and 'soft knee' in signal compression.

Would that be the effect of "When A is released for the first time in each jump, multiply upward velocity by 1/4."?

Quote:
Don't mind me; I'm just trying to golf down the size of each algorithm's required state.

I think it would be beneficial to boil down a list of barebone jumping/physics topologies that are especially useful on the NES and similar 6502 platforms.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 12:51 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1311
na_th_an wrote:
Interesting.

The jumping mechanism is as follows:

- Every frame, vy is added to y.
- G is added to vy.
- When A is pressed, jumping starts. vy gets a negative boost. Such boost is applied to vy in a decreasing manner as long as time passes during a maximum of 16 frames.


This is why it has a strange jump curve, then. When an actor jumps, dy (or vy in your case) is generally set to an upwards (negative) value as a one-shot, and then a gravity constant is added every tick to slow this upwards acceleration until it eventually becomes downwards acceleration. To continuously boost vy upwards would drag the actor upwards, increasingly quickly. That makes sense for something bobbing to the surface under water, or if the actor has a jetpack or other propulsion apparatus, but for a jump it seems inappropriate.

Some Virgin games for Genesis (Cool Spot, Aladdin, Earthworm Jim) jump with this same strange curve, while others (Lion King) do it in a more sensible way.

EDIT: Argh, I'm a page late. Having an unusual jump isn't necessarily a bad thing, but getting the more typical parabolic curve might make it feel more natural to those used to other platformers. As others have written, it is a matter of whether or not it is worth changing the mechanic, then testing and adjusting the rest of the game to match.


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 2:15 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 363
rainwarrior wrote:
I have a different question about something that happens in both Lala and Cheril, though. How does the game choose a respawn point when you get hit? It feels like it returns you to a "safe" place from a few seconds prior. How did you implement this?

It seems to choose the point pretty well. I never had a moment where I thought it put me in a bad place (though the temporary invincibility really helps with that), but I also was never sure exactly where I'd end up restarting from. How does the game decide where to put you?


It's very simple: it places you where you jumped the last time. It records your position everytime you jump (but not if you jump from a moving platform).

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 2:21 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1124
Location: Gothenburg, Sweden
Correction: That's ingeniously simple. :shock: Now knowing this, i should say the omission of moving platforms are noticeable (they are percieved as longer, irregular gaps in the timeline). If you wanted to expand on that, you could check for a moving platform collision detection to be true at each jump press, in which case the init position of that platform + centering offset would be stored instead of the actual position. Some additional playtesting involved, but that's much quicker than checking every corner for side effects of altered jumping mechanisms.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 6:21 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 297
tepples wrote:
If you have time, I'd be interested to see your essay on wiki.nesdev.com.

Me and my big mouth. :|

What should I cover? I haven't done any surveys or implementations on the NES, just general algorithms for my PC game engines. I doubt NES developers are going to be interested in the mathematical properties of Euler vs. Verlet integration, for instance, and I'm not quite sure which of the collision detection algorithms I know are appropriate for a 6502.


Top
 Profile  
 
PostPosted: Tue Feb 07, 2017 8:18 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5895
Location: Canada
na_th_an wrote:
rainwarrior wrote:
I have a different question about something that happens in both Lala and Cheril, though. How does the game choose a respawn point when you get hit? It feels like it returns you to a "safe" place from a few seconds prior. How did you implement this?

It seems to choose the point pretty well. I never had a moment where I thought it put me in a bad place (though the temporary invincibility really helps with that), but I also was never sure exactly where I'd end up restarting from. How does the game decide where to put you?


It's very simple: it places you where you jumped the last time. It records your position everytime you jump (but not if you jump from a moving platform).

Ah, neat! Thanks for explaining how that works. I was trying to imagine that you tagged "safe" platforms throughout your levels and were keeping a ring buffer of the last places visited or something, but I couldn't think of a non-complicated way. Interesting how simple the actual approach was. :)


Top
 Profile  
 
PostPosted: Wed Feb 08, 2017 2:47 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 363
Well, it's *very* simple and it seems to work in the games I've implemented it, as it is a spot where you won't fall to certain death on respawn, and the timed invincibility grants no baddies will harm you, but it has its limitations:

- As mentioned, you can't respawn on a moving platform. If you are planning for a segment in which you have to advance jumping through a series moving platforms, the respawn will place you far behind and this may seem unfair.
- If conveyors are implemented, maybe the respawning spot is not that safe. Imagine you jump from the edge of a conveyor in the last minute.
- You (as the game designer) don't really have control. It may result on unwanted / exploitable glitches, or unfair situations. Imagine you descend like 8 screens without having to jump, then get killed. Back to top! [*]

@FrankenGraphics, I like your idea. I can detect if the jump is from a platform (in fact, I am using such detection to *not* register a "safe spot"). I could easily save the platform status. I could even take a snapshot of the values of every moving object on screen, and restore it alongside the player position. In fact, I think I'm going to try this on Goddess to see how it works.

I always need to KISS (yet effective) as I'm coding in C and have to cope with the overhead.

[*] This issue could be solved registering a safe spot everytime the player hits the ground. I could have implemented this but that would result in having to register the safe spot (much) more often, and every cycle counts. Maybe it's a fault in my engine, but usually you are registering a collision with the floor every frame as you walk.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Wed Feb 08, 2017 3:47 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1124
Location: Gothenburg, Sweden
na_th_an wrote:
[...] and every cycle counts. Maybe it's a fault in my engine, but usually you are registering a collision with the floor every frame as you walk.


Background hit checks could be resolved far less often (unlike against moving platforms and enemies), because(/if) solid blocks are always aligned to the grid.

Any attempt to move 1px in the wanted direction is called every frame, but:
and #$07 (value as an example) + bne then checks if the incoming value isn't a multiple of 8, in which case the branch goes around the actual detection code to let the movement attempt be. If background solids/semi-solid surfaces always are on a 16x16 grid, you can filter for a multiple of 16 (and #$0E). Either option should save you a handful of cycles.

A game can have different filters/masks for the Y and X axis if the level layout calls for it (not related to this particular game, i think, but one might want to have a different collision grid granularity on the Y axis than the X axis, for example).

_________________
http://www.frankengraphics.com - personal NES blog


Last edited by FrankenGraphics on Wed Feb 08, 2017 4:58 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Wed Feb 08, 2017 4:23 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 363
Problem is, gravity is always pulling you down, affecting your vy. Vy gets added to y, player moves into the floor, collision is detected, vy is set back to 0 and player put on floor. Continuously.

_________________
http://www.mojontwins.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group