Je bosse actuellement sur un jeu de la vie en ncurses. J'ai un soucie algorithmique : je n'arrive pas a gérer la sortie des modèles qui "bougent".
Par exemple le planeur, qui est amené a sortir de la map. Quand mes planeurs arrivent en bordure il bloquent en un pattern stable (carré de 2x2), alors qu'il devrait garder le cap et sortir de l'écran.
Je n'arrive pas a concevoir l'algo qui gérerait ces cas. Avez-vous une idée ?
J'ai un soucie algorithmique : je n'arrive pas a gérer la sortie des modèles qui "bougent". Quand mes planeurs arrivent en bordure il bloquent en un pattern stable (carré de 2x2), alors qu'il devrait garder le cap et sortir de l'écran.
Je n'arrive pas a concevoir l'algo qui gérerait ces cas. Avez-vous une idée ?
Pour être plus claire, je stock dans un char** la "map". Celle-ci contient donc des "0" et des "1" qui sont respectivement les cellules mortes et les cellules vivantes au cycle 0. Quand je lance le programme, les cellules évoluent donc selon les règles du jeu de la vie de John Conway :
1) Si une cellule a exactement trois voisines vivantes, elle est vivante à l’étape suivante.
2) Si une cellule a exactement deux voisines vivantes, elle reste dans son état actuel à l’étape suivante.
3) Si une cellule a strictement moins de deux ou strictement plus de trois voisines vivantes, elle est morte à l’étape suivante.
L'affichage dans ma console de ma map, est donc limité à la taille du tableau préalablement renseigné. Se que je souhaite c'est que les bords de cette fenêtre d'affichage ne soit pas des limites pour les cellules vivantes qui compose ma map. Lorsqu'un pattern mobile est présent dans la map et que celui ci est amené a sortir de l'écran je voudrais qu'il continu sa route dans sa direction sans qu'il se bloque arrivé aux extrémités.
- Le plus simple: tu fais un tableau plus grand que l'écran. De cette façon les cellules vivantes/figées en dehors de l'écran ne se verront plus (il te faut alors tuer manuellement les cellules hors de l'écran
- Le plus compliqué: soit au lieu de baser ton algo sur un tableau représentant la surface de jeu, tu considères une liste de cellules vivantes
struct cellule
{
int x,y;
}
les calculs sont alors plus compliqués car pour une cellule donnée il faut parcourir la liste pour savoir combien elle a de voisines. Mais de cette façon, une cellule vivra même en sortant des limites de l'écran! En amélioration, tu pourrais alors faire une sorte de scrolling pour voir comment les choses évolue en dehors de la zone d'affichage initial.
** La doc, c'est comme le PQ: ça sert à se démerder tout seul **
J'avais pensé à la première solution mais je la trouve carrément bullshit :/
La deuxième solution est pas mal intéressante et elle ne complique pas tellement l'algo finalement ! Je vais surement me plonger la dedans surtout que ça va m'aider pour mon projet par la suite !
Je me penche là dessus et je reviens vers toi si j'ai des soucis
- Le plus compliqué: soit au lieu de baser ton algo sur un tableau représentant la surface de jeu, tu considères une liste de cellules vivantes
Petite précision: dans ce cas, pour limiter le temps de recherche des voisins, il vaut mieux que la liste soient triée sur au moins une composante (x ou y)
** La doc, c'est comme le PQ: ça sert à se démerder tout seul **
Une liste triée, ça ne va pas aller pour insérer/retirer, qui va être une opération extrêmement fréquente dans la représentation du plateau du jeu de la vie.
Dans ce cas, une structure à base d'arbre binaire ou de table de hachage semble nettement plus indiquée.
Plus simplement, si c'est le jeu de la vie alors le terrain peut être le jeu du monde et lier les bords, ce qui sort à droite revient par la gauche (en haut en bas...), un peut comme dans la réalité, si tu pars à l'Est, tu arrives par l'Ouest... Bon Ok, on va m'objecter que si tu pars au Nord, tu reviens par le Nord , mais ça me semble tout de suite plus simple à implémenter que de partir dans des arbres binaires et autres tables de hachage versus une bête comparaison de cases adjacentes sur modulo dans un tableau.
Plus simplement, si c'est le jeu de la vie alors le terrain peut être le jeu du monde et lier les bords, ce qui sort à droite revient par la gauche (en haut en bas...), un peut comme dans la réalité, si tu pars à l'Est, tu arrives par l'Ouest... Bon Ok, on va m'objecter que si tu pars au Nord, tu reviens par le Nord , mais ça me semble tout de suite plus simple à implémenter que de partir dans des arbres binaires et autres tables de hachage versus une bête comparaison de cases adjacentes sur modulo dans un tableau.
Bonne continuation.
L'ennui de cette proposition, c'est que quelque chose qui s'eloigne va se remettre a interagir avec des motifs stables qui sont resté au centre!
(Bon cela peut peut être finir par créer des interactions sympas, mais bon, c'est pas les règles du jdlv)
** La doc, c'est comme le PQ: ça sert à se démerder tout seul **
En effet, la demande de l'OP semble plutot concerner un espace 2D potentiellement infini, plutot qu'un tore (ça se fait aussi, mais c'est une autre histoire).
> je voudrais qu'il continu sa route dans sa direction sans qu'il se bloque arrivé aux extrémités.
ça veut dire : pas d'extrémités.
- Edité par michelbillaud 25 février 2018 à 22:04:50
il existe en effet quelques millions de programmes qui font ça, depuis les années 60.
[C] Game of life
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Bonhomme !! | Jeu de plateforme : Prototype.