-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Improve code quality of Breakout game example #2094
Conversation
Working around bitshifter/glam-rs#173 :(
Reduces over-penetration risk
Great effort, unfortunately I am a bit stretched for time this week and won't be able to spend the time on it that it deserves. :-( |
Credit to @kiiya for the idea!
Alright, I think this is ready for final review now :) |
examples/game/breakout.rs
Outdated
} | ||
|
||
velocity.x = direction * paddle.speed; |
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.
Per #2349, should this be scaled by delta time?
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.
We are moving our other objects on "fixed updates" which means they update X times within the bounds of this frame's "real delta time" and leftover accumulated time from previous frames. Therefore if we move this on "real" delta time, we might "overstep" relative to the other things. I personally think this should also move using the fixed update delta / be a part of the fixed update system set. Its ok to move more than once with the same input (think of this as an input sampling resolution rounding issue), but we do have both the issue of "dropped inputs" (if we had zero fixed updates this frame) and "just_pressed" not getting reset (if we had >1 fixed_updates this frame), which might result in logic repeating that wasn't intended to repeat.
I think this might be something that we need to handle better in-engine.
Closing this out in favor of several scoped PRs. |
# Objective - The Breakout example has a lot of configurable constant values for setup, but these are buried in the source code. - Magic numbers scattered in the source code are hard to follow. - Providing constants up front makes tweaking examples very approachable. ## Solution - Move magic numbers into constants ## Context Part of the changes made in #2094; split out for easier review.
# Objective - The components in the Breakout game are defined in a strange fashion. - Components should decouple behavior wherever possible. - Systems should be as general as possible, to make extending behavior easier. - Marker components are idiomatic and useful, but marker components and query filters were not used. - The existing design makes it challenging for beginners to extend the example into a high-quality game. ## Solution - Refactor component definitions in the Breakout example to reflect principles above. ## Context A small portion of the changes made in #2094. Interacts with changes in #4255; merge conflicts will have to be resolved.
# Objective - The Breakout example has a lot of configurable constant values for setup, but these are buried in the source code. - Magic numbers scattered in the source code are hard to follow. - Providing constants up front makes tweaking examples very approachable. ## Solution - Move magic numbers into constants ## Context Part of the changes made in bevyengine#2094; split out for easier review.
…engine#4261) # Objective - The components in the Breakout game are defined in a strange fashion. - Components should decouple behavior wherever possible. - Systems should be as general as possible, to make extending behavior easier. - Marker components are idiomatic and useful, but marker components and query filters were not used. - The existing design makes it challenging for beginners to extend the example into a high-quality game. ## Solution - Refactor component definitions in the Breakout example to reflect principles above. ## Context A small portion of the changes made in bevyengine#2094. Interacts with changes in bevyengine#4255; merge conflicts will have to be resolved.
# Objective - The Breakout example has a lot of configurable constant values for setup, but these are buried in the source code. - Magic numbers scattered in the source code are hard to follow. - Providing constants up front makes tweaking examples very approachable. ## Solution - Move magic numbers into constants ## Context Part of the changes made in bevyengine#2094; split out for easier review.
…engine#4261) # Objective - The components in the Breakout game are defined in a strange fashion. - Components should decouple behavior wherever possible. - Systems should be as general as possible, to make extending behavior easier. - Marker components are idiomatic and useful, but marker components and query filters were not used. - The existing design makes it challenging for beginners to extend the example into a high-quality game. ## Solution - Refactor component definitions in the Breakout example to reflect principles above. ## Context A small portion of the changes made in bevyengine#2094. Interacts with changes in bevyengine#4255; merge conflicts will have to be resolved.
Functionality should be nearly an exact match to the old feature. @rhulha, take a look :) This PR was inspired by bevyengine/bevy-website#102, and should make this example much more suitable as a tutorial, whether that's part of the Bevy book or not.
Main improvements:
kinematics
system that operates on everything with a velocityadd_system(my_system.system())
system naming convention in favor of more descriptive names ;) (Cart feel free to revert this but it will still make me sad)