Puissance 4 : finalisation

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

École Polytechnique Fédérale de Lausanne

Initiation à la programmation (en C++)

224 calificaciones

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.

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é ».

Puissance 4 : introduction10:47

Puissance 4 : premières fonctions20:02

Puissance 4 : fonction joue 1ère version18:22

Puissance 4 : fonction joue variantes et révision8:42

Puissance 4 : moteur de jeu14:14

Puissance 4 : fonctions est_ce_gagne et compte15:51

Puissance 4 : finalisation8:07

Conoce a los instructores

Jean-Cédric Chappelier
Dr.
School of Computer and Communication Sciences
Jamila Sam
Dr
School of Computer and Communication Sciences

Right now, we are nearing the conclusion of

our Connect Four game.

We have managed to let both players play alternatively

and to test if a player has won.

Now, we still have to tweak a little our main program

in order to indicate to our players who has won.

Also, we will have to deal with the draw situation.

This will be the topic of this episode.

As a reminder, our Connect Four game is a struggle

between two players : the player 'X', in charge of the yellow disks

and the player 'O', in charge of the red disks.

These two players play alternatively.

Thus, we have made sure that, after every loop iteration,

the current player's color will alternate between red and yellow.

Both players will keep playing until one of them has won.

We still need to tweak our program a little bit.

The first natural thing to do is, once the loop has finished its execution

-- which means that either one of the two players has won --

is to indeed signify who has won the Connect Four game.

Another thing to do is to consider

the situation where no player has won.

The draw situation is not yet covered by our program;

which does not correspond to a realistic simulation.

Let us now obviate these two holes.

Let us now begin by having

our program indicate who the winner is.

Therefore, after the loop, we will have to add a few instructions,

testing the color of the current player.

If the color of the current player is yellow, for example,

we will print the the winner is the red player.

But, why the red player instead of the yellow player?

Well, remember: at the end of the loop iteration,

we switch the color of the current player.

Therefore, if the current player's color is the yellow color,

that means the winner

is the player with the other color, that is, red.

This means that the red player has indeed won the game

when the current player was the yellow player.

This explains why, in the case where the

color of the current player is yellow,

the winner is indeed the red player.

We will cover the situation where the yellow player has won similarly.

We have thus covered the two possible cases.

Now, we will take the precaution to comment this particular test

indicating that we have first

switched of the players' colors, which

explains the conter-intuitive nature of this test.

Also, as we have said at the beginning of this episode,

there are situations

where both players will be playing

and eventually fill out the whole grid, without anyone having won.

This corresponds to the draw situation.

Consequently, we have to deal with this situation aswell,

thus exiting the loop if one player has won or if

the grid is full.

We thus have to complete our code

so that this case will be covered aswell.

If we do not, the program will behave incorrectly

and keep on looping even once the grid has been filled,

forever asking the same player to indicate a column number where to play.

This does not make sense since the grid is full

and it is not possible to drop disks anymore.

This corresponds to an erroneous situation we have to correct.

The modifications required

in order to solve this problem are rather natural.

Thus, we have to signify that we are iterating,

looping, as long as we do not have a winner

-- this part is already covered -- and as long as the grid is not full.

This can be written this way.

We will be foresseing the existence of a function called "plein" (TN: means "full")

which will test if the grid is full or not.

This will also require a few modifications

after the execution of the loop.

Indeed, at this point,

once we have exited the loop, we will not be confronted with a unique situation anymore

where, fatally, one player has won.

Now, there is another possibility aswell:

a draw which we will have to signal.

Therefore, we will have to modify our program so that

if there is a winner, then we will

find ourselves in the situation where we will signify who has won.

However, this will not always be the case;

it is also possible not to have any winner.

In this second case, we will indicate the game ended in a draw.

Now, we have covered all the possible situations.

Let us now move on to the coding of the "plein" function.

Remember that our program will ask the red and yellow player

in what column they intend to drop their disk.

Let us suppose that it is the yellow player's turn.

If, for example, they decide to drop their disk down the first column,

the filling will occur from bottom to top.

Namely, the disk will be automatically placed

on the first available square, starting from the bottom.

Therefore, in order to test if the grid is full,

we do not need to test all the squares of the grid,

testing if they are occupied by a particular color.

We simply need to test the squares of the very first line.

Indeed, in the case where the grid is full,

we will have filled all the columns starting from the bottom.

This means that all the squares of the first row

will also have been filled.

Now, we should be able to effectively code our "plein" function.

Methodologically speaking, we have briefly wondered,

since it is a rather simple function,

about the "what": what does the "plein" function do?

In the main program, we have planned for this function

to take, as argument, the grid and to test whether it is full or not.

This corresponds naturally to the following prototype:

the function returns a boolean indicating if the grid is full or not.

The only parameter of the function is a grid.

In the previous episodes,

we have seen that, for all the functions having, as parameter,

a rather voluminous object

used only in reading, in consultation,

which we did not want to modify,

it was a good idea to resort to passing by constant reference.

We will do just that here.

Here, the "plein" function aims only to consult the content

of certain squares of the grid in order to know if they are filled or not.

It thus does not aim to modify the grid.

This is precisely the reason why are resorting to

a passage by constant reference here.

Let us now focus on the "how".

How should effectively write the body of this "pleine" function?

We have already sketched the algorithm on the previous slide.

Namely, if we encounter an empty square on the first row,

we know that the grid is not yet full.

This is what we will concretely code.

We will iterate square by square

on the first row, "grille[0]", and test the squares.

If one or more squares are empty, then we know that the grid is not full.

Therefore, the "plein" function will return "false".

Otherwise, obviously, the grid is full

and we will thus return the value "true",

signifying that the grid is full.

Now, we have finished coding our little

Connect Four application.

The goal of this case study was to show you how to tackle

the programming of such an application when we are programming begginers.

Several key ideas are to be remembered.

First of all, always proceed bottom-up.

Start by identifying the essential types,

the fundamental functionalities

before dealing with the details.

Each fundamental function can then, at its turn,

be modularized, call other functions or more details

helping to fulfill the process.

For each function, proceed with methodology.

Ask yourself "what",

what is the role of the funciton in your program?

What informations does it need in order to perform effectively?

What will the function deliver as return information?

Then ask yourself "how"

and consider the algorithm

which will help to realize the desired processing.

Focus on the essential aspects

before dealing with cosmetic tweaking aspects.

Finally, last essential point,

be systematic when testing the different functionalities

as you are progressing in the development of the application program.

Voilà! These were some of the key points

we wished to illustrate through this case study.

We hope they will prove useful to you once you will be facing yourselves

the programming of such applications.

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.

Descargar en la App Store

Consíguelo en Google Play