Skip to content

Wind and swimming updates #2793

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

biggeryetbetter
Copy link
Contributor

@biggeryetbetter biggeryetbetter commented Feb 20, 2024

This PR includes an overhaul of wind physics:
Included changes:

  • Player doesn't jitter in certain scenarios with wind
  • No skidding noise in wind.
  • Player is not slowed down when they work with wind.
  • Most flying enemies can now interact with wind
  • A "Current" variant of wind that does not affect Dive Mines.
  • Wind acceleration and speed is now part of the Physic class for convenience.

Previously players were slowed down when moving in the same direction as
wind when its velocity was particularly low.
`add_wind_velocity` was ported from `Badguy` to the `Player` class to
fix this.
* Darts, kamikaze snowballs and owls stop moving vertically after exiting wind
* Zeeklings abort a dive if they are stopped by strong enough wind.

For Flying Snowballs:
* Velocity is now calculated based on the previous target height to
avoid snapping when pushed away from their start position
* They can be pushed upwards or downwards
* When pushed sideways, damping keeps them from floating away forever
@mrkubax10 mrkubax10 added involves:functionality status:in-progress Progress has been done, but more is intended be done category:code type:bugfix Pull Requests that fix bugs. labels Feb 22, 2024
@Rusty-Box
Copy link
Member

A issue that does still persist is that when the wind is set to values (I believe) below Tux max. walk/run speed, Tux will not be moved by the wind when standing still, stuck in his run animation.

Also, I feel that wind should always affect things when they are in their zone. Right now if you don't jump it will not affect you at all, even though you are clearly inside the wind zone.

wind.mp4

- "Current" variant of wind that blows bubbles and does not affect Dive
Mines.
- Players now have an `m_wind_velocity` variable that is applied only
after calculating other player physics. This fixes several unwanted
behaviors related to Tux and wind.
@biggeryetbetter
Copy link
Contributor Author

I have made several changes to the wind physics process that seem to have fixed these behaviors. I've also added a prototype "current" that does not affect dive mines. I would like some clarification about what you mean in #2592:

You have better control within the current for better navigation and correcting

By this, do you mean faster acceleration/deceleration?

@Rusty-Box
Copy link
Member

So the thought behind the current was that (since it is underwater) it can be used to suck/push Tux into an area. However, Tux should be able to swim against the current if it is not too strong. Now that should probably apply to both the current and wind. Main difference is that the current type would have different particles (i.e. bubbles) to better fit the aquatic theme.

@Rusty-Box
Copy link
Member

Somethig I noticed with the "Current". It is very hard to fight it. Especially with an acceleration of 100. You would expect setting the speed of wind lower than Tux's swim/boost speed, he'd still be able to slowly go against the current. However, I seemingly get force-halted by the current even thought techincally Tux should still be able to swim through (obviously slower). It lets me swim for a short moment before halting all my progress, even when oosting which is moves very fast! Even with an acceleration of 10.

current_wip_issue.mp4

Also, make sure to have the "Current" particles fade out rather than suddenly disappearing in an instant.

@Rusty-Box
Copy link
Member

I would not be suprised if something similar applies to the normal wind as well

@biggeryetbetter
Copy link
Contributor Author

I'm admittedly a bit stuck on this issue. While the normal wind seems to be working correctly, it seems that in water, the acceleration from current is still vastly overpowering that from swimming. Unfortunately I'm not really sure how to fix that without also altering how swimming works- any ideas would be appreciated.

@Rusty-Box
Copy link
Member

Unfortunately I'm not really sure how to fix that without also altering how swimming works- any ideas would be appreciated.

Altering swimming in what way? Swimming is still a fairly "unpolished" mechanic so alterations are still legitimate as long as they improve it. So depending on how would have to alter it, you might be able to go through with it.

@biggeryetbetter
Copy link
Contributor Author

Alright, I've tried tweaking swimming to actually work with wind. Let me know what you think. Boosting in particular seems to sometimes create large radii on turns which might need to be fixed.

Also, how can I make the water bubbles fade out?

@Rusty-Box
Copy link
Member

Found a couple bugs:

  • Walking through wind and standing, Tux gets pushed much weaker as when he jumps afterwards
inconsistent_wind_push.mp4
  • When underwater Tux will attempt to always move left when letting go of the directional keys.
swim_bug.mp4
  • At higher acceleration, around 100 (default value) but also noticeable aroud 50, Tux begins kinda jittering in a current and also somewhat stop an go when at higher speed wind
wind_current_jitter.mp4

It also seems that the wind affect Tux statically, i.e. instead of his speed accelerating or decelerating "smoothly" it changes instantly. Atleast that's how it felt to me. It should ease into the new faster/slower speed to make the transition more smooth. This seems to apply to both wind and current, if that is truly what is happening, maybe I'm mistaken here.

@biggeryetbetter
Copy link
Contributor Author

I can confirm the first and third bugs but I'm not able to recreate the second one. Can you upload the setup that is shown in the video?

Another bug: Pressing the down arrow rapidly while moving into fast wind somehow allows you to go through easier. This is caused by some stuff around line 1586 of player.cpp and I don't know what they are supposed to do so I won't touch them.

@Rusty-Box
Copy link
Member

Can you upload the setup that is shown in the video?

This is the level I tested and discovered that bug:

wind_test_level.zip

@Rusty-Box
Copy link
Member

More bugs I found:

  • Buttjumping in downwards moving wind breaks the animation, i.e. Tux gets stuck in his buttjump an/or stomp animation after touching the ground.
  • Tux cannot duck when in wind that goes downwards

@Rusty-Box
Copy link
Member

I also noticed that when you swim in the Current and you move in the direction it goes, you kinda seem to break the speed at which it is pushing you, like you get a bit slower than when you just get pushed without moving yourself. This might also apply to normal wind. Not sure on that. I usually notice it best while swimming.

@Rusty-Box
Copy link
Member

Okay I keep finding many more bugs - sry 'bout that :D

So apparently, Dive Mine is still affected by currents but also when they leave the current/wind area they keep on going, never stopping. Also getting pushed underwater is still somewhat jittery. Feathering help a little bit but overall needs a much higher value than normal wind to be smoothed out fully, for the most part.

Speaking of feathering, so idk if I fully get what it does specifically but the best values I've seen with it seems to be around 350? Can shed some more light on what it does exactly because with default value of 16 it looks horribly jittery

@biggeryetbetter
Copy link
Contributor Author

Don't worry; that's what open-source is all about. I haven't done a particularly good job testing each change, to be honest.

Also, the way feathering works is that it calculates how far the center of your hitbox is from the edge of the wind area (in pixels), then divides it by the feathering distance and clamps it between 0 and 1. It wasn't introduced to fix the jittering (that is caused by friction) but rather the fact that tux would keep "bouncing" off the edge of strong wind instead of pushing up against it like you might expect.

My main problem with how it works right now is that if you put wind in a tunnel, like in the test level you showed previously, the top and bottom edges of the wind will have feathering, even though this makes no sense inside a tunnel.

Also, I found out that I was calculating m_wind_velocity (should actually be m_wind_acceleration) completely wrong which seems to have been what was going on when you said

It is very hard to fight it. Especially with an acceleration of 100. You would expect setting the speed of wind lower than Tux's swim/boost speed, he'd still be able to slowly go against the current.

I will keep attacking these issues and hopefully we can get this to work soon!

@Rusty-Box
Copy link
Member

Any further progress on this? Just checking :)

@biggeryetbetter
Copy link
Contributor Author

Not really as I have again been busy with other things. It seems like the cause of the weird jittering bug is that wind only collides with tux every few game ticks and adds velocity, in between which, friction causes tux to suddenly slow down. That is what I have been stuck on currently.

@biggeryetbetter
Copy link
Contributor Author

Alright I think I got the jittering issue fixed finally... Sorry that took awhile. Let me know what you think and of any bugs you find.

@Rusty-Box
Copy link
Member

  • Jittering appears to be fixed indeed. The only thing that happens is that Tux's walk animation start,stops,start,stops the whole time if you don't hold the direction key you're going.
animation_jitter.mp4
  • Knowing that Tux walk and run speed can go up to iirc. 230 and 320 repsectivly, I'm suprised that if you walk against wind with a 100 value Tux barely manages to walk against it. As if the wind was suddenly way stronger. Also when Tux jumps still gets pushed stronger than when he is on the ground, which is odd.
wind_stronger_pushback.mp4
  • Reaching the top of a wind area occassionally push Tux much higher + objects that walk or stand in up facing wind don't get pushed up. They're not even affectd by wind at all even the they should
changing_wind_push.mp4
wind_badguy_bug.mp4

@Rusty-Box Rusty-Box added this to the 0.7.0 milestone Apr 25, 2024
@biggeryetbetter
Copy link
Contributor Author

I've been procrastinating on this a lot but I have finally gotten around to letting the vast majority of badguys interact with wind. I have not done this for ice crushers and ghouls because I'm not sure if that is desired.
Unfortunately, due to changes in how strong acceleration is, levels like "A Leaf In the Wind" will be broken with wind in its current state; the "acceleration" option will need to be cranked up quite a bit. Wind is however much more consistent with other sources of acceleration such as gravity, which is 1000 px/s^2 by default and can be mostly negated by using a wind object pointed upwards with an acceleration of 1000. For this reason I would personally recommend that levels simply be updated. Let me know what you think about this and the icecrushers/ghouls.

@Rusty-Box
Copy link
Member

I have not done this for ice crushers and ghouls because I'm not sure if that is desired.

Sounds fine. Ghoul is a ghost so makes sense they are not affected really and Crushers don't really need it. At best have them fall slower wind etc but its not too essential.

Unfortunately, due to changes in how strong acceleration is, levels like "A Leaf In the Wind" will be broken with wind in its current state; the "acceleration" option will need to be cranked up quite a bit.

Totally fine. Levelshave been fully remade from scratch for the next update thus will take this changes into account.

I will do further and more proper testing as soon as possible! Thank you for all this effort btw. :)

Copy link
Member

@weluvgoatz weluvgoatz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. While I do like the swimming changes, please clarify them more verbosely next time (such as in the title or description of PR) because this changes Tux's swimming in a pretty big way.
  2. The wind/current seems to not really work. Okay, well, to be exact, it barely works. I literally have to set the acceleration to 100,000 in order for it to replicate what a previous value of 100 would do. I understand why it was made this way but it breaks a bunch of current levels, so it would be appreciated if something could be done to more closely align with the current design so that fewer levels break.

@biggeryetbetter biggeryetbetter changed the title Wind fixes and swimming updates Wind and swimming updates Nov 15, 2024
@Rusty-Box
Copy link
Member

Swim and swim boost speed is still way too high. Very uncontrollable in narrow water areas.
The rest seems good I think.

@Rusty-Box
Copy link
Member

Rusty-Box commented Dec 7, 2024

Definitely getting closer. While normal swimming is better now and boosting technically feels much better to control, an issue that arises is the jump height you gain from jumping out of the water. It is very low. Previously you used to be able to jump about 4-ish tiles. Now it's barely 2. Adding a little bit more speed for boosting, it may run the risk of making boosting uncontrollable again. You could try increasing the boost speed to 500? Not sure how much that will fix it.

Copy link
Contributor

@Alasdairbugs Alasdairbugs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • The Wind is definitely an improvement

  • The currents feature is very welcomed

  • There is still more to be desired when it comes to diving:

There is too high an emphasis placed on vertical height when holding up+right after diving into a water source, when coming out of it, it doesn't look or feel like a 45-degree angle, and the speed you have UP is higher than the speed you have RIGHT. It looks more like a 30-degree angle from falling. A consequence of this is that now you dont cover much horizontal ground from these kinds of dives.

Secondly, The speed conversion from falling doesnt seem to convert as fully into speed while in the water, this has been completely numbed, it seems like you "speed-cap" in the water too harshly. this looks especially odd when you leave it because it looks like you just gain a ton of speed from tux's flippers.

Thirdly the speed ratio from falling to the ratio when coming out of the water seems to be more than halved than what tux' momentum when diving.

The last two points seemed to be sourced from the fact that just diving out of water looks to give the exact same momentum as diving in to water from a height. it looks like they grant the same momentum, but only if you're falling ~30+ tiles or more does marginal speed gains start to occur, but then tux' terminal velocity hits and there isnt really much to be gained.

Fourthly, Tux doesnt gain speed as he reaches a liquid edge, I think in terms of Biology and physics this would make more sense because A: you'd assume the penguin knows they're surfacing, so would put some extra kick into trying to get out, and B: its easier to push around water on a surface than a meter down, the pressure is less there.

Fifth: Currently if diving in and holding UP+Direction, Tux falls into the water about 4-5 tiles deep, i'd rather this be 2-tiles deep at most. Not only would it make the Bubble tileset actually viable, but i think it also would look more natural especially if we're going to have a 45-degree (or close to) trajectory.

Sixth: previously when diving into water, if you had a small amount of horizontal momentum (by tapping right, or by being slightly pushed by wind) and then held UP only, you could get different angles of trajectories. I'd like to see this kind of feature maintained, it gives designers a lot of options for using diving mechanics.

Overall The wind changes are really good but the swimming changes are unfortunately really undesireable! It heavily reduces the amount of fun you get from gaining lots of horizontal speed from them, it reduces options for getting different trajectories based on what input you press during a dive entry. It improves swimming while deep in water in terms of controlling tux, but unfortunately is undesireable elsewhere. If this PR was split into two, where wind was in one and swimming in another, I would approve the Wind ones immediately. Please reach out if you want clarification on any points :)

@Zwatotem
Copy link
Member

Zwatotem commented Feb 9, 2025

Can we merge this into local branch, separate out the wind and then merge into master? @Alasdairbugs

@Alasdairbugs
Copy link
Contributor

Doing that would be best i think for now and let swimming changes be another PR. Swimming changes will require a lot more R&D and feedback from level designers and it wont make sense to halt changes to wind for that. If @Zwatotem or @biggeryetbetter could do that that would be nice :)

Personally i think any swimming changes are kind of lower priority? Swimming seems fine to me rn. the only issue is underwater currents not being a thing, thats the only issue i can really think of.

@biggeryetbetter
Copy link
Contributor Author

Sorry guys, I've been a bit busy lately but I can isolate the wind updates soon so you can merge them.

@biggeryetbetter biggeryetbetter force-pushed the wind_fixes branch 2 times, most recently from c91a4af to 8e01ebd Compare February 19, 2025 16:15
Wind now has a configurable variable that allows for feathering of the
strength of wind. This is intended to make the transition into wind
smoother.

Fixed a logic error where all enemies would only be affected by current,
not normal wind.
Previously, acceleration was calculated completely incorrectly which
resulted in excessively high accelerations within wind areas.

Dive mines also no longer are pushed by wind.
* `CollisionObject` now keeps track of colliding wind areas each frame
* Wind now interpolates its applied velocity 50:50 each frame to prevent
Tux from jittering
* Tux will not skid constantly in wind
* Tux has higher turning acceleration in wind to give him a bit more
control
biggeryetbetter and others added 5 commits February 19, 2025 11:20
* Wind acceleration is now integrated with `dt_sec`
* Wind acceleration to the player is now smoother and is more consistent
with established accelerations such as gravity.
* Friction modified slightly
* Tux can skid in wind again but will not make the noise because it was
annoying.
* Most badguys now should be pushed around by wind like expected.
* All badguys for which it makes sense can interact and be pushed by
wind
* Wind interaction logic put in seperate functions
* Fixed many member variable names in `src/object/rock.hpp` to conform
to the style guide
Wind was integrated into the `Physic` class, meaning it can be accessed in the same manner as object velocity and acceleration.

Signed-off-by: biggeryetbetter <[email protected]>
@biggeryetbetter
Copy link
Contributor Author

Wind changes are now isolated, I'm going to turn this into a normal pull request.

@biggeryetbetter biggeryetbetter marked this pull request as ready for review March 6, 2025 15:28
if (adjusted_end_speed.y < 0 && m_physic.get_velocity_y() + m_wind_velocity.y > end_speed.y)
end_velocity.y = std::max(vec_acceleration.y, adjusted_end_speed.y);

m_wind_velocity = glm::lerp(m_wind_velocity, end_velocity, 0.5f);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be calculated using your push_to_velocity function?

@@ -96,6 +96,10 @@ void
Dart::active_update(float dt_sec)
{
BadGuy::active_update(dt_sec);

m_physic.set_velocity_y(m_physic.get_velocity_y() * 0.9f);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should depend on dt_sec.

@@ -39,6 +40,14 @@ KamikazeSnowball::initialize()
set_action(m_dir);
}

void
KamikazeSnowball::active_update(float dt_sec) {
m_physic.set_velocity_y(m_physic.get_velocity_y() * 0.9f);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should depend on dt_sec.

if (to.y < 0 && from.y > to.y)
result.y = std::max(from.y + diff.y, to.y);

return result;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks pretty much like:

if (glm::dot(to - from, from) > 0) {
  return move_towards(from, to, d);
} else {
  return from;
}

@@ -1173,6 +1184,11 @@ Player::apply_friction()
friction *= (ICE_FRICTION_MULTIPLIER*(m_sliding ? 4.f : m_stone ? 5.f : 1.f));
else
friction *= (NORMAL_FRICTION_MULTIPLIER*(m_sliding ? 0.8f : m_stone ? 0.4f : 1.f));

// Air friction does not make sense when the air is moving with you!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Air drag depends on the object speed with respect to the air. If the velocity of the air is equal to the velocity of Tux, then indeed, there is no drag. However, when they have both different velocities, there is drag. That is actually the reason why wind blows object away.

However, it looks like the term friction stands for the friction between Tux and the ground. In such a case, the friction is one force and the air drag is another force.

@Hypernoot
Copy link
Member

I was testing it again and something is very wrong - you can't go against slow wind. If the wind speed is around 10 or even less, then walking against it results in no movement at all. Jumping against wind causes a little movement. This should be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:code involves:functionality status:in-progress Progress has been done, but more is intended be done type:bugfix Pull Requests that fix bugs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants