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 : moteur de jeu
Loading...
From the course by École Polytechnique Fédérale de Lausanne
Initiation à la programmation (en Java)
175 оценки
From the lesson
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.
Meet the Instructors
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
Jamila SamDr
School of Computer and Communication Sciences
Let's continue programming our famous Connect Four game.
At this point, we know how to represent the game,
we know how to represent the colors,
we know how to initialize the game,
how to display it,
and then we saw how to make the core of the program,
the <i>joue</i> method,
which allows us to get a column number from a user,
verify if we can actually play in that column,
and if possible, make that play.
But at this point, we still don't really know how to play the game.
So let's try to write a <i>main</i> method
that will handle the actual gameplay.
For this, what we will need to do
is of course ask a user for a move,
make this move,
display the game, then alternate,
change the player's color.
Of course, we want to repeat this, to play one turn after another
until the game is over.
So, now, we are clear with what the method has to do, with the "what".
As always, when we write a method,
we should first think about what it has to do, the "what"
Now that this is clear, we can start to write
and of course, we start with the classic header
then the body of the <i>main</i> method.
Before entering this game loop which we have just described,
we must of course declare a game.
So here, this is a two-dimensional integer array,
which we call "grille" (TN: means "grid").
And we know that a Connect Four grid has six rows and seven columns.
Then we will of course initialize it.
So we call our <i>initialise</i> method.
And it is nice to display it to show that we are starting with an empty grid.
Now, we will define the color of the first player.
In Connect Four, we start with the yellow player.
So we initialize a variable defining the color of the current player to yellow
There, now we are ready to begin our game loop,
as we discussed earlier.
The question we should ask ourselves at this point is:
should we use a <i>while</i> or <i>do while</i> loop?
Do we begin by testing something?
Or do we begin by executing something
before testing a condition and looping?
Here, I can't really imagine what we might want to test.
We are in the initial situation,
we control everything.
So we will start by running through our game sequence,
then we will test whether we should continue or not,
if the game has ended,
and if that is not the case then we will of course loop
So, this is a <i>do while</i> loop.
We start by writing <i>do</i>.
And what we want to do first in our loop
is to ask the player for a move.
We could do this with a function,
but here, I will write everything in the <i>main</i>
and we will come back to it a little later on.
That being said, even if we don't make this into a function,
we can adopt the same methodology
and decompose it into sub-tasks:
to ask for a move, what should we do?
We must ask the question and retrieve the answer.
So we start by asking the question
To do so, we will display a message to the user
and we will display a different message
if the player is red or if he is yellow
since we will also use this message to indicate their color.
So if the players color is yellow, we will display the following message:
Of course, <i>system.out.println</i>.
Here, we display "joueur" (TN: means "player") and their color
here we will display an X for the color yellow,
player X, and we will ask him to enter a move.
Otherwise, we display a message for the red player.
We use a capital O
to display the color red, just like for the disks.
And we end here with the same message
Then, we want to input the reply.
To do this, we introduce a new <i>colonne</i> variable (TN: "colonne" means "column")
which will be the column in which the player wants to play.
And we read with <i>nextInt</i>.
Of course, we mustn't forget to declare something to be able to read this,
so we declare a Scanner as usual.
And, following the suggestions we gave you in the previous episodes,
we declare this variable outside of the <i>main</i> here
to be able to access it in the entire program.
There, let's shift all of this up a little
to continue with our <i>main</i>.
By the way, don't forget that the indices we use for the grid in Java
are shifted by one compared to the indices that we humans use.
Humans would count from one to six,
whereas we will begin at zero.
So we must shift by one with "--colonne".
Then we will be able to actually make this move.
Remember that the <i>joue</i> method,
as we wrote it in the previous episode,
returns a boolean that is true if the move is valid
and false if it is not valid.
So we get this return value and store it in a boolean,
in a <i>valide</i> variable which we declared and initialized here,
with a call to our <i>joue</i> method
which takes the grid,
the column number we just received from the player
and the color of the current player
which we declared here.
If the play is invalid, it is important to let the player know
and so if it is invalid,
we display a message indicating that the play was invalid:
so, <i>println</i> the message.
Now, third step in our loop: displaying the game.
And now, fourth step...
... let's shift this all to have a clearer picture...
... fourth step of our loop: alternating the colors,
i.e changing the color of the current player.
As usual, we write comments to be as clear as possible.
So, we change the color very easily.
We could also write a method to do this, actually this would be a good place to do so,
but the method is simply: if the current color is yellow,
then we change it to red.
Otherwise, we set it to yellow.
So, <i>if</i> the current player's color is yellow,
we set it to red.
So if the color of the player is yellow, I set it to red.
Otherwise, I set it to yellow.
<i>couleur_joueur</i>, remember, is the variable representing
the color of the current player.
There, we have finished our loop
and all we need to add is the condition.
What condition?
The game continuation condition.
We continue playing while...
Well, I will leave this to the next episode,
and leave this blank.
This concludes our <i>main</i> method that allows us to play.
I encourage you to compile and test it.
Of course, you have to write something here in the blank space.
At first, you can write <i>while true</i>
to have an infinite loop,
and you can stop the program with the environment.
I encourage you to systematically
make tests like this
when you are at such a step.
Personally, I would prefer to review this code right now with you
to organize it better, to modularize it,
that is, to create methods to handle the most important parts.
We have already said that we could write a display method here
and we will come back to this later on.
We could write a method to alternate between the players.
And, on a larger scale,
we could make a method of all of this,
since it is essentially the core of the game.
The <i>main</i> is way too large here. As you can see,
it doesn't fit on one slide
which is a sign that it is not well written.
A <i>main</i> must be very concise, very clear.
So we will modularize it, we will chop it up into methods.
The easiest is to directly cut out the part we want to make into a method,
as we explained to you in the episode on methodology for
function and method development.
Then we start to write the method call as we envision it,
so for example, let's say that this part corresponds to asking and playing,
so we will call it demandeEtJoue (TN: means "askAndPlay").
This will be the name of our method, demandeEtJoue.
And what does this method need to receive?
It needs the current game of course, so the grid
and the color of the current player.
Those are the two arguments we pass it.
And now we can proceed to writing this method.
As a reminder, here is the call in comment.
So we pass the grid and the player's color to demandeEtJoue
This gives the following header:
void demandeEtJoue taking a grid
and a color.
Then, in the body of the method, we will simply
copy everything we had cut out of the <i>main</i>
to make it into a method.
At this stage, one should be very careful not to make any mistakes in the names.
For example, here we used <i>couleurJoueur</i> again
and I strongly encourage you to save, compile and verify
that the code is correct and that we haven't made any mistake.
Of course, you should proofread it,
and possibly test it too
with a small test method.
In the spirit of modularizing,
let's try to avoid copy-pasting as much as possible.
I see several copies of the same thing here.
I see that "Joueur" was repeated here.
I see that here, we repeated the message asking the user for a column number.
This all is not right and we will have to make it modular.
To do so, we will find the common parts
and remove them from the condition on the color.
Because, which part of this depends on the color?
The only part that does is this output here
of the X and O.
So we will put the common parts preceding the display of the X
before the <i>if</i>,
and we will put the common parts following the display of the X and O
after the <i>if</i>.
This gives the following code:
We start by displaying the common message "Joueur "..
and careful here, we are using <i>print</i> and not <i>println</i>
since the line is not finished and we do not want to display a newline.
Then we make our test on the color and in this case,
if the color is yellow, we display the X
otherwise, we display the O.
Then we have another common part which is displayed using <i>println</i>
thus displaying the end of the message.
And now, we see again that we could modularize
a little bit more.
And this little bit of code here, these few lines,
could be a color output
which would be useful both in displaying the game
and displaying the player like we did here.
Let's make the most of already being in this demandeEtJoue method
to improve the algorithm part of it.
What happens the player enters a move that is invalid?
In the previous version, we simply passed to the other player,
which is certainly not correct
Here, we will have to ask again while the move is invalid
Asking again means having a loop.
Once again, we ask ourselves the question: should this be a <i>while</i> loop,
or a <i>do while</i> loop?
In other words, do we start by asking the question, then checking the condition?
Or do we start by verifying the condition, then execute code?
So here of course, we start by executing,
we start by asking for the move before checking whether it is valid.
So it is a <i>do while</i> loop. Let's write it.
<i>do</i> the whole bloc of our method here, then <i>while</i>.
<i>while</i> what?
Remember, what we want to do if the move is not valid,
is to display the message, and we want to repeat this entire interaction
here while the move is not valid.
So this is written <i>while not valide</i>.
There, we're pretty sure we have finished. We save, we compile
and what happens?
The code doesn't compile because of the scope of the <i>valide</i> variable here.
It is declared in this bloc here.
And so the <i>valide</i> variable is not defined here.
So we must move the <i>valide</i> variable
which is declared in the loop,
and put it before the loop to be able to use it
in the condition of the <i>while</i>.
Of course, if we do this, we must be careful to note
that we now have two declarations of <i>valide</i>.
One here, and one here. So obviously, we should
correct this one and delete it.
Now, we just have one single assignment in the loop.
There, our demandeEtJoue method is now finished,
it compiles and should execute correctly.
Let's end this episode with a last look at the joue method.
To answer a quiz that was asked in a previous episode
let's look at what we have to do to correct this joue method.
The problem here is that we access a row and column in an array
without actually checking that the column we received is correct.
We could imagine that this test would be done before the joue method.
We could for example have done it right after asking the player
to enter a column number.
If he enters a number that is too large, such as 100,
we could tell him that the move is not valid.
But it is best to put this sort of test
as close as possible to the danger it protects against.
Which would mean putting it in the joue method here,
as it receives a column number as parameter.
Checking here would guarantee that this column is compatible
with its use here as an index in the grid.
So we will simply start
as usual, by writing the comment
and saying that if the column number is larger than the size of the array,
then it means that the move is invalid.
In Java, this is written like so:
If <i>colonne</i> (TN: means "column") that we received as parameter
is larger than the size of the grid,
so for example <i>grille[0].length</i>,
then at that moment, we simply <i>return false</i>
since the move is not valid.
There, this concludes this episode.
All that is still needed,
to have a complete game,
is to implement the stopping test
in the game's loop.
This will be the subject of the next episode.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
