We have almost finished our case study of our Connect Four game. We now have 2 players playing alternately and we can determine if one of them has won. We just need to refine the main program so that it indicates which of the 2 players has won and to take into account a tie between the players. So this will be the topic of this episode. As a reminder, our Connect 4 game at this stage enables 2 players to play alternately by placing disks: player 'X' places a yellow disk while player 'O' places a red piece during one round or loop. This means that at the end of each iteration of the loop we can guaranty that the player's colors alternates between yellow and red. This continues until one of the two players wins. This program nevertheless needs to be improved. The first thing to do is that when we exit the loop which means that one of the players has won, to display which of the 2 is actually the winner. The second thing to do is to consider the situation where the 2 players continue placing their disks without anyone winning until the grid is filled and then no one will have won. It is a tie. This scenario is not anticipated in the present program which is not very good. Let's start modifying our program so that it displays the winner. So naturally, we have to add to the code after the loop, a certain number of instructions, which will determine the color of the player whose turn it is when the loop is exited. So if the color is yellow this means that the winner is the red player. Why the red player and not the yellow? Well, if we examine the last instructions that we execute when we leave the loop we see that they alternate the color of the player. If the color is alternated so that the color at the end of the loop is yellow, which is our case, this means that effectively, the player who won is the other color: red. This explains why we exit the loop with the color yellow and indicates that it is indeed the red player who has won. So here to cover each possibility in the other alternative case we simply need to display the fact the winner is this time the yellow player which is player 'X' in our modification. So, now we have covered each case. Here we take care to comment this test that is rather counter-intuitive by indicating that beforehand we had already changed the color of the player which explains the reason for this test here. As we said in the beginnning of this video, we can also encounter situations in which neither player wins because the players have filled the grid without anyone getting 4 in a row. Therefore we will have to complete our code so as to take into consideration this situation as well. That is to say, we will have to leave the loop not only when one party has won (this is already done), but also when the grid is entirely filled, which is not coded and which corresponds to a tie. What would happen if we do not consider the possibility of the gird to be full? Well, what could occur is that once the grid is filled we ask a player to place a token on a valid box of the grid, which would be impossible, and so we would enter an infinite loop without any likelihood of anyone winning. We wouldn't stop asking a player to introduce a disk which would be impossible as the grid is all full and so we could never get out of the cycle. This is obviously faulty for a program like this and we have to resolve this error so that the program runs smoothly in any situation. The modifications to do to our program to test if the grid is filled are quite intuitive: we have to repeat this part allowing the 2 players to play alternately, as long as neither has won, which is already implemented, but also as long as the grid is not filled. This can be written easily like this by anticipating a method "plein" (TN: means "filled") which will let us test if the grid is filled or not. This modification will change how the rest of the program runs. Indeed, we will not be in a one-track mode where there has to be a winner, but we also have a situation where we exit the loop without there being a winner, which we will indicate accordingly. Here, we will have to modify our program so as to include this scenario, so then we test: "Did we exit the loop because a player won?" and signal this duly, as we did before if the answer is "yes". If the answer is "no", then we have a tie and we have to let the user know with a relevant message. So, now we have covered all the possible situations. Here is the code for the method "plein", so we will ask alternately the red player and the yellow player into which colomn he wants to place his piece. Suppose that it's yellow's turn, if he decides to play in the first column then since it is filled automatically from the bottom up, then this means we will fill in this case the very first position of the grid. This effects how the grid is tested to see if it is full: indeed, it is not necessary to test each box of the grid to see if they contain a color or are empty but we can simply test the last line of the grid (at the top). Indeed, if this row is filled, this means that each box of the grid is also already allotted a color because the grid is filled from the bottom up. Therefore the grid is filled. Let's examine how to code this method "plein". We saw from a methodological point of view that we we consider coding a method, we have to always ask ourselves the question "what?" "what does the method do?", "what information does it need to work?" "what does it return?". These are elements that we have considered quickly here because the function is so simple through how we anticipated its utilization in the principal program. So we have anticipated that we will invoke this method "plein" on the grid and that it returns obviously a boolean variable, no doubt. This boolean indicates whether the grid is full or not. This corresponds naturally to this header of the method "plein". Now that the "what" is clear, we can now examine the question "how?". "How to program the body of the method 'plein'?" We can use the algorithm that we sketched earlier that is that if we find in the first line, that is to say in the last line according to how the grid is filled, an empty slot, this means that the grid is not full. It's this procedure we will implement. First we will use a for-loop iterating on the values of the slots of the first line. which is written "grille[0]", and test if the cell considered is empty which would mean that the grid is not full and so we would exit the method "plein" by indicating that the grid is not full with "false". If we have to go through all the cells of the first line without finding any empty slot then we leave the loop which means in this case that the grid is full and "plein" has to return the boolean "true". Note that a frequent error for beginners in this kind of situation is to implement the algorithm but in a wrong manner by returning "false" if the cell is empty, which is correct, but then to return "true" right afterwards, which is obviously not the correct procedure that we want to implement. Why? Because we have to have tested all the cells of the first line of the grid before determining that the grid is indeed full. And this cannot be known inside the body of the loop so we have to finish the whole loop before returning "true". We pay attention to these little details that beginners tend to forget but that are important in the end. So, now we've finished programming our application for "Connect 4", of course, there are many ways of programming this game and we have only presented one of them. The goal of this case study was to essentially show how to take on programming such an application when you do it for the first time. Several key ideas: first, always proceed from bottom up start by identifying the essential types of data needed, and the main functions before going into small details. Each of the functionalities and fundamental methods can in turn be modularized that is, can invoke other more detailed methods that will help it do the tasks needed. We saw that in coding each method it is preferable to have a certain methodology, and always ask the question "what does the method do?", "what information does it require?", "what information does it return?". An only then ask the question "how?" and think of the algorithms that will allow you to do the wanted manipulations. Finally we saw that it was fundamental to work on the essential aspects before working on the aesthetics. And an important point is to systematically test as you write your code and not only at the end. So, that concludes what we wanted to teach you in this case study and we hope it will be useful farther along when you will take on similar programming challenges.
