* Moderator hat on*
This is a gentle reminder that we are in the For Beginners forum, discussing a project being implemented by a beginner asking for help with is code.
Discussion on the poorly-defined meanings of object oriented-ness are not appropriate. Discussions in For Beginners should be focused on the actual problem the beginner is having.
* Moderator hat off*
Now, on to the updated code.
7 hours ago, reders said:
Here's the upgraded .cpp ... What should I consider doing to improve the code?
I think that code is much more readable, even though it takes up more lines. Hopefully you agree, as it is your code and you're the one who gets to live with it.
If I use the code-collapse feature of my IDE, the code is broken up into easily understood blocks: main(), Initialize(), Move_ball(), AI_Movement(), Player2_Movement(), and Reset_all(). I can look at that and understand your game.
Expanding any one of those gives me logic that I can easily understand. For example Player2_Movement() opens to keypressed up and keypressed down. Each of those actions is easily understood when I expand them.
Those are good, especially in beginner code.
If I were looking to improve it -- even though what you've got in there looks like a runnable game -- I would next try to simplify by merging duplicate functionality.
Moving up and moving down seem like the same operation, the only difference is that one is positive and the other negative, you can use a clamp function to limit movement both at the top and the bottom. That's 7 lines removed. The AI has different logic controlling if they move the paddle up or down, but the actual logic of moving of a paddle is the same as you're only modifying the y value. Extract the duplicate paddle-moving logic to a new function that accepts both a reference to a paddle and the direction it moves, and you remove another 10 or so lines of duplication.
Moving the ball also has a lot of duplicate math that depends on ballsp_x is positive or negative. That duplicate math can probably also be merged.
I'd also look at more consistent naming conventions. Sometimes they start with uppercase or lowercase, sometimes they have underscores, sometimes they have abbreviations. There are automated ways to rename all variable instances in most IDEs, so it is usually an easy thing to clean up.
Games are shipped but never really done. There are always improvements developers want to see and bugs that could be fixed. Players don't normally dig through the source code, and if they did often they'd encounter nightmare fuel. If your code does the things you want to do and fits whatever performance criteria you've been given, you can call it good enough, even when it could be better.