Pong

[odd finch]

I created a pong clone. It's my first bevy project. I would like feedback so I can learn more about bevy and best practices but I wouldn't blame anybody if they didn't want to struggle through spaghetti code. https://github.com/Vilhelm-Ian/bevy-pong

[tender glade]

x_change and y_change could be a Vec2?

movement, input and collision are one system when they could easily be separate

(like you've done with ball)

those are just things i noticed with a quick look over it

[odd finch]

I thought it would be better having this in multiple system be more readble

but now that I think about it, having multiple systems just means multiple queries which drains perfromance

[tender glade]

thats not at all what i was saying

the opposite

[odd finch]

sorry I am sleepy I misread your message

[tender glade]

heh, happens

but yeah i'd split them

my one system interacting with transdform is often just 3 lines

adding a velocity to the transform (maybe multiplied by elapsed time)

then in other places i just modify the velocity

[odd finch]

question how can I limit how much something can move, if I am checking for collision in a different system

[tender glade]

now, for pong thats not really neccessary, but in many other types of games it works well

[tender glade]

setting the velocity to zero before its applied

[odd finch]

then I will have to detect when the collision ends

[tender glade]

you can make sure in which order systems run by using explicit system ordering

[tender glade]

not really, you just set it to whatever the player is pressing, then check collision and set to zero, then apply

its a bit overcomplicated for pong i admit

its not bad currently, for being a very simple game

[odd finch]

laund do you know any open source bevy games i should look into

to learn more

[tender glade]

hmm, https://github.com/fishfolk/punchy maybe

they have a few https://github.com/fishfolk/bomby

i havent looked much into the code quality, tho what i've seen seems good

[rocky frost]

Some typos:

collider_tarnsform -> collider_transform
linnear_equation -> linear_equation

There are a bunch of hardcoded magic numbers everywhere. The code would be more readable with some of this sort of thing:

const PADDLE_SPEED: f32 = 10.;
const PADDLE_MIN_Y: f32 = -250.;
const WALL_COLOR: Color = Color::rgb(0.25, 0.25, 0.75);

Your movement is always 10 units per frame. This means the game is much more difficult on higher framerates, and easier on lower framerates. You should multiply this by the frame time delta.

time: Res<Time>
// ...
enemy_transform.translation.y += PADDLE_SPEED * time.delta_seconds();

You should run cargo clippy. It has a few small suggestions for you.

The enemy can overlap the walls of the arena when seeking the ball. Why not use the collision checking when moving them like you do with the player's input?

create_linear_equation is an unidiomatic way to do a constructor. I would suggest

impl LinearEquation {
    fn new(a: Vec2, b: Vec2) -> Self { /* ... */ }
}

Also, predict_ball isn't very ball specific, and could probably be something like

impl LinearEquation {
    fn project_y(&self, x: f32) -> f32 { /* ... */ }
}