Looking at the preceding flow chart, which meets our requirements, we know we need to develop the following in the ASP.NET Core 2.0 application to constitute a basic two-player Tic-Tac-Toe game:

1. A web page where players can go and register themselves with their name and display a picture
2. A module to find an opponent to play against

3. A module to simulate a coin toss to ensure fairness in giving players the option of making the first move
4. The UI for the Tic-Tac-Toe game board in the web page, that is, a 3×3 grid where players can place their image
5. Logic to indicate to the player whether it's their turn or the opponent's turn
6. A module to show the opponent and player the move that was made
7. A mechanism to ensure that the player and opponent's board are in sync with their moves
8. Logic to check whether the game is over
9. Logic to determine the winner

Sounds simple enough! Let's see how we can design and implement each of the preceding points by using ASP.NET Core 2.0 goodness:

1. Web page for registration: We have multiple options available to code this. We can either use a static HTML page, or a regular .cshtml view of MVC, or the new Razor Pages introduced by ASP.NET Core 2.0. Since we will be working extensively with Razor Pages in the next chapter, we will use the .cshtml Razor view to create the UI of the game.
2. Opponent-finding module: When a player registers, we can store his details somewhere on the server so the server knows how many players are registered to play. When a player finds an opponent, we can pair them as opponents based on their registration time. The problem with just relying on registered users, though, is when a player registers and closes the browser window knowingly or unknowingly, or decides not to play the game after registering. So, we need to ensure that we pair up only those players who are registered, are actively connected to the server, and are looking for an opponent to play the game with. If a player disconnects in the middle of the game, award the game to the opponent and inform them that the opponent has disconnected. We will need to do additional housekeeping to refresh the registered players in the server as new players join and existing players disconnect. To check whether a user is connected or not, we may need to perform additional housekeeping by writing additional code or making use of sessions. 
3. Simulate coin toss: There are many ways to simulate a coin toss, such as generating a random number between two numbers and seeing whether it's even or odd. In our case, to keep things simple, we will generate a random number, either 0 or 1. If it's 0, it's heads; otherwise, it's tails.

4. UI for game board: As already discussed, we will be using the standard MVC Razor view to create the registration form as well as the Tic-Tac-Toe game board user interface. Designing the game board for Tic-Tac-Toe is rather simple with CSS; we just need to get the correct box style and arrange the boxes in a 3×3 grid. To place the player's image on the board, we pass the player image to each of the players and update the box background style to the image when the user clicks on that grid box. The challenge we can see here is how we will keep the game board of both the players in sync at any given time. Although the individual player and server know which player has a marker placed at which position, the opponent needs to have the same picture of the game board. This is something that the server needs to inform both players of after every turn. 
5. Logic to indicate whose turn it is: Although the server knows the toss result, it needs to inform one player to make a move and the other to wait for the other player to make a move. And after each turn, the server needs to inform both players (clients) about the turn, so the server has to push data to the clients after every move.
6. Module to show the players the move that was made: Like the preceding point, it is again the server's responsibility to update the players about the last move and ensure both players have a game board view after each move.

The last two modules are straightforward. We need to check whether the game is over and we have a winner. The interesting part of our discussion is that in Steps 2, 4, 5, and 6, we came across scenarios where the server needs to push data to the client. This is something that has already been made incredibly easy by the ASP.NET team who developed a library called SignalR. So, we will use SignalR to cover these scenarios. Before we dive into coding, let's understand what SignalR is, how it works, and how it saves us from writing all this stuff ourselves.