-
-
Notifications
You must be signed in to change notification settings - Fork 521
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
base: master
Are you sure you want to change the base?
Conversation
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
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.
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:
By this, do you mean faster acceleration/deceleration? |
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. |
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.mp4Also, make sure to have the "Current" particles fade out rather than suddenly disappearing in an instant. |
I would not be suprised if something similar applies to the normal wind as well |
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. |
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. |
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? |
Found a couple bugs:
inconsistent_wind_push.mp4
swim_bug.mp4
wind_current_jitter.mp4It 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. |
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 |
This is the level I tested and discovered that bug: |
More bugs I found:
|
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. |
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 |
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
I will keep attacking these issues and hopefully we can get this to work soon! |
Any further progress on this? Just checking :) |
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. |
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. |
animation_jitter.mp4
wind_stronger_pushback.mp4
changing_wind_push.mp4wind_badguy_bug.mp4 |
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. |
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.
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. :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
- 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.
Swim and swim boost speed is still way too high. Very uncontrollable in narrow water areas. |
575f18f
to
9ca056d
Compare
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. |
09990af
to
a986c18
Compare
There was a problem hiding this 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 :)
Can we merge this into local branch, separate out the wind and then merge into master? @Alasdairbugs |
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. |
Sorry guys, I've been a bit busy lately but I can isolate the wind updates soon so you can merge them. |
eda15b5
to
06c5611
Compare
c91a4af
to
8e01ebd
Compare
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
8e01ebd
to
b8e19ab
Compare
* 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]>
b8e19ab
to
aefe237
Compare
Wind changes are now isolated, I'm going to turn this into a normal pull request. |
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); |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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! |
There was a problem hiding this comment.
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.
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. |
This PR includes an overhaul of wind physics:
Included changes:
Physic
class for convenience.