How to make a new game on the server side



Modify Constants.java
    Add a new "public static final String" that corresponds your game, just like those already present.  For example, if you are trying to add the game Battleship, add this line to Constants.java:
public static final String BATTLESHIP = "Battleship";
    Then, modify the array "GAMESARRAY" in Constants.java to include your new game.


Create a GameHandler:
    Next, you will have to write a specific game handler, which will extend NOOGAGameHandler,  for your game.  This is where the "meat" of the game lives.
    Your game handler should be named as follows:  Take the String you added to to GAMESARRAY in the step above, and append GameHandler to it.  So, to continue our example above, you would have to name your new game handler class BattleshipGameHandler.  This specific naming is necessary because the NOOGAServerImpl uses reflection to create the new GameHandlers.
    Whenever enough players want to play Battleship, this GameHandler will be created.  It will be passed in to its constructor a List of NOOGAPlayers playing this game, and an int ID used during the super class' RMI binding (i.e. something you don't have to worry about).  Then, the GameHandler's run() function will be called from the NOOGAServerImpl, via a new Thread.  The new GameHandler must implement Runnable, and its constructor must first call the super class' constructor, but other than that can "play" the game anyway it wants.
    After its run() function is called, it is up to the new GameHandler to control the flow of execution.  Some helpful functionality has been built into the NOOGAGameHandler.java.  It is recommended that the GameHandler first calls NOOGAGameHandler.showNames(), (to  let the Clients know who they are playing against) and then to call NOOGAGameHandler.sendBoard() (which will tell all the clients that the game is now starting).  The developer of this new GameHandler should publish the flow of execution that a client can expect, so that the whoever is writing the client can conform to this specific GameHandler (more on that later).
    NOOGAGameHandler.java also provides other functionlity such as sending all clients a message and checking to see if any of the clients have disconnected, among other things.
    Finally, when the game is over, the new GameHandler must call ShowResults(Object) on all the clients.  This lets the clients know that the game is over.  Then, the GameHandler must call done()   (implemented in the NOOGAGameHandler super class), to let the GameHandler unbind from the RMI registry, and clean up after itself.


RMI Clients:
    After the two steps above, RMI clients will now be able to connect and play your game!  We will now briefly go into what is necessary for the client to do in order to play your game.  The client must write a new NOOGAFE  (which must implement NOOGAFE) that supports the flow of execution that your new GameHandler will follow. For example, if your GameHandler calls startGame() and then doTurn() on its clients, the clients must support this!  Or, if the GameHandler expects a response after calling updateBoard(), the clients must give the necessary response!  The clients also need to know what form the board is coming in. etc. etc. etc.  See the RMI Front End Tutorial for more detailed information.
    When the new client's getGameType() function is called, it must return the String that was originally added to Constants.java.
    After the client writes a NOOGAFE that conforms to the new GameHandler's expectations, the client developer also needs to write a simple "starter" program.  It should look like the following:
 
 

public class RMINewGame //where NewGame can be replaced with the name of the new game
{

    public static void main(String args[])
        {
         String name;
         String server;

         if ( args.length != 2 ) {
           System.out.println("Usage: RMINewGame name server");
           System.exit(0);
        }

        name = args[0];
        server = args[1];

        NOOGAFE fe = new NewGameFE(name);

        NOOGAConnector connector = new NOOGAConnector(server ,fe);
         if (connector.isConnected()) {
           connector.playGame();
         }
    }
 

}
 

(NOOGAConnector, along with all the classes it uses, will be provided to the client.  So will any classes from the board or util packages that will be needed by the client.)

When this main() function is run, it should properly connect to the server, and should properly play the game after enough players are ready.'


Supporting XML clients:

Create a new "Fake Front End":
    If the server is to support XML clients for a new game, a bit more work is needed.  In the client package, you must write a new "fake front end."  This new fake FE ends up in the same place that the real FE ends up during an RMI game.  (That is: the GameHandler is connected to the NOOGAClientImpl, which forwards all function calls to the FE).  However, instead of being the "last stop" on the communication line, this fake FE stuffs everything into a socket that the end user is listening on.  The end user then processes the information and, if necessary, sends a response back down the same socket to be decoded by your fake FE.  The fake FE is needed to properly encode information (coming from the GameHandler, through the NOOGAClientImpl) to be sent to the end user, and to decode information coming back from the end user (which is then sent to the GameHandler through the NOOGAClientImpl).
    Your new XML fake FE should extend XMLNOOGAFE.   This class provides a lot of functionality that will be needed by all games (for example, sending to the client the names of all players playing).  Your new fake FE needs to implement the functionality more specific to your new game.  This means it must implement the following functions (which are declared abstract in XMLNOOGAFE):

    public void startGame(Object board);
    public void showResults(Object info);
    public void doTurn(Object board);
    public void updateBoard(NOOGABoard board);
 

 For example, when the NOOGABoard needs to be sent to the end user via an updateBoard function call, your fake FE must properly encode the board into XML any way you deem necessary, and send it over its socket.  The new fake FE must also know how to decode a board being sent in XML from the end user.
 
 

Modify NOOGASocketListener.java:
    After you have written your Fake FE, you must slightly modify  the
"public NOOGAFE getFE()" function in the inner XMLConnectionThread of NOOGASocketListener.
Inside of the function, add:
    if (myGameType.equals(Constants.YOURNEWGAME)) {
        return new XMLYourNewGameFE(mySocket);
    }

    Basically, this is just determining which fake FE to forward calls to.  In the future, we hope to use reflection such that this modification will not be necessary.