Back to Main Page

Instructions to a Client Programmer:
How to Implement Another Game

With our object-oriented game architecture (ooga), implementing another game of your choice is easier than ever!
Our architecture works best with grid-based games that deal with playing boards.

How to go about implementing your own game:
4 Easy Steps!

Step #1: Implement a GameModel.
Think about the rules of the game. They should be totally encapsulated in the game model.
The GameModel has:

a game name (String myGameName)
a list of game pieces (LoopedList myGamePieces)
a variable that stores the current game status (String myGameStatus)
a variable that stores the status of the last move, ie. whether or not it was a valid move. This can be used in order to determine when the next player call needs to be made, when to update a gui, etc. (String myLastMoveStatus)
a representation of the current playing board that the game is being played on (PlayingBoard myPlayingBoard)

All of these items are protected variables and any object that extends GameModel needs to initialize them in the constructor and then the object can have access to any of these variables.

Any extension of a GameModel needs an implementation of the following:

Constructor(..)
    A constructor of some sort should be implemented if you want your game to be playable!
Object clone()
    for the cloneable interface, allows for the GameModel to create a copy of itselfv
void newGame()
    Resets the model's state to the beginning game status
void processClick(int col, int row)
    Process a click that occurred on the space (row, col) on the PlayingBoard
void processClick(Move m)
    Process the move, m
void updateGameStatus()
    Updates the status of the current game

Step #2: Create A GamePiece
Each game needs its own gamepieces. A string view should be implemented and then, optionally, the sourcepath of an image can be added to the extension of the GamePiece by implementing GraphicsObject and the getImageIcon function. Depending on the type of game implemented, you may need other types of functions to handle special cases.

Step #3: Register your class in our GUI
Once your game has been created, it needs to be registered in the GameSuiteFrame menu.. Because our GameGUI is generic, you do not need to make any changes to the GUI. This makes creating a new game blissfully simple.

Modifications to the code in GameSuiteFrame.java:

public void createMenuBar()
{
    ..
    ..
    ..
    newGameMenu.add(createGameMenuItem((new MemoryModel(5), new ImageIcon("Memory.png")));
    ..
>>newGameMenu.add(createGameMenuItem((new newGameModel(), new ImageIcon("newGame.png")));<<
    ..
    ..
}

This line of code adds a new menu option for you game on the main menu. The first parameter for createGameMenuItem is a new instance of the game model and then second is the picture that the menu will display if you want it to.

Step #4: You may Need Helper Classes
You may need helper classes for your gamemodel. For example, in Boggle, we used Professor Astrachan's trie, jogglereader, joggleword finder classes. For other games, we had smaller classes that dealt with functions that were particular to a type of game. For instance, in boggle, we created a dice class and a collectionofdice class. The Dice class used a random generator to randomly generate a number which corresponded with a letter, so that each of boggle's lettergamepieces would return a randomly generated facevalue every time a boggle playing board was created. You may need to create classes that are small and struct-like. As a client programmer, this is your call and, of course, there is no right answer.

Suggestions for future games that could be implemented:

Minesweeper
Battle Ship
Black Box
Chomp
Dots
PipeDream

Back to Top