So, I realize the bullet points above me are a little trolly :), but to be clear - I asked on this forum so I could hear people who design games better tell me why my designs were wrong. At work, I become a better coder through code reviews; In the same manner, I would get better at building games if people told my why what I do is crap. I don't mind if the advice is too much for such a simple game implementation, in fact that's kind of what I want to hear, so in my next implementation I can start out making better choices.
- It looks weird that the ball has BoundClose and BounceNear parameters. I'd let the ball move anywhere and check outside the Ball's Update method if it's a point for any of the players.
- It also looks weird that in the Ball's Update method you send both Paddles, it's like you put all the collision detection inside the Ball class. I'd take that out into something that checks for collisions, and add methods in Paddle and Ball classes to react to collisions.
So I like this advice, when shoving the logic into a ball Update function I thought about how that's probably pretty crappy. So to sum up what a good change would be is to have a module check for collisions and react by calling a function to Ball or changing its velocity? While all ball update should really do is it update its own position with its velocity or something? This is good just saying it out loud makes it feel better.
- I can't find anything about timing, it looks like you update and draw everything as soon as you can. Implementing a way to limit the the frame rate is usually a must for games, so the game fells the same in any computer you play. You basically check how much time has passed since your last iteration of the gameloop, send that value into all the "Update" methods (and do everything considering that time) and wait some milliseconds before executing the next iteration. Later you can add fixed updates for physics too.
I have actually implemented this before. I haven't done it here yet, I have no idea why, but this is something I should be doing from square one not after implementing game logic. Thank you.
- Speaking about Update methods, if you send the same thing every time consider setting those things as attributes once instead. It's also uncommon that your WorldObject doesn't have an Update method and the derived classes have different Update methods. It's not bad, but in almost every engine and game I worked in the base game object has an Update(float deltaTime) method. This also makes it easier to update the game objects in games that the object count is dynamic. Now you have the paddles and the ball and update each one in a line, but imagine a Breakout game, where you also have a different number of blocks in each level.
This is way better than what I'm doing. It actually enforces better design decisions. With an Update in WorldObject with a single parameter of DeltaTime I can't do stupid stuff like sending paddle parameters or parameters for input detection. I will be implementing this bit very soon.
- In WorldObject you have some empty constructors, is that OK?
- The "Movable" class has a name that sounds like an Interface, but it has some code. Couldn't that code be part of WorldObject? Or some WorldObjects don't move? I only see that Paddle and Ball are.
No, that's not ok. Good catch! Yeah that was the idea was that some objects may not move, but I've shot my own self in the foot because WorldObject's have Moveable protected member in them. This was a stupid choice of mine and I actually want to rethink how this works in general.
Awesome points. All of them. Thank you for looking at it. Actually means a lot that you guys are willing to blow your own time looking at my stinky code, so I do appreciate it.
