Au cours de la journée je vais essayer petit à petit de décrire ici les specs de la bête, dans l'état actuel. Sinon pour les impatients, cette page contient déjà un genre de log de l'évolution de l'idée, et il y a une mini-démo ici.
Alors.
Je suis pas particulièrement attaché à l'idée des dossiers, et puis je pense que de toute façon, en faisant un automate vraiment énorme, ce ne serait pas intéressant parce que l'utilisateur attendrait 3 heures pour voir bouger un peu les choses. Donc je laisse tomber cette idée.
Par rapport au système ternaire, ce n'est pas inhabituel du tout d'avoir des cellules pouvant prendre plus de 2 états dans un automate. Par exemple il y en a un assez célèbre (de Von Neumann) qui accepte 29 états. Mais là je pars sur 3 états pour représenter le Yin, le Yang, et le Vide Médian. Un petit côté spirituel.
Dans l'état actuel, il y a maintenant deux fonctions presque similaires. Les deux sont des fonctions de copie / saut, comme décrit dans le post plus haut. Celle qui est activée par un 0 utilise un adressage absolu (relatif au début du secteur), tandis que celle qui est activée par un 1 utilise un adressage relatif (relatif à l'adresse de l'opcode exécutant).
La machine est partitionnée en secteurs, qui sont des segments de mémoire juxtaposés. Les secteurs s'exécutent en parallèle, potentiellement de façon distribuée sur plusieurs machines, et échangent des demandes de transfert d'information. Les demandes sont non-bloquantes, ce qui permet au système de fonctionner malgré les lags, segments inaccessibles (déconnexions), ...etc.
La syntaxe exacte des demandes reste à définir de façon précise. D'une manière générale, ce sont toujours des demandes d'écritures, c'est à dire qu'on demande à une section décrire quelque chose quelque part. Le "quelque chose" qu'il faut écrire est défini soit par l'emplacement où se trouvent les données et leur taille, soit par les données elles-mêmes. Par exemple, on pourrait avoir :
- write( location: 15, size: 10, target: -266 )
- write( content: " 0 11 1 000 1", target: 552 )
- ...etc.
L'attitude à adopter en fonction de la demande est la suivante :
- Si on connaît les données à écrire :
Voilà pour le moment, je ne sais pas si c'est très clair ni très intéressant...
-----
J'ai eu une autre idée. Puisque l'univers est segmenté, le contenu de chaque segment sera sans doute une partie d'une entité ou d'une organisation couvrant de nombreux segments adjacents. Pour proposer au joueur une représentation visuelle des contenus, on peut s'inspirer de la façon dont l'ADN est "lu" par une tête de lecture qui "tricote" les molécules en avançant. Une certaine façon de faire (qui reste à déterminer) pourrait permettre de générer des représentations en 3D, "tricotées" de la même façon, dans un style "Tron" des années 80. Le contenu de chaque segment serait ainsi représenté en 3D, et potentiellement reconnaissable par l'utilisateur.
Niveau scénario, on peut s'inspirer de la richesse du gnosticisme.
Alors.
Je suis pas particulièrement attaché à l'idée des dossiers, et puis je pense que de toute façon, en faisant un automate vraiment énorme, ce ne serait pas intéressant parce que l'utilisateur attendrait 3 heures pour voir bouger un peu les choses. Donc je laisse tomber cette idée.
Par rapport au système ternaire, ce n'est pas inhabituel du tout d'avoir des cellules pouvant prendre plus de 2 états dans un automate. Par exemple il y en a un assez célèbre (de Von Neumann) qui accepte 29 états. Mais là je pars sur 3 états pour représenter le Yin, le Yang, et le Vide Médian. Un petit côté spirituel.
Dans l'état actuel, il y a maintenant deux fonctions presque similaires. Les deux sont des fonctions de copie / saut, comme décrit dans le post plus haut. Celle qui est activée par un 0 utilise un adressage absolu (relatif au début du secteur), tandis que celle qui est activée par un 1 utilise un adressage relatif (relatif à l'adresse de l'opcode exécutant).
La machine est partitionnée en secteurs, qui sont des segments de mémoire juxtaposés. Les secteurs s'exécutent en parallèle, potentiellement de façon distribuée sur plusieurs machines, et échangent des demandes de transfert d'information. Les demandes sont non-bloquantes, ce qui permet au système de fonctionner malgré les lags, segments inaccessibles (déconnexions), ...etc.
La syntaxe exacte des demandes reste à définir de façon précise. D'une manière générale, ce sont toujours des demandes d'écritures, c'est à dire qu'on demande à une section décrire quelque chose quelque part. Le "quelque chose" qu'il faut écrire est défini soit par l'emplacement où se trouvent les données et leur taille, soit par les données elles-mêmes. Par exemple, on pourrait avoir :
- write( location: 15, size: 10, target: -266 )
- write( content: " 0 11 1 000 1", target: 552 )
- ...etc.
L'attitude à adopter en fonction de la demande est la suivante :
- Si on connaît les données à écrire :
- si c'est ici, on les écrit
- si c'est dans un autre segment, on transfert la demande à ce segment
- si c'est ici, on remplace l'adresse et la taille par les données elles-mêmes et on traite la demande
- si c'est dans un autre segment, on transfert la demande à ce segment
Voilà pour le moment, je ne sais pas si c'est très clair ni très intéressant...
-----
J'ai eu une autre idée. Puisque l'univers est segmenté, le contenu de chaque segment sera sans doute une partie d'une entité ou d'une organisation couvrant de nombreux segments adjacents. Pour proposer au joueur une représentation visuelle des contenus, on peut s'inspirer de la façon dont l'ADN est "lu" par une tête de lecture qui "tricote" les molécules en avançant. Une certaine façon de faire (qui reste à déterminer) pourrait permettre de générer des représentations en 3D, "tricotées" de la même façon, dans un style "Tron" des années 80. Le contenu de chaque segment serait ainsi représenté en 3D, et potentiellement reconnaissable par l'utilisateur.
Niveau scénario, on peut s'inspirer de la richesse du gnosticisme.