Ce cours initie aux bases de la programmation en utilisant le langage C++ : 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 C++)». 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...
Del curso dictado por École Polytechnique Fédérale de Lausanne
Initiation à la programmation (en C++)
224 calificaciones
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
De la lección
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. Nous en profitons pour présenter un dernier type de données : le type « énuméré ».
Conoce a los instructores
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
Jamila SamDr
School of Computer and Communication Sciences
Let us keep on following the demanding path
of the programming of our Connect Four game.
At this point, we know how
to represent the game: the grid (type "Grille").
We also know how to represent the player's colors,
initialize the game, and print it.
Finally, we have coded a more complex function
to drop a disk
in the grid if the
inidicated move is valid.
However, right now,
we are still not able to effectively play.
Let's try to play, then!
To that end, we will try to write a "main" method
which will let us play.
We start just like usual :
" int main() " then the body of the "main".
Let us begin, of course, by defining a game,
that is, a "grille" (TN: means "grid"),
which we will initialize.
This is very usual.
Also, at the beginning, we will have to show it
to the players, thus printing it.
Now, what should we do?
We need a player
which will be represented by a color.
Therefore, we will start by declaring a "Couleur"-type variable;
this will be the color of the current player.
Now, let us initialize it, for example to, "jaune" (TN: means "yellow").
What should we do now?
Well, we should of course strive to run through the game,
as long as we can play.
We will thus need a loop.
Should this be a "while loop" or a "do while loop"?
Will we start by testing something?
Or will we start by playing?
Here, all the conditions are fulfilled,
the game is initialized, we have a player:
we can start playing right away.
Therefore, we resort to a "do while loop".
Here, we thus write "do".
Now, what will we do exactly inside this loop?
The first thing is, of course,
to ask the player to inidicate his move.
So, let us start by printing a message to the player
to inform him that we expect him to enter a move.
In this message, we will also indiciate the player's color.
To that end, we should use a "print_player" function,
but, here we will write it directly
to show right now how it looks like.
Thus, if the color of the player is yellow, we will print :
"joueur jaune entre un coup" (TN: "yellow player, enter a move")
Otherwise, if the red player is at turn,
we will print that the red player,
that is, according to our convention, 'O',
has to enter a move.
They must thus enter a column number.
Then we should, of course, read their answer.
To that end, we will declare a "colonne" (TN: means "column") variable,
a "size-t"-type variable,
since we will use it to index our grid.
In this variable, we will retrieve
the player's answer.
By the way, we should not forget that the players will play
between 1 and 7. However, in C++,
the arrays are indexed between 0 and 6.
Therefore, it is absolutely necessary to decrement,
subtract 1 from the column.
Now that we have a column number, given by the player,
we can play our move thanks to the "joue" function,
which we have developped in the previous episodes.
Thus, we declare a boolean variable "valide"
which will test the validity of the move.
We will thus call the
"joue" function here, in the initialization of the boolean.
Now, here a little comment regarding this line.
Here, we declare a bool-type variable
"valide" initialized directly
with the return value
of the "joue" function call.
By the way, please remember
that we passed the grid, the column we just declared here
and the color of the current player to the "joue" function.
Thus, since this function is testing if the move is valid,
and that the result is stored inside the variable "valide",
we need to inform the player
if the move was not valid.
Therefore, if "not valid",
we will print a message,
warning the player.
Once the move has been played or once the player has been
warned that his move was invalid, in both cases,
we will print the game again.
Therefore, the player will see what is happening.
Let us shift this all.
Now, we can move to the other player.
Thus, simply,
if the player's color is yellow,
then the current player's color will become red.
Otherwise, that is, "else",
the color of the current player will become yellow.
Here, out of this little portion of code here,
similarly to the previous printing a little while ago,
we should have made a function
called, for example, "alternate_player".
For this episode though, it is enough to have it in the "main";
we simply wanted to show you
how to globally organize the game.
Now, at this point, we have asked the player to enter a move,
retrieved his answer
and tested the validity of the move. If the move was valid,
we effectively dropped the disk in the grid.
If it wasn't valid, we warned the player.
One way or the other, we printed the game
and swapped the player's colors.
We have thus terminated a game turn.
We can thus finish our "do while loop",
making it possible to alternate game turns.
Now, the question is: what test should we put here,
for the game stopping condition?
We will leave this aside for now
since this will be the topic of the next episode.
For now, we will leave this blank.
Our version is now almost complete.
Only this test here is missing,
finishing the almost complete version of the game.
At this point, we can criticize our work a little bit
and try to improve our code.
The problem here, is that the "main"
is way too big; it does not even fit
on one slide!
This proves that our "main" function is way too big.
We will thus need to "modularize",
try to split this big "main", into smaller functions.
Thus, we propose here
to regroup all this in a function.
What does this portion of code do?
This is where we ask the player
to enter a move.
We were testing the validity
and playing this move.
If the move was invalid, we warned the player.
This all corresponds indeed to a functionality
which can thus be grouped in a function.
We will call it "demande_et_joue" (TN: means "ask_and_play").
This is a possible example of modularization;
there are many others.
If you so desire, you may create your very own modules(= functions).
What matters is to identify the key concepts
and, mostly, to decompose
in order to render our code all the more modular,
readable and maintainable
in a independent way.
Now, let us go back the function methodology.
If we have identified a portion of code that is
either repeated (never ever copy-paste!!)
or important by itself, which is the case here.
We wish to make a function out of this portion of code.
What we start by doing is simply to cut it.
Voilà! We have suppressed this portion of code.
We then replace it
by a call to our function "demande_et_joue".
So, what will this function receive as parameters?
Of course, the game -- the grid --
and the color of the current player.
This should be enough for our function.
Now, let us move on to the writing of this function.
As a reminder, we added here in a comment
how to call this function.
Thus, the function "demande_et_joue"
is called directly; its return type is
thus "void".
The function is called "demande_et_joue".
As parameters, it will receive a grid,
which we had defined with the "Grille" type.
Is the grid modified?
Yes! "demande_et_joue" will let us play in the grid;
the grid is thus modified
and will be passed by reference.
Then, we pass the player's color.
Is the player's color modified?
Obviously, the answer is no.
Therefore, a passage by value is enough here.
Here is now the prototype of our "demande_et_joue" function.
We can now move on to its body. This is simple;
we simply need to paste the portion of code
we had suppressed from the "main".
At this point, when you practice this kind of exercise,
it is a good idea to reread your code in order
to verify that you have not omitted anything or made a mistake.
Then, you should compile because you could have erred in the names.
For example, we could have called this "couleur"
instead of "couleur_joueur". Because of this mistake,
we would have triggered a compiling error.
Finally, we should test our function.
Let us keep modularizing
and improve this portion of code here.
We have already mentioned,
previously in this episode, that we could make a function out of it.
We would call it "affiche_joueur" (TN: means "print_player").
But here, even without making a function out of it,
we can still improve this code,
regrouping the common parts.
Do not ever resort to copy- pasting. And there is copy-pasting here.
Indeed, "joueur" (TN: means "player") has been copied twice.
Also, the message "entrez un numéro de colonne" (TN: means "enter a column enter")
has been repeated twice.
Here, we can thus rearrange our code a little,
beginning by printing the common part.
Thus, we will print the message "joueur".
Here, we do not need the "endl" since we will print
either "X" or "O" just after
and resume the "message"; there is thus no "endl".
Then, we will keep the test
that was there previously, regarding the color.
Thus, if the player's color is yellow,
we will print X". Otherwise, we will print "O".
At this point,
it is this part we can modularize
and turn it into a function :
for example, "affiche_couleur" (TN: means "print_color").
This function will thus print
'X' if the color received as parameter is yellow
and 'O' otherwise.
Let us conclude our printing of the common part
following the printing of the player's color.
Namely, the message "entrez un numéro de colonne"
and, of course, the line break.
Let us conclude by improving another aspect, algorithmic, this time,
of our "demande_et_joue" function.
What will happen if a player enters an invalid move?
In the current version,
we will simply print
that the entered move is invalid.
Then, we will switch to the other player.
This does not, in fact, correspond to the reality of the game.
What should we do, then?
Well, as long as the player does not enter a valid move,
we will not let him free;
we will keep asking and asking.
Therefore, we will once more resort to a "do-while loop",
since we will start by asking the player to enter a move,
verify that the move is valid,
and keep asking as long as the entered move is invalid.
We thus have a "do" loop
on all the block asking the player to enter a move.
Then, we will verify if the move is valid
and, finally, inform them if the move was invalid.
Therefore, we will move all this block inside a "while".
While what?
While the move is not valid, that is, "while not valide".
However, this code will not compile. Indeed, we use the "valide" variable here
and the scope of "valide",
which has been declared here, is this block.
Therefore, we have a utilization of "valide" beyond its scope.
Consequently, at this point,
the compiler will produce an error.
What we have to do is to pull
the declaration of "valide" outisde the loop.
For example, we could put the declaration up here,
or just before the loop.
Here, we thus declare "valide",
which we could initialize to "false".
Of course, we should not keep
this declaration here, for we would then have two variables "valide".
We would have this one here, with a scope local
to the block controlled by the "while" instruction.
And we would have another "valide" here, with a scope local to the function body.
Obviously, this would not work,
and we will thus change this
declaration-initialization to an assignment.
This is it for our function "demande_et_joue".
A last comment though.
We could obviously have put
the printing of the question inside the "do-while loop";
this is a variant. Namely,
after every valid move, we will print which player is to play.
In the previous version,
we simply repeated the entered answer.
Let us conclude by a last comment regarding the "joue" function.
This is related to a quiz of the previous episodes.
The problem with this "joue" function
is that the column number is never verified
before we access the array here.
It is not verified, neither in the "joue" function here,
nor in the function "demande_et_joue".
Here, we simply trust
the player and decrement 1 from the entered column.
However, we do not verify if the player has entered, for example,
100,000 as the column number.
Now, we thus have to correct our "joue" function,
making sure that the access to the column here is indeed valid.
We start, as usual, by explaining it
in a comment before coding it.
So, if the "colonne" parameter
is greater than the grid size,
then the entered move is not valid and we can return "false".
We systematically need to check
the access condition to an array cell.
This concludes this episode.
Today, we have added 3 functionalities to our program.
We have asked the player to enter a move.
We have coded the main loop,
making it possible to repeat the game.
And we have alternated between the two players.
Now, we only need, in order to exit the loop,
to define the loop stopping condition -- we left it blank here.
This condition is either that
the grid is full or that a player has won.
This will be the subject of the next episode.
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2019 Coursera Inc. Todos los derechos reservados.
