-
-
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
[Merged by Bors] - Move magic numbers into constants in Breakout example #4255
Conversation
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.
Overall I think moving the relevant constants to the top of the file makes sense as it does let beginners play with things more easily.
Co-authored-by: Mike <mike.hsu@gmail.com>
Co-authored-by: Mike <mike.hsu@gmail.com>
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.
LGTM. As a beginner I would've greatly appreciated the constants so this change makes sense to me.
I think the amount of documentation on the constants is fine as is for now, because otherwise the example would be drowned in comments that don't add a lot to the example itself.
If we see users asking questions about particular constants we should add documentation to those, but they are mostly self explanatory.
Co-authored-by: KDecay <KDecayMusic@protonmail.com>
bors r+ |
# 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.
// These constants are defined in `Transform` units. | ||
// Using the default 2D camera they correspond 1:1 with screen pixels. | ||
// The `const_vec3!` macros are needed as functions that operate on floats cannot be constant in Rust. | ||
const PADDLE_HEIGHT: f32 = -215.0; |
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 meaning of this one is not very obvious, even less with the PADDLE_SIZE
just under
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.
Agreed. I'll fix this in a follow-up PR.
# 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.
Objective
Solution
Context
Part of the changes made in #2094; split out for easier review.