[Merged by Bors] - Move magic numbers into constants in Breakout example#4255
[Merged by Bors] - Move magic numbers into constants in Breakout example#4255alice-i-cecile wants to merge 7 commits intobevyengine:mainfrom
Conversation
hymm
left a comment
There was a problem hiding this comment.
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>
ghost
left a comment
There was a problem hiding this comment.
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.
the meaning of this one is not very obvious, even less with the PADDLE_SIZE just under
There was a problem hiding this comment.
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.