Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualBCullis

Posted 07 December 2012 - 11:32 AM

Just to add on to what Alvaro is bringing up: you're not actually using Object Oriented programming. You've made a class, but it's just a container for strictly procedural code. Also, as your game doesn't loop, it'll be over immediately.

A helpful heuristic for object oriented design is the "paragraph model". If you were to sit down and write out how your game works (what the code does, or what happens while playing the game) you'd find that most of the time, your objects would be the nouns in the sentences, the verbs would be your object's methods, and adjectives define additional properties of your objects. As an example:

"When the ball collides with the paddle, it bounces back in the other direction"

Already I could make an argument for a ball class, a paddle class, and two methods for ball could be Ball::Collide() and Ball::Bounce(). Though my experience tells me that you could simplify the design and make Bounce() just an internal method call inside Collide() that defines how you react to a collision.

#1BCullis

Posted 07 December 2012 - 11:29 AM

A helpful heuristic for object design is the "paragraph model". If you were to sit down and write out how your game works (what the code does, or what happens while playing the game) you'd find that most of the time, your objects would be the nouns in the sentences, the verbs would be your object's methods, and adjectives define additional properties of your objects. As an example:

"When the ball collides with the paddle, it bounces back in the other direction"

Already I could make an argument for a ball class, a paddle class, and two methods for ball could be Ball::Collide() and Ball::Bounce(). Though my experience tells me that you could simplify the design and make Bounce() just an internal method call inside Collide() that defines how you react to a collision.

PARTNERS