Skip to content
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

Closed
wants to merge 47 commits into from

Conversation

alice-i-cecile
Copy link
Member

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:

  1. Better comments
  2. Better practices for magic numbers, which are mostly contained to a config module to allow for easier twiddling and better comprehensibility.
  3. Smaller, more comprehensible systems
  4. Idiomatic use of marker components to make the example easier to extend
  5. A single kinematics system that operates on everything with a velocity
  6. Always use the fixed time step const, rather than sometimes using delta_time
  7. Removed confusing early break in collision system
  8. Demonstrates nested bundles
  9. Much less confusing wall spawning logic by breaking it down into simple parts
  10. Removed redundant add_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)

@alice-i-cecile alice-i-cecile added C-Code-Quality A section of code that is hard to understand or change C-Examples An addition or correction to our examples labels May 4, 2021
@rhulha
Copy link

rhulha commented May 5, 2021

@rhulha, take a look :)

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. :-(

@alice-i-cecile
Copy link
Member Author

@Kiiyya thanks for the idea on comments for the system ordering! That improves the clarity of the code a lot, and should also be educational. See: 46294c1

@alice-i-cecile
Copy link
Member Author

Alright, I think this is ready for final review now :)

}

velocity.x = direction * paddle.speed;
Copy link
Member Author

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?

Copy link
Member

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.

@cart cart added the S-Pre-Relicense This PR was made before Bevy added the Apache license. Cannot be merged or used for other work label Jul 23, 2021
@mockersf mockersf removed the S-Pre-Relicense This PR was made before Bevy added the Apache license. Cannot be merged or used for other work label Jul 24, 2021
@alice-i-cecile
Copy link
Member Author

Closing this out in favor of several scoped PRs.

bors bot pushed a commit that referenced this pull request Mar 19, 2022
# 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.
bors bot pushed a commit that referenced this pull request Mar 23, 2022
# 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.
aevyrie pushed a commit to aevyrie/bevy that referenced this pull request Jun 7, 2022
# 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.
aevyrie pushed a commit to aevyrie/bevy that referenced this pull request Jun 7, 2022
…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.
ItsDoot pushed a commit to ItsDoot/bevy that referenced this pull request Feb 1, 2023
# 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.
ItsDoot pushed a commit to ItsDoot/bevy that referenced this pull request Feb 1, 2023
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Code-Quality A section of code that is hard to understand or change C-Examples An addition or correction to our examples
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants