NOOGA FrontEnd Developers Tutorial

 

What is a NOOGA FrontEnd?

 

            A NOOGA FrontEnd is a class that servers as a negotiator between the client-end game and the NOOGA server.  It must implement the NOOGAFE interface to seamlessly fit into the NOOGA architecture.  Through the functions in the interface the NOOGA server will be able to send and retrieve information concerning the state of the game and its players.

 

Why use a NOOGA FrontEnd?

 

            A NOOGA FrontEnd allows another level of abstraction when developing a game for the NOOGA architecture.  Additionally, it standardizes the interaction between a NOOGA server and a client’s FrontEnd.  A client doesn’t need to wonder about how the server is going to handle information transactions – the client must simply implement the functions defined in the interface.

 

How to write a NOOGA FrontEnd:

            The first step to writing a NOOGA FrontEnd is to decide what type of paradigm you wish to use in your client program.  In the nooga.examples package Dots example the program was originally written as a stand alone (local players only) game.  It was written using the Model/View paradigm.  The actual game and the GUI components are separated into the model and view, respectively.  The NOOGA developers decided that it would be better not to write a different class to serve as the FrontEnd, but to integrate the functionality of the FrontEnd into the model component of the existing Dots game.

            So the Dots model was made to implement NOOGAFE and the needed functions were added to the DotsModel class.  As development continued with the entirety of NOOGA, it became apparent that having a separate FE in that specific case might have simplified debugging, and general enhancements.  Therefore, as a developer, one must think carefully about how the NOOGAFE would best be implemented into they specific design paradigm.

 

            The first step to the actual coding of a NOOGAFE is to create a class, which will implement the NOOGAFE interface.  By implementing this interface you will have to implement the following functions:

 

-public String get Name()

            This function is used by the server to get the name of the player represented by that specific FE.  In its simplest form it should just return the String of the players name.  The example Dots program (nooga.examples.guidots.DotsModel) has this name passed into the constructor of the DotsModel.

 

 

 

 

-public void showName(String name[])

            Here a array of names in String format are passed into the FE.  These names are all of the players who are involved in the game of which this FE is a part.

 

-public void showMessage(String message)

            This is a utility function which allows the server to send messages to the client FE.  These messages can be anything, but usually concern changes in the state of the game (beginning, player has dropped out, etc).  These message should be displayed to the user in some way since they are of little internal value.  There is no standard for the information they hold, thus parsing them would be fruitless.

 

-public void startGame(Object board)

            Called once by the NOOGAGameHandler to inform the client that it is part of a game, and that game has begun.  The Object passed into this function is expect to contain the information that a given FE would need to initialize the game which it represents.  In the Dots example this Object contain a few arrays that determine the state of the dots board. 

 

-public void showResults(Object info)

            This function is called to inform the FE that the game has terminated.  The object passed in contains information pertinent to completion of the FE’s game type.  In the Dots model provided with the package this Object isn’t needed since the score information can be extracted from the Board object.

 

-public void tick(int secondsRemaining)

            The GameHandler decides when and how often to call this function.  It is intended for use in games that are time sensitive.  For example, it could be called every second passing in the time that the FE should display as “Time Remaining.”  The time remaining is passed in (as opposed to allowing to FE to internally regulate the time remaining) allows the GameHandler more control over the rules of the game, and leaves less to the client developer.  For example, if x time is left and the user obtains a power up which allows more time left the FE would simply inform the GameHandler which would in turn handle the updating of the time.

 

-public void doTurn(Object board)

            When this function is called on the FE, the FE is expected to take a turn and then notify the GameHandler of it’s completion of the turn through the NOOGAClient.  The object passed in is the same as the one passed during startGame; however, the state of that Object may be different.

 

-public void updateBoard(Object board)

            This function is used to tell the FE that another player has altered the state of the game, and this FE may need to update its own display/state.  The object passed into this function should be of the same type as used in startGame and doTurn; however, the state should be different.

-public String getGameType()

            This function should return a String from the Constants class.  Any other String is not guaranteed to be supported by the NOOGA Server.  For instance, the Dots example returns the String Constants.Dots.

 

-public void setPlayerNumber(int playernum)

            This functions is used to assign this FE a unique player number for use in the current, joined game.

 

-public int getPlayerNumer()

            This function is used to get the player number that was previously assigned to the FE by the GameHandler.  Storing each players unique number on the server would be a great unnecessary burden.

 

-public boolean hasJoined()

            This function should return true if the player is ready to join and play in a game.  The presence of this function allows players to connect to the server and chat/browse before committing to a game.  None of the games in the examples package use this feature and automatically return true, as would any FE that doesn’t plan on allowing chatting/browsing.

 

-public void setClient(NOOGAClient client)

            This function gives the FE the client that it will be using to talk back to the server.  Function such as turnOver are available through this client.