Fundamentals of Computer Science II (CSC-152 98S)


Notes on the Design of an Othello Game

Basic Questions

What are some of the issues we should consider in the design of an Othello game?

How should we segment the game into classes and objects?

Object-oriented design suggests that you put logically separate components of the game into separate classes. This helps ensure that each component can be developed independently and also allows us to reuse components in new ways. For our Othello game, we might want to change the way pieces flip, the size of the board, the rules, and the interface.

This consideration of "things we might want to change" suggests one way of segmenting the program into different classes.

How will someone interact with the program?

There are (at least) two basic strategies for interaction. We can build a text-based game, in which we repeatedly draw the board and ask the player to select where to move. We can build a more graphics-based game, in which the player can click on the appropriate point of the screen. To begin with, we will build a text-based version, since it will be easier to implement at this stage of our career.

The main "loop" of the program will be something like

  // while the game isn't over (that is, there are still legal moves
  // and neither play has quite)
    // determine the current player
    // give the current player a chance to move
    // update as appropriate

This design also makes it easier to add a computerized opponent, as we can have a Player class that we will subclass for human and computer players.

What libraries will make our task easier?

It's likely that we'll only realize this once we go on to more specific implementation details. However, it is likely that some Matrix class will be useful for a representation of the board. I would choose to use rebelsky.util.Matrix but you may find that you prefer one of your onw.

If we choose to do textual input and output, we'll need objects that support this. We've been using rebelsky.io.SimpleReader and rebelsky.io.SimpleOutput.

What other details are likely to be important?

It's likely that we'll need to worry about a few special cases having to do with the rules of the game. In particular,

What exceptions will we want to use?

It is likely that we won't be able to determine more about the exceptions until after we've designed the interfaces for our classes in more detail. Some of the exceptions we might consider are

Details of Individual Classes

Board - the game board

Game boards will most likely need to support

BoardLocation - a location on the game board

It's not clear what we'll need to do with board locations except to set up (row,column) pairs, at least at this stage of the design. We may also ask ourselves whether we want to use BoardLocations in loops, in which case we'll want to provide ways to change locations. My inclination is to include as little as possible and not permit a change to a location.

Piece - one piece on the board

Pieces are likely to be rather simple. We'll need a constructor that we can use to set their value, and that may be it. While we could just use String or some such, use of a Piece class helps ensure that we only place things that we expect on the game board.

OthelloPiece - a piece for Othello

We can make the Piece class more useful by subclassing it. An OthelloPiece can then support flip(), black(), and white() operations.

Rules - the rules of the game

If we think about the game from the perspective of the interface given in the Play class, we'll observe that the Rules class can encapsulate a number of key issues in the game.

Player - a player

The Player class might handle interactions with both user and "automatic" players. We can subclass this class for each type of interaction (initially for regular players, later for automatic players).

The primary method for Player will be

Human - a human player

How will we implement selectLocation for a human player? We could print out the board and continue to ask for a location until the player quits or selects a legal location.

Play - the interface

In our discussion of the interface, we've already seen many of the key issues for this class. I expect that this class will have only a main routine that

Reflection

Has this multi-object design made our task harder? Yes and no. Clearly, we'll need to spend more time worrying about the interaction between object. However, it is likely that we'll be able to test parts separately, which often makes it easier to track down bugs. Since this is likely to be a multi-person project, we can use the separation of objects to provide a mechanism for separating work.


Disclaimer Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.

Source text last modified Sun Feb 22 22:53:29 1998.

This page generated on Tue Jan 12 11:44:37 1999 by SiteWeaver.

Contact our webmaster at rebelsky@math.grin.edu