Skip to main content

JeuDeLaVie - 1.1

Yet another (Python+PyGame) implementation of John Horton Conway's Game of Life


Hubert Tournier
(HubTou)
The game of Life is a cellular automaton simulation. In this implementation you can: Configure in a file the language to be used (French or English), set cells screen width, cells evolution speed and game's rule. Edit the initial pattern, load it from an internal library, load it from a third party pattern collection (with 1500+ files), auto-save it before launch and restore last pattern used, load one of your files, etc. Launch the simulation with a lot of counters (generation, population, min, max, births, survival, deaths, etc.) and pace setting functions

Changes

The new version includes the following changes: - CORRECTION: Corrected a bug when using File mode before the creation of the backup directory or the first file inside - CORRECTION: Corrected a bug with PlainText files loading (empty lines instead of dot filled lines) - CORRECTION: Correction a bug with RunLengthEncoded files loading (multiplicator before the "$" character) - NEW FEATURE: Automatic download and install of LifeWiki's pattern collection - NEW FEATURE: Measuring evolution cycle duration and displaying it on the console in DEBUG mode - OPTIMIZATION: Use integers when comparing the number of cell neighbours with the birth/survival rule - OPTIMIZATION: Evolve or crop only the useful part of the game grid - PRESENTATION: Improve PEP8 compliance
pygame 843 2d 784 game 396 python 342 retro 98 simulation 55

Links

Home Page
https://github.com/HubTou/JeuDeLaVie
Source
https://github.com/HubTou/JeuDeLaVie
Windows
https://github.com/HubTou/JeuDeLaVie
Mac
https://github.com/HubTou/JeuDeLaVie
Github repo
https://github.com/HubTou/JeuDeLaVie

Releases

JeuDeLaVie 1.0 — 8 May, 2020

JeuDeLaVie 1.1 — 16 May, 2020

Pygame.org account Comments

  • jo 2020-05-10 14:40

    très lent, besoin d'optimisations.

    Hubert Tournier 2020-05-10 20:18

    Tu peux aussi mettre CYCLE_DE_VIE = 1 dans le fichier de configuration. Sinon la valeur par défaut est d’une évolution tous les 250 ticks d’horloge

    jo 2020-05-11 11:59

    c'est l'algo qui pèche.

    Hubert Tournier 2020-05-16 13:53

    Pour ce qui me concerne les performances ont toujours été correctes sur les machines où j'ai fait tourner ce programme. J'ai cependant chargé une nouvelle version avec 2 optimisations et une fonctionnalité permettant de mesurer le temps de cycle (entre 4 et 12 centièmes de secondes chez moi), mais normalement cela ne devrait pas changer grand chose à la vitesse ressentie car le programme passe son temps à attendre le prochain cycle de vie en multiples de ticks d'horloge... Pour aller plus vite, il faudrait soit le recaler sur un multiple de centièmes de secondes, soit renoncer à la possibilité d'avoir plusieurs règles (type B3/S23 et autres), soit implémenter un algo type HashLife (pas ce que je souhaitais faire), soit augmenter la taille des cases via le fichier de configuration... Le code source est sur GitHub, tu es le bienvenu si tu souhaites faire des modifs

    Hubert Tournier 2020-05-10 18:24

    Tu as essayé la touche + pour accélérer le rythme d’évolution ?

    jo 2020-06-18 15:16

    j'en avais fait un il y a longtemps. L'algo avait même était repris sur un autre projet ici. ça démarre en pause. pour dessiner: maintien barre espace + maintien clic droit pause/reprise: p zoom/dézoom sur le curseur: molette déplacer le carte: maintien clic droit + bouger souris https://drive.google.com/file/d/1m5s0ENOMl8NlubWH5tFwPLnynQGU-UX3/view?usp=sharing c'est quoi un algo hashlife ?

    Hubert Tournier 2020-06-22 08:19

    Tu as une description de l'algorithme là : https://www.conwaylife.com/wiki/HashLife https://web.archive.org/web/20120719224016/http://www.drdobbs.com/jvm/an-algorithm-for-compressing-space-and-t/184406478 Pour le principe, aujourd'hui j'ai implémenté le terrain de jeu sous forme de matrice, avec donc un terrain de jeu fini et avec bordures. Si je voulais rendre le terrain de jeu infini, je ne pourrais plus faire cela pour des raisons de temps de calcul et de stockage mémoire. Il ne faudrait plus représenter le terrain sous forme de matrice, mais plutôt comme une liste de zones où il se passe quelque chose (zones séparées d'au moins 2 cases vides) avec un système de coordonnées absolu (de -x/-y à +x/+y). Quand tu commences à faire cela, tu te rends rapidement compte qu'il n'est pas nécessaire de tout recalculer à chaque fois. Les structures stables ("natures mortes") n'ont plus besoin d'être recalculées, et les structures cycliques peuvent être pré-calculées et leur état montré seulement s'il apparaît à l'écran. Pour reconnaître ces structures, tu peux implémenter un algorithme de hachage ("hash" en anglais) qui va permettre de reconnaître ces structures stables ou cycliques. La liste des zones pourra donc être séparée en structures stables, cycliques et "autres", où seules ces dernières nécessiteront un calcul au tour par tour. Il faut ensuite implémenter un algorithme qui détecte les collisions entre zones et le fait qu'une structure "autre" devienne stable ou cyclique. Du coup, il faut conserver pour chaque zone "autre" une liste des valeurs de hachage qui permettra de détecter de nouvelles structures cycliques, au-delà de celles qui pourraient être initialement référencées. Pour en revenir à HashLife, ils calculent ces valeurs de hachage non pas sur des zones de taille arbitraire, mais en les découpant en zones de 4 ou 4x4 cellules.