♕ Phase 5 ‐ Chess Pregame - softwareconstruction240/softwareconstruction GitHub Wiki

• Chess Application Overview
• Getting Started
• 🖥️ Videos

In this part of the Chess Project, you will create an initial version of your Chess client. Your Chess client will be a terminal-based (i.e., console-based) program that gives the user a simple interface for playing Chess. Your client should implement all user interactions that occur outside of actually playing a game. Game play interactions will be implemented in the next phase. This includes allowing the user to display help text, register, login, list existing games, create a new game, play a game, observe a game, logout, and exit. You will also write the client code that draws the chessboard.

To implement this, you will create a ServerFacade class to handle sending and recieving HTTP requests to and from your server. Your client code will then use your ServerFacade methods to make server API calls.

When the user first opens your Chess client application they can execute any of the Prelogin commands.

After the user has registered or logged in they can then execute any of the Postlogin commands.

As stated previously, gameplay will not be implemented until later. For now, when a user plays or observes a game, the client should draw the initial state of a Chess game in the terminal, but not actually enter gameplay mode. If you join the game either as the white player or as an observer then the chessboard must be drawn from the perspective of the white player. That means that the first row and column of the board (a1) should be displayed in the bottom left corner.

If you join as the black player then the board should be drawn from the perspective of the black player. That means that the first row and column of the board (a1) should be displayed in the upper right corner.

You are free to make your chessboard look different as long as the essential information is displayed in an easily readable way, but it must look like a chess board. You must have different colors for alternating squares, but they don't have to be white and black. Light and dark, or white and brown, or whatever you'd like is fine. Per official chess rules, the bottom-right and top-left squares (h1 and a8) must be the "lighter" color. This will mean each queen is "on her color" (white queen on a light square, black queen on a dark square). The boarder of the board must show the correct row numbers and column letters.

Note that in the above images, the blue letters are black pieces and the red letters are white pieces.

When developing a UI you should focus on the user experience and only present things in a way that the user can relate to. This means that you should not display programming jargon or debugging information. For example, you should avoid:

• Anything in JSON - If you have something in JSON, parse it and then print out only the information you want the user to see.
• Authtokens and Game IDs - These are important to keep track of but the user should not be aware of these internal variables. See the requirements for the Postlogin UI for what to display instead of Game IDs.
• HTTP status codes - The user should not be made aware of internal details like this. Ask yourself, apart from 404, when was the last time you saw a status code on a professional website?
• Exception stack traces - Hackers love these kinds of internal details as they show how your code works. These should never be displayed to users, although logging them to a place users will not find may be useful. Instead of a stack trace, a simple message informing the user an error occurred (and hopefully why the error occurred without too many details) should be sufficient.

To create a smooth user experience, make sure that your client doesn't freeze or crash in any way. If an exception occurs, catch it. A user may mistakenly put in all kinds of bad input and your client should be able to handle bad input without crashing. This includes incorrect number of arguments (too few or too many), wrong types of arguments (a word when the code expects a number, arguments in the wrong order, etc.), and arguments that the server rejects (register with an existing username, login with incorrect username/password, etc.). When you go to pass off, the TA will test for bad inputs, so please test all of these examples on your own first and ensure the program does not crash and provides reasonable error messages when each error occurs. Test other examples of bad input that you can think of as well, as this list is not exhaustive. If the output your program produces is not reasonable, the TA will have you go and change it. You may then have to redo the pass off.

Even though your client does not implement gameplay yet, make sure that you can exit any menu you create. If your client gets stuck in a state that a user cannot exit from, the TAs will not pass you off and will have you come back when you have fixed your menu.

• Console UI: Reading from the keyboard and writing out fancy text.
• Web API: Making HTTP client requests.

Should you choose to use the unicode Chess characters, some machines by default don't render them in the console (this is often the case if you are using a .jar file). To fix this on Windows (it shouldn't be an issue on Mac/Linux), go to Settings > Time and Language > Language and Region > Administrative Language Settings and on the Administrative tab click Change System Locale and then check the box for using UTF-8 which requires system reboot. This should fix the issue.

Additionally, you may notice that the chess characters might render slightly wider than everything else. To balance this out, a wider version of a space called an em-space can be used. It is denoted by \u2003 and is currently being used as the middle space in the EMPTY escape sequence, so if you choose not to use the Unicode chess pieces, you will have to replace that with a regular space to get everything to line up vertically.

There are no new pass off test cases for this assignment.

Write positive and negative unit tests for each method on your ServerFacade class (all the methods used to call your server).

Your tests must be located in the file client/src/test/java/client/ServerFacadeTests.java, provided in the starter code.

[!TIP] ServerFacadeTests.java contains code that will automatically start and shutdown your server on a randomly assigned port as part of the test. However, you will still need to start your server using the Main.main function when you manually run your client.

public class ServerFacadeTests {

    private static Server server;

    @BeforeAll
    public static void init() {
        server = new Server();
        var port = server.run(0);
        System.out.println("Started test HTTP server on " + port);
    }

    @AfterAll
    static void stopServer() {
        server.stop();
    }


    @Test
    public void sampleTest() {
        Assertions.assertTrue(true);
    }
}

Replace the sampleTest method with your own unit tests.

Your server facade will need to take the port that the server is running on as part of its initialization when running your tests. You can accomplish this by modifying the init method to create and initialize your server facade with code that is something like the following:

private static Server server;
static ServerFacade facade;

@BeforeAll
public static void init() {
    server = new Server();
    var port = server.run(0);
    System.out.println("Started test HTTP server on " + port);
    facade = new ServerFacade(port);
}

You can then directly test your facade with tests such as demonstrated in the following register unit test example.

@Test
void register() throws Exception {
    var authData = facade.register("player1", "password", "[email protected]");
    assertTrue(authData.authToken().length() > 10);
}

Make sure you clear your database between each test. You can do this in a method that has the @BeforeEach annotation.

For this phase the auto grader will grade the quality of your project's source code. The rubric used to evaluate code quality can be found here: Rubric

All of the tests in your project must succeed in order to complete this phase.

To pass off this assignment, first submit your work to the course auto-grading tool. Once it completely passes the autograder, meet with a TA and demonstrate that your Chess client and server meet all requirements and they will assign you a final grade.

[!NOTE] You can receive 4 points of extra credit by first receiving 100% from the autograder and then completing an in-person pass off before the final due date.

• 🎥 Phase 5 Introduction (8:11) - [transcript]
• 🎥 Read-Eval-Print-Loop (REPL) (8:11) - [transcript]
• 🎥 Drawing the Board (1:26) - [transcript]
• 🎥 Server Facade (5:00)- [transcript]
• 🎥 Phase 5 Requirements (3:11) - [transcript]
• 🎥 Client HTTP (12:11) - [transcript]