09-11-2020, 01:09 PM
D'abord merci de te pencher sur mon obscur ... truc.
Je partais du principe que les cellules vivantes seraient "rares" (vraiment entre guillemets) parce que l'espace est infini, mais à bien y réfléchir, c'est pas un critère. Après tout, au bout d'un temps infini, même l'espace infini peut être plein. Mais bon, là on est un peu dans le philosophique donc pas forcément hyper intéressant.
Partons sur du concret.
L'idée d'utiliser des dossiers et sous-dossiers consistait en fait à faire un arbre ; en gros si je ne trouve pas de sous-dossier correspondant à l'adresse que je recherche, je peux arrêter ma traversée parce que je sais qu'à cette adresse, il n'y a que du vide. Plus on fait des gros sous-dossier, plus on va vite, mais plus on gaspille de place. A l'extrême inverse, plus on fait des petits sous-dossiers, plus ça rame, mais par contre les zones vides ne prennent pas de place sur le disque parce qu'elles ne sont tout simplement pas représentées, c'est leur absence qui indique leur valeur.
De toute façon ça reste une procédure très lente effectivement, parce que comme tu dis, le processeur doit se farcir toutes les adresses une par une pour trouver les arguments d'une fonction. En fait je vais être plus précis pour qu'on sache bien de quoi on parle.
On peut représenter l'univers avec une string contenant des caractères espace, 1 et 0. Un 1 entouré d'espace est interprété comme un opcode (l'unique opcode). Une commande complète pourrait être
" 1 0100 110 11000 11 "
Le premier bit est le signe, on est en little-endian, donc on a comme arguments -4, +2, +8, +1, ce qui veut dire "copie la zone commençant à l'adresse -4 et de taille 2, colle-la à l'adresse +8 et créé un 1 à l'adresse +1". Le premier 1 entouré d'espace (l'opcode) est transformé en espace après exécution.
Le système parcourt la mémoire de gauche à droite et réagit à chaque fois qu'il trouve un 1 isolé. Cette description, c'est celle d'une variante du système, j'ai fait beaucoup de variantes en fait. Mais les problèmes se posent toujours un peu à chaque fois.
A partir de là, il y a deux types de jeuweb qu'on peut faire : un jeu "roleplay", et un jeu "automate cellulaire".
Dans le jeu "roleplay", il s'agit d'incarner une entité vivant dans cet univers. Ce qu'on y fait, je ne sais pas encore ce que ça peut être, mais en tout cas le but n'est pas de simuler réellement l'automate cellulaire, mais plutôt de simuler l'univers directement dans sa version "haut niveau", c'est à dire que les joueur évolue dans un monde d'objets, d'entités comme lui, de véhicules, de cités, ...etc. Commerce, traquenards, guerres, la totale. C'est un jeu classique, pas de technologie particulière, mais on a besoin de connaître les propriétés exactes du milieu pour que l'histoire soit crédible (par exemple, est-il possible, avec le véhicule adapté, de se "téléporter" à n'importe quel endroit de l'univers ? si oui, doit-on procéder par "sauts" successifs ? ...etc).
Dans le jeu "automate cellulaire" qu'on pourrait en faire, il s'agit bien de simuler l'univers et donc plutôt de "jouer à dieu" en quelque sorte, c'est à dire élever des entités, les faire évoluer, les partager, ...etc. Dans ce cas, idéalement on aurait un univers réel partagé, sans doute hébergé sur le serveur, soit en flat file soit dans une MySQL ou similaire... ou alors, autre option plus moderne, un réseau peer2peer où chaque joueur a un nœud qui représente un segment de l'univers (qui ne tourne que quand le joueur est connecté). Il faut alors faire passer les infos en lecture / écriture d'un nœud à l'autre et là c'est pas de la tartiflette !
Donc pour résumer,
- deux options pour un projet Jeuweb basé là-dessus,
- je me trompais en disant que la plupart des cellules étaient vides (c'est pas forcément le cas),
- dans tous les cas, il faut une grosse connectivité entre les postes des joueurs,
- les "règles" d'évolution de l'univers sont loin d'être figées, elles me posent notamment des problèmes de stabilité (pour que des entités évoluées apparaissent, les copies de taille énorme à distance énorme posent un problème de design mal foutu à vrai dire, je suis en train de bosser sur la question).
Je partais du principe que les cellules vivantes seraient "rares" (vraiment entre guillemets) parce que l'espace est infini, mais à bien y réfléchir, c'est pas un critère. Après tout, au bout d'un temps infini, même l'espace infini peut être plein. Mais bon, là on est un peu dans le philosophique donc pas forcément hyper intéressant.
Partons sur du concret.
L'idée d'utiliser des dossiers et sous-dossiers consistait en fait à faire un arbre ; en gros si je ne trouve pas de sous-dossier correspondant à l'adresse que je recherche, je peux arrêter ma traversée parce que je sais qu'à cette adresse, il n'y a que du vide. Plus on fait des gros sous-dossier, plus on va vite, mais plus on gaspille de place. A l'extrême inverse, plus on fait des petits sous-dossiers, plus ça rame, mais par contre les zones vides ne prennent pas de place sur le disque parce qu'elles ne sont tout simplement pas représentées, c'est leur absence qui indique leur valeur.
De toute façon ça reste une procédure très lente effectivement, parce que comme tu dis, le processeur doit se farcir toutes les adresses une par une pour trouver les arguments d'une fonction. En fait je vais être plus précis pour qu'on sache bien de quoi on parle.
On peut représenter l'univers avec une string contenant des caractères espace, 1 et 0. Un 1 entouré d'espace est interprété comme un opcode (l'unique opcode). Une commande complète pourrait être
" 1 0100 110 11000 11 "
Le premier bit est le signe, on est en little-endian, donc on a comme arguments -4, +2, +8, +1, ce qui veut dire "copie la zone commençant à l'adresse -4 et de taille 2, colle-la à l'adresse +8 et créé un 1 à l'adresse +1". Le premier 1 entouré d'espace (l'opcode) est transformé en espace après exécution.
Le système parcourt la mémoire de gauche à droite et réagit à chaque fois qu'il trouve un 1 isolé. Cette description, c'est celle d'une variante du système, j'ai fait beaucoup de variantes en fait. Mais les problèmes se posent toujours un peu à chaque fois.
A partir de là, il y a deux types de jeuweb qu'on peut faire : un jeu "roleplay", et un jeu "automate cellulaire".
Dans le jeu "roleplay", il s'agit d'incarner une entité vivant dans cet univers. Ce qu'on y fait, je ne sais pas encore ce que ça peut être, mais en tout cas le but n'est pas de simuler réellement l'automate cellulaire, mais plutôt de simuler l'univers directement dans sa version "haut niveau", c'est à dire que les joueur évolue dans un monde d'objets, d'entités comme lui, de véhicules, de cités, ...etc. Commerce, traquenards, guerres, la totale. C'est un jeu classique, pas de technologie particulière, mais on a besoin de connaître les propriétés exactes du milieu pour que l'histoire soit crédible (par exemple, est-il possible, avec le véhicule adapté, de se "téléporter" à n'importe quel endroit de l'univers ? si oui, doit-on procéder par "sauts" successifs ? ...etc).
Dans le jeu "automate cellulaire" qu'on pourrait en faire, il s'agit bien de simuler l'univers et donc plutôt de "jouer à dieu" en quelque sorte, c'est à dire élever des entités, les faire évoluer, les partager, ...etc. Dans ce cas, idéalement on aurait un univers réel partagé, sans doute hébergé sur le serveur, soit en flat file soit dans une MySQL ou similaire... ou alors, autre option plus moderne, un réseau peer2peer où chaque joueur a un nœud qui représente un segment de l'univers (qui ne tourne que quand le joueur est connecté). Il faut alors faire passer les infos en lecture / écriture d'un nœud à l'autre et là c'est pas de la tartiflette !
Donc pour résumer,
- deux options pour un projet Jeuweb basé là-dessus,
- je me trompais en disant que la plupart des cellules étaient vides (c'est pas forcément le cas),
- dans tous les cas, il faut une grosse connectivité entre les postes des joueurs,
- les "règles" d'évolution de l'univers sont loin d'être figées, elles me posent notamment des problèmes de stabilité (pour que des entités évoluées apparaissent, les copies de taille énorme à distance énorme posent un problème de design mal foutu à vrai dire, je suis en train de bosser sur la question).