Ce cours initie aux bases de la programmation en utilisant le langage Java : variables, boucles, fonctions, ... Il ne présuppose pas de connaissance préalable. Les aspects plus avancés (programmation orientée objet) sont donnés dans un cours suivant, «Introduction à la programmation orientée objet (en Java)». Il s'appuie sur de nombreux éléments pédagogiques : vidéos sous-titrées, quizz dans et hors vidéos, exercices, devoirs notés automatiquement, notes de cours.
Puissance 4 : finalisation
Loading...
En provenance du cours de École Polytechnique Fédérale de Lausanne
Initiation à la programmation (en Java)
182 notes
À partir de la leçon
Etude de cas
Nous voulons terminer notre cours avec une étude de cas, la création d'un jeu de « Puissance 4 », nous permettant de revoir tous les concepts abordés au long du cours.
Rencontrer les enseignants
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
Jamila SamDr
School of Computer and Communication Sciences
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.
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2018 Coursera Inc. Tous droits réservés.
