Big Tuto on OOP & MVC with the Game Of Life

Bon autant te le dire tout de suite, le jeu de la vie, ce n'est pas mon truc, mais par contre bravo. Quel boulot sur le tuto... J'ai vu une petite erreur dans le graphique de "Calcul du voisinage", il est écrit i différent de 0 ou j différent de 0 alors que c'est et à la place du ou (d'ailleurs c'est bien marqué dans le texte en dessous) par contre c'est faux dans le programme d'exemple (c'est un ou de marqué alors que ça devrait être un et).

J'ai regard rapidement le reste car je vais me faire à manger mais le reste me parait très bien et quel beau tuto. Bien divisé en chapitre, très clair. En fait je pense que les tuto de la META devrais un peu s'inspirer des tiens pour la lisibilité et l’enchaînement. Je trouve la navigation dan les tutos beaucoup plus intuitive sur ton site. Si tu veux intégrer les miens à ta sauce, fais toi plaisir. 

Donc, bon le programme d'exemple, désolé, ce n'est pas mon truc mais les tutos, j'adore et j'espère que tu va continuer à en faire.  :)

Merci pour ton commentaire fort sympathique. C'est très encourageant ! La rédaction m'a en effet demandé pas mal de boulot et je commençais à être impatient de voir le bout du tunnel...

Concernant ta remarque au sujet  d'une petite erreur que tu aurais relevée concernant le calcul du voisinage d'une cellule, et bien... j'en conclue que ma figure n'est pas assez claire. Je la referai donc demain (à La Réunion il est déjà 1:00 du matin passée et je dois me lever tôt demain pour aller bosser).

Il ne s'agit pas d'une erreur ! Le voisinage d'une cellule est bien défini par :

grid[x+j][y+i] lorsque i ∈ [-1,1] et j ∈ [-1,1] et que (i ≠ 0) OU (j ≠ 0)

Le cas où (i=0) ET (j=0) concerne la cellule centrale qui ne fait donc pas partie du voisinage ;-)

Je n'ai pas dû être assez clair (ou tu as lu trop vite ?)... je reformulerai ce passage demain.

Concernant la mise en page des tutos du site officiel, effectivement, je trouve qu'elle n'est pas mise en valeur et les contenus sont difficilement appréciables sous cette forme. C'est pourquoi j'ai préféré publier le mien sur un site perso, où je maîtrise la feuille de styles et la navigation :-)

Pour terminer, je conçois que le Jeu de la Vie ne passionne pas tout le monde. Néanmoins, dans le cadre de ce tuto, il ne faut pas le considérer en tant que tel, mais plutôt l'envisager comme une base pédagogique abordable par sa simplicité, et qui permet d'illustrer de nombreux concepts de programmation intéressants (voire fondamentaux) sans se heurter à la difficulté intrinsèque d'un cas d'étude plus complexe.

Encore merci pour ton commentaire !

Hum, je ne comprends pas en effet. Si i=0 et j=-1 par exemple, la cellule fais bien partie du voisinage. Seul le cas ou i=0 et j=0 est à exclure du voisinage. Enfin c'est ce que je comprends moi. Donc le voisinage est i ∈ [-1,1] et j ∈ [-1,1] et i,j ≠ (0,0) soit i≠0 et j≠0. Si i=-1 ou 1 et j=0, la cellule fais bien partie du voisinage.

Si oui, je comprends tout à fais la base pédagogique et ça, c'est très bien fait et en effet, c'est un cas qui permet de bien illustrer différentes choses au travers des différents chapitre.

Hi hi ... décidément...

Hum, je ne comprends pas en effet. Si i=0 et j=-1 par exemple, la cellule fais bien partie du voisinage. Seul le cas ou i=0 et j=0 est à exclure du voisinage. Enfin c'est ce que je comprends moi.

Tout à fait ! Le cas "i=0 ET j=-1" fait bien partie des cas où "i≠0 OU j≠0"

Seul le cas ou i=0 et j=0 est à exclure du voisinage. Enfin c'est ce que je comprends moi.

C'est exactement ça.

Donc le voisinage est i ∈ [-1,1] et j ∈ [-1,1] et i,j ≠ (0,0) soit i≠0 et j≠0.

Et non justement... (i,j) ≠ (0,0) <=> ! [i=0 ET j=0] <=> i≠0 OU j≠0 ;-)

Bon je n'insiste pas, c'est peut être moi qui me trompe mais si je suis d'accord avec ! [i=0 ET j=0] pour moi, le résultat est différent de i≠0 OU j≠0 ou du coup tu exclues la ligne i=0 et la colonne j=0 donc tu exclues 5 cases au lieu d'une selon moi dont la centrale mais aussi 4 autres. 

Je t'assure que non !... simple règle de logique :

NON(A ET B) = NON(A) OU NON(B)

ok, oui, il faut bien A=0 et B=0 pour avoir un résultat à 0, sinon on a 1, c'est vrai. Désolé, je dois être fatigué sans doute, mais oui, c'est vrai...

Très bon tutoriel !

Tu as très bien décrit la POO et le MVC, c'est un bon complément à ce que j'ai écris. Je pense d'ailleurs que je vais ajouter un lien vers ton tutoriel.

Je pense que pour le framework que j'écris je vais m'inspirer de tes effets de lumières.

J'ai repéré deux petites coquilles, dans la partie "son et lumière", dans le dernier exemple de code :

• tu indique qu'il s'agit du fichier GameController.h mais je pense qu'il s'agit du .cpp.
• et pour la dernière méthode de cette classe tu as écrit le commentaire suivant "// idem lrosqu'il sort du mode édition :".

Merci pour ton commentaire ! Je viens de corriger les coquilles :-)

Je pense effectivement que, pour les  apprenants, tes tutos et celui-ci constituent une bonne base pour se lancer dans la POO et l'architecture MVC. Ils ont tout à y gagner lorsque l'application prend de l'ampleur...

Concernant les lumières, oui, c'est plus facile de gérer ça dans un contrôleur dédié... et surtout... dans le référentiel HSL ! J'ai d'ailleurs suggéré à Soru (sur Discord) d'ajouter les fonctions rgb2hsl et hsl2rgb dans l'API de la bibliothèque officielle.

Par rapport à mon dépôt j'ai fait une branche qui restera la même pour toujours comme ça je peux faire des changements ^^

https://github.com/sautax/game-of-life-gamebuino/tree/0.4

C'est incroyable! Le tuto est trés complet, et il a connaissance beaucoup pour moi apprendre C++ sur la Gamebuino. Je ne parle pas français bien, mais je comprende assez de français essayer lire le tuto en français. Merci beaucoup pour vos poste!

Merci sautax ! C'est très sympathique de ta part. Je pousserai la mise à jour du lien vers la bonne branche de ton dépôt dès ce soir.

Edit: c'est fait :-)

MERCI steph :D

Une petite question : je vais essayer d'utiliser cette méthode pour créer un clone de Breakout, du coup la logique est d'avoir un MVC pour chaque élément ? (ex. Pad, PadView, PadController, Ball, BallView, BallController etc. ?)

Merci d'avance ! :)

Edit : Après avoir essayé j'imagine que ce n'est pas la bonne méthode, je suis un peu perdu :/

Merci pour tes commentaires YQN :-)

Désolé pour le délai de réponse... mais quelques impondérables m'empêchent actuellement d'être très présent auprès de la communauté.

Pour répondre à ta question... il ne faut pas considérer que l'architecture MVC est la solution idéale qui s'applique à tous les cas de figures que tu vas rencontrer lorsque tu vas chercher à organiser ton code ! Loin de là ! Il est tout à fait inutile d'employer un marteau-piqueur pour enfoncer une punaise ;-) Cette architecture se prête très bien à la modularisation des composants de ton code lorsque celui-ci se complexifie. Il en facilite l'organisation et la compréhension en séparant bien la logique qui les articule. L'architecture que je propose dans le Jeu de la Vie en illustre la plupart des aspects. Mais vouloir à tout prix adopter cette organisation peut, au contraire, alourdir ton code et s'avérer parfaitement inutile. Dans des cas simples comme la gestion d'un paddle dans un jeu de casse-briques, le modèle et la vue peuvent être rassemblés au sein d'un même et unique composant (Paddle). Un contrôleur des événements utilisateurs (pour intercepter l'appui sur les boutons de la console) sera par contre très utile pour isoler la gestion de ce type d'interactions dans ton code. Le contrôleur pourra alors ensuite agir directement sur ton composant Paddle en le déplaçant (c'est-à-dire en envoyant un ordre ayant pour effet de modifier sa coordonnée selon l'axe horizontal). Et lorsque ce sera le moment (prévoir un point d'entrée à partir de la boucle de contrôle global loop), ce même Paddle pourra simplement se dessiner en fonction de ses coordonnées (qui représentent finalement son modèle). Il sera, à lui seul, son modèle et sa vue...

Est-ce que j'ai répondu à ta question ?