Subscribe to andrewsw's Blog        RSS Feed

Ball Games - OOPs!

Icon Leave Comment
I responded to a question about deciding what classes were needed for a ball game. The game itself wasn't specified, so the following advice is very general, and goes beyond that for a specific game (ball or otherwise) or language (the question was asked in the Java forum).

I should qualify that I am not an expert, and so encourage comments. However, I believe the advice below to be, hopefully, useful and logical.

Firstly, the answer to the question "what classes do I need" is : IT DEPENDS. It depends, firstly on the specific game that you are playing/building, but it also depends on the overall design decisions that YOU decide to make.

Typically, there is a Game class. Game (or, more precisely, a game instance) is in overall control - it maintains the state of the game. You would create a new instance of Game and (usually) use the constructor to define the parameters of the game. How many players, level at which the game is played, etc. Creating a new (instance of) Game could effectively start the game, or you might decide to have a separate start() or play() method.

Typically, a game might have properties such as stateOfPlay, duration, level, etc.

A game involves players. In a trivial application this might just involve passing the names of the players in the game's constructor (or adding them later via a method). However, Player could be a separate class; in which case, they could be created separately, and you could store information such as their name, skill-level, handicap, nickname and, in particular, highestScore (gamesPlayed, etc.).

A ball screams that it should be an object. But does a ball require an existence outside of the context of the game? Typically, the game might control and manage balls. In which case, the Ball class could be nested within that of Game (a nested or inner class). This decision is a little tricky and it depends very much on the game itself. (Also, not every language allows us to define nested classes.)

Java - nested classes

Assuming for the moment that the Ball class is nested within that of Game, then starting (or instantiating) a game would typically involve the game instantiating a number of balls and maintaining them (internally) as a collection or list of some kind.

The OP referred to "movement" and "collision", but thought of them as classes rather than as, sensibly, methods of a class. But of which Class? Ball or Game (or some other)?

"Movement" screams that it should be a method - move(). But should it be a method of a Ball (if it has a separate existence outside the game) or of the game itself? Consider it this way:

myBall1.move(x, y)

This has no connection to the game itself?!

aGame.move(player1, ballA, x, y)

This depends on the game; specifically, can the player determine which ball to move? Otherwise it might be:

aGame.move(player1, x, y)

in which case, the Game decides which ball might be (or needs to be) moved - the player doesn't get to decide!

Again, decisions about move() (and collides() - discussed below) would be dictated by the game and its rules.

Note how player1 is supplied as an argument to a method of the game. In many board, and card, games players take turns, and this rule cannot be violated! In which case, it would not be necessary to supply a Player as an argument, as the Game would always know which player's turn it was. In fact, in these cases, specifying the player adds unnecessarity complexity. For such games, the Player-class has little involvement in the execution of the game. They are identified in the construction of the game, supply details about the move they wish to make (when it is their turn), and a Player is identified as the eventual winner of the game.

"Collision" again shouts that it should be a method, returning a boolean value: collides(). Ignoring the Game for the moment, typically collides() might be a static (class-level) method of Ball, to determine if two balls collide:

Ball.collides(ballA, ballB)

If Ball is a nested class then not all languages permit nested (inner) classes to have static methods. In which case, it might require something like:

aGame.collides(player1, ballA, ballB)

Typically, though, decisions about collisions are integral to a game, and so might utilise a private method of the Game class or a method of the Ball class that is nested in that of Game:


The player(s) might not need to know about individual collisions. Perhaps this information is only conveyed (exposed) to the player(s) in the event of an illegal, or succesful, move? For example, a move() attempt might make use of the collides() method, and return a boolean value indicating whether the requested movement was accepted - that is, was legal (according to the rules of the game).

You can see that a lot of decisions depend on the specifics of the game. My advice is to jump in and explore! You can always come back with a question for DIC once you've got the ball rolling!

0 Comments On This Entry


Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

December 2020

  1234 5


    Recent Entries

    Recent Comments

    Search My Blog

    1 user(s) viewing

    1 Guests
    0 member(s)
    0 anonymous member(s)