• Its contents, such as the state of a game
• Its visual appearance (the GUI)
• Its behavior (reaction to player moves)

These characteristics will be realized through the Model-View-Controller design pattern (MVC). MVC consists of three objects. The Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to screen input. MVC decouples views and models by establishing a subscribe/notify protocol bewteen them. A view must ensure that its appearance reflects the state of the model. Whenever the model's data changes, the model notifies views that depend on it. In response, each view gets an opportunity to update itself. The model communicates with its views when its values change, and the views communicate with the model to access these values. This approach lets you attach multiple views to a model to provide different representations. You can also create new views for a model without rewriting it.

To come up with a design for our overall game architecture, we first implemented Tic-Tac-Toe without taking any sort of general architecture into consideration. We did this in order to get a feel of what is involved in programming a game. In our use of the MVC design pattern, each game will implement the following two classes:

• The GameModel, which stores the contents or state of the game;
• The GameView, which displays the contents, handles user input, and controls the flow of the game (i.e., taking turns between players).

We will also provide classes that represent common functionality in our games. For example, games such as Chomp, Connect Four, Dots, Tic-Tac-Toe, etc, all share several common characteristics which we can exploit. First, all of these games are a competition between two players - one being human and the other being either human or "machine" (an A.I.). The controller in these cases will basically only be responsible for delegating the turns between the two players and controlling the flow of the game. Our first idea would be to include code such as the following:

public void nextPlayer() 
{
   if (gameOver()) showWinner();
      
      // switch players
      else 
      {  
         if (nextPlayer == player1) 
         {
            nextPlayer = player2;
         }
         else 
         {
            nextPlayer = player1;
         }
         nextPlayer.takeTurn(); 
      } 
}

A GameBoard can be leveraged by any game that is played on a grid-like surface. A GameBoard consists of any number of GameTiles. A programmer will be able to easily change the look and feel of the board using setColor(), setSize(), and other visual-enhancing functions.

A GameTile can be a button to click on (like in Tic-Tac-Toe), a tile to simply display something, or anything else that can have ActionListeners associated with it. This makes the GameBoard class flexible across different games because each GameTile will be able to perform a variety of tasks depending on the game.

A Player class is useful for games supporting two or more players. Each Player object can make a move, or take it's turn, using an abstract takeTurn() method. In this way, we can easily incorporate different players into game, such as a network player, or even an artifical intelligent (AI) player.