So i'm looking to code pong (score will go up to 10) as my first actual game and have written out part of the pseudo code (minus the actual physics) to show the very basics of the game mechanics and just want to make sure on this super high level I'm not missing anything. I've included my pseudo code and I'm likely going to code this in C++ or C#, but if anyone thinks another language is better I am open to suggestions.

I was also curious as to whether using a pointer, class, or function would suit my needs better for storing the code for the physics part of this. I'm thinking with as simple as it should be a function may be best, but again, I am open to suggestions.

**EDIT** Realized I don't need a generic score variable and removed all references to it.

pong

paddle a - left side
paddle b - left side
int score a = 0
int score b = 0

while (score <= 10)
	if (click){
		send ball from one side to the other
	}
	else {
		keep ball at paddle
	}

	if (ball goes past paddle b){
		point to paddle a
		score a = score a + 1
	}
	else{
		send ball back to other side
	}

	if (ball goes past paddle a){
		point to paddle b
		score b = score b + 1
	}
	else{
		send ball back to other side
	}
	
	display score a on left side
	display score b on right side
	
	if  (paddle a's points = 10){
		end game
		player 1 wins!
	}
	else if (paddle b's points = 10){
		end game
		player 2 wins!
	}
	else {
		continue game
	}
}

Ask if player wishes to play again

Pong, being 2D and moving fairly slowly, doesn't need much in terms of physics. Merely reversing the movement vector when it hits a wall is generally enough. I coded the basic version and then the 3D version with much more complicated physics that could handle much greater speeds.

Generally, reversing the X and Y when it hits a barrier is "good enough". For mine, I actually calculated the trajectory and did a reflection off the wall using vectors. But that may be overkill for most pong games.

In a game of Pong, I would expect that rallies can take place, where the ball moves back and forth between both paddles, until one of the players makes a mistake.

In more detail, one leg of a rally would be that the ball moves from one side to the other side, and eventually, the receiving side either catches or misses the ball. (If the player catches, the ball bounces, and a new leg is started in the opposite direction.)

The "while" at line 8 seems to be run once every rally, where lines 9-14 seem to launch the ball. Should both sides be able to launch the ball?

Lines 16-30 seem to handle catching or missing the ball at the end of a leg. I idon't see any code that moves the ball and the player paddles during a leg, nor do I understand how your pseudo code is handling a rally (for example, 2 legs of the ball moving back and forth, before a player makes a mistake). Maybe you need another while loop to do that?

Lines 35-45 seem to handle announcing the final winner (no idea what "continue game" means, you may want to expand that further or clarify what it means). It's a bit weird that you do that while the rallies are still being played. Maybe you want to do that after the "while", when you know the game has been decided.

While your code is great for understanding the high-level picture top->down, in terms of game programming it is not of much use.

The game-loop starts at the low end instead of your high-level end, and is run every frame (every time the ball moves a few pixels on the screen). It goes much like

# Game loop
while not done do:
    read-inputs() # Read what the player wants
    update-positions() # Make everything moves a few pixels (if you have moving things on the screen)
    draw-screen() # Display new situation on the screen
end

You need to merge both ideas into one code, then you're done! :)

Pong, being 2D and moving fairly slowly, doesn't need much in terms of physics. Merely reversing the movement vector when it hits a wall is generally enough. I coded the basic version and then the 3D version with much more complicated physics that could handle much greater speeds.

Generally, reversing the X and Y when it hits a barrier is "good enough". For mine, I actually calculated the trajectory and did a reflection off the wall using vectors. But that may be overkill for most pong games.

I figured as much. And I'm thinking reversing X and Y is something as simple as multiplying the trajectory or angle by -1.

In a game of Pong, I would expect that rallies can take place, where the ball moves back and forth between both paddles, until one of the players makes a mistake.

In more detail, one leg of a rally would be that the ball moves from one side to the other side, and eventually, the receiving side either catches or misses the ball. (If the player catches, the ball bounces, and a new leg is started in the opposite direction.)

The "while" at line 8 seems to be run once every rally, where lines 9-14 seem to launch the ball. Should both sides be able to launch the ball?

Lines 16-30 seem to handle catching or missing the ball at the end of a leg. I idon't see any code that moves the ball and the player paddles during a leg, nor do I understand how your pseudo code is handling a rally (for example, 2 legs of the ball moving back and forth, before a player makes a mistake). Maybe you need another while loop to do that?

Lines 35-45 seem to handle announcing the final winner (no idea what "continue game" means, you may want to expand that further or clarify what it means). It's a bit weird that you do that while the rallies are still being played. Maybe you want to do that after the "while", when you know the game has been decided.

While your code is great for understanding the high-level picture top->down, in terms of game programming it is not of much use.

The game-loop starts at the low end instead of your high-level end, and is run every frame (every time the ball moves a few pixels on the screen). It goes much like

# Game loop
while not done do:
    read-inputs() # Read what the player wants
    update-positions() # Make everything moves a few pixels (if you have moving things on the screen)
    draw-screen() # Display new situation on the screen
end

You need to merge both ideas into one code, then you're done! :)

I was thinking the while loop I already have would take care of multiple rallies, but taking into account what you have present at least one more loop would likely be a good idea on my part. Looking at it now I also see what you mean about moving the if statements that determine who the winner is. At the time I wrote this I was going along the lines that at the end of each loop it would look to see if either player had 10 points and if neither did then it would continue on with the next round of the loop...and talking this out now I think I need to change the condition in my while loop to be something along the lines of confirming if the winning criteria (a player getting 10 points) has been met instead of what it is currently set to (which is incorrect anyways since I decided to remove the generic score variable).

Thank you for input and for the pseudo loop code. Everything has been very informative and being able to talk this out should get me more on the right track. :)