Le jeu incrémental devient physique : quand votre ASIC travaille vraiment

État de la publication : DCENT_Pool est en préparation pour sa diffusion publique. Suivez ou inspectez la destination GitHub de DCENT_Pool pour connaître l'état de la version. Ne supposez pas que le code complet du pool, du jeu, du tableau de bord ou la documentation d'auto-hébergement sont publics avant de les y voir.

Un bon jeu incrémental ne demande pas une attention constante. Il demande de prendre quelques décisions importantes, de laisser un système fonctionner, puis de revenir pour comprendre ce qui s'est produit.

On choisit une construction. On ajuste une priorité. On découvre un goulot d'étranglement. On ferme le jeu. Plus tard, on revient devant un résultat, on modifie la stratégie et on recommence.

Cette boucle — choisir, laisser fonctionner, constater, optimiser — explique pourquoi le public des jeux incrémentaux, souvent appelés idle games, pourrait être le premier public de joueurs à saisir DCENT_Pool.

DCENT_Pool est conçu comme un MMORPP — Massively Multiplayer Online Role-Playing Pool. Une personne choisit l'intention de son personnage ou de son groupe. Un véritable mineur Bitcoin de type ASIC fournit l'effort continu. Le pool valide le travail soumis. Les blocs Bitcoin font avancer l'horloge d'un monde persistant.

La ressemblance avec un jeu incrémental est évidente. La différence est radicale :

La production n'est pas simulée.

Une boucle connue, avec une machine réelle au centre

Le vocabulaire des jeux incrémentaux tourne autour de l'automatisation, de l'optimisation, de la progression pendant l'absence, de la gestion de ressources, des constructions, des boss et des systèmes qui se dévoilent graduellement.

Le MMORPP peut reprendre cette cadence humaine tout en changeant la source de l'effort :

1. Choisir une intention. Indiquer que le prochain travail admissible doit servir à explorer, bâtir, défendre, attaquer, se déplacer, effectuer une recherche ou soutenir un objectif de guilde.
2. Laisser l'appareil fonctionner. L'ASIC calcule des hachages et soumet des résultats au pool.
3. Valider le travail. Le pool accepte ou rejette les shares selon la tâche, la difficulté et les règles actives.
4. Appliquer une mécanique de jeu. Le travail accepté et normalisé peut alimenter l'objectif fictif choisi.
5. Faire avancer le monde. Les nouveaux blocs Bitcoin déclenchent les ticks prévus par les règles.
6. Revenir constater. L'interface montre ce qui s'est passé et permet de remonter de l'histoire fictive vers les preuves du pool.
7. Optimiser. La personne change d'objectif, améliore la stabilité, coordonne son groupe ou choisit un autre compromis entre coût et contribution.

Le joueur n'a évidemment pas à cliquer pour chaque hachage. Un ASIC effectue une quantité gigantesque de tentatives chaque seconde. Le rôle humain est de donner une direction, pas d'imiter la machine.

Progression hors ligne ou progression sans surveillance?

Les deux expressions ne veulent pas dire la même chose.

Dans plusieurs jeux incrémentaux, le serveur ou l'application calcule une progression hors ligne lorsque la personne revient. Il connaît la durée de l'absence et simule ce que le système aurait produit.

Pour DCENT_Pool, cette traduction serait trompeuse si elle concerne le travail de minage.

Si le tableau de bord est fermé, mais que le mineur demeure alimenté, connecté et en train de soumettre du travail admissible, la contribution peut continuer. La personne est absente; la machine ne l'est pas.

Si le mineur était éteint, en surchauffe, déconnecté ou incapable de soumettre une share valide, il n'existe aucun travail minier à recréer. Le royaume ne devrait pas attribuer après coup une production imaginaire.

La bonne expression est donc progression sans surveillance appuyée par du matériel.

Cette nuance devrait apparaître dans chaque titre, description de fonction et écran de retour. Elle empêche de confondre :

• un tableau de bord fermé;
• un mineur hors ligne;
• un mineur connecté qui ne produit que des rejets;
• un mineur qui fournit réellement des shares acceptées.

La fiction doit respecter la différence.

Le matériel transforme les statistiques en contraintes

Dans un jeu incrémental traditionnel, le concepteur peut modifier une vitesse de production en changeant un nombre dans le logiciel. Dans DCENT_Pool, une partie du débit appartient au monde physique.

La disponibilité est le temps réel pendant lequel l'appareil fonctionne correctement.
Le taux de hachage est une capacité mesurée, pas un attribut acheté dans une boutique.
L'efficacité relie une quantité de travail à une consommation électrique réelle.
La chaleur doit être évacuée ou récupérée.
Le bruit existe dans la pièce, pas seulement dans les options audio.
Une panne réseau interrompt la soumission, même si le personnage est prêt à agir.

Ces contraintes rapprochent aussi le projet des jeux de gestion et d'automatisation. Le plaisir peut venir de l'observation d'un système, de la recherche d'un goulot d'étranglement et de l'amélioration d'une configuration — sauf que le système se trouve sur une étagère, dans un atelier ou dans une salle mécanique.

Cette réalité interdit certaines facilités de marketing. On ne peut pas promettre une progression « gratuite ». On ne peut pas parler de revenu passif. On ne peut pas cacher l'électricité, le prix du matériel, le refroidissement ou l'entretien derrière un univers coloré.

Le coût est une partie de la contrainte, pas une note de bas de page.

La machine participe à deux systèmes séparés

Pendant qu'il fonctionne, l'ASIC participe à la fois au minage Bitcoin et à une interprétation fictive du travail accepté. Ces deux systèmes se touchent sans devenir identiques.

Sur le plan Bitcoin

Chaque hachage est une tentative de produire un résultat sous la cible du réseau. Plus de taux de hachage signifie plus de tentatives par seconde. Cela augmente la probabilité sur une période, sans créer de garantie.

Sur le plan du pool

Le pool utilise une cible de share plus facile pour mesurer régulièrement le travail. Une share acceptée est un résultat qui respecte cette cible et les autres règles de validation. La documentation pour développeurs Bitcoin explique que les shares permettent d'estimer le travail fourni même lorsqu'elles n'atteignent pas la cible du réseau.

Sur le plan fictif

Le travail admissible peut faire progresser une construction, un déplacement, une défense ou un combat selon une règle de jeu publiée.

Une share acceptée n'est donc pas un petit morceau de bloc. Elle ne remplit pas une barre de paiement. Une action fictive ne rend pas le prochain hachage plus chanceux. Et un boss vaincu ne produit pas une récompense Bitcoin.

La couche ludique peut donner une rétroaction fréquente. Elle ne doit jamais fabriquer une proximité monétaire qui n'existe pas.

Une horloge irrégulière change le jeu d'attente

Dans un jeu incrémental, une construction peut annoncer « terminée dans 40 minutes ». Dans le monde de DCENT_Pool, les événements fondamentaux peuvent être exprimés en blocs : « terminée après quatre nouveaux blocs Bitcoin ».

Bitcoin vise un nouveau bloc environ toutes les dix minutes en moyenne à l'échelle du réseau, comme l'explique la FAQ française de Bitcoin.org. Le prochain bloc peut toutefois arriver beaucoup plus tôt ou beaucoup plus tard.

Cette irrégularité donne un caractère différent à l'attente :

• une durée peut être estimée, mais pas promise à la minute;
• D-Central ne contrôle pas le prochain battement;
• tous les joueurs voient le même progrès de hauteur de bloc;
• le monde avance même lorsque le bloc a été trouvé ailleurs sur le réseau;
• un tick du monde n'est pas un paiement du pool.

L'horloge n'est pas une minuterie de récompense. Elle est un repère public pour la simulation.

Un jeu incrémental multijoueur, pas seulement un compteur personnel

Beaucoup de jeux incrémentaux sont des problèmes d'optimisation privés. On améliore son propre moteur de production sans transformer le monde des autres.

Le MMORPP peut rendre la contribution sans surveillance sociale.

Une guilde pourrait soutenir un chantier commun. Des personnes pourraient choisir des rôles d'exploration, de logistique, de défense ou de combat. Une petite machine très stable pourrait maintenir un effort régulier pendant qu'une installation plus puissante interviendrait sur une fenêtre courte. Un groupe pourrait coordonner ses intentions autour de la hauteur de bloc plutôt que d'exiger que tout le monde soit devant l'écran en même temps.

La promesse sociale n'est pas « tout le monde regarde le même chiffre monter ». C'est : des machines exploitées séparément peuvent laisser des traces dans une histoire commune.

Cette proposition doit toutefois être reliée à un état de version. Une guilde décrite dans un document de conception n'est pas nécessairement disponible dans le produit public. Au moment de publier et après chaque version importante, chaque mécanique doit porter l'étiquette en production, en cours d'essai, prototype ou sur la feuille de route.

Progresser sans recommencer le monde

Les jeux incrémentaux utilisent souvent le prestige : on efface une partie de la progression pour obtenir un multiplicateur et accélérer le prochain cycle.

DCENT_Pool vise un monde persistant qui ne remet pas son histoire à zéro. Des fenêtres de classement peuvent se terminer. Une renommée récente peut décroître. Des routes peuvent s'user. Des structures peuvent devenir des ruines. Mais le monde conserve la trace de ce qui s'est produit.

Pour un système alimenté par un effort physique, cette permanence a un poids particulier. Une machine a consommé de l'énergie et fourni un travail vérifié. Le monde peut changer la valeur stratégique de son résultat, mais il ne devrait pas prétendre que le résultat n'a jamais existé.

Le choix crée aussi un problème : comment permettre à une nouvelle personne de compter dans un monde ancien?

Les réponses possibles comprennent de nouvelles frontières, l'entretien, les catastrophes, les rôles spécialisés, la décroissance de certains avantages et des classements récents qui n'effacent pas le registre historique. « Sans remise à zéro » n'est pas une solution automatique. C'est une responsabilité de conception.

La stratégie ne peut pas se limiter à acheter plus de puissance

Le taux de hachage doit compter, puisqu'il représente une différence physique réelle. Mais si chaque résultat fictif appartient toujours à la plus grande installation, le monde devient un simple classement de matériel.

Un jeu profond peut donner du poids à d'autres décisions :

• disponibilité : contribuer régulièrement sur un grand nombre de blocs;
• moment : appliquer le travail avant une résolution importante;
• information : explorer et révéler une route ou un danger;
• logistique : faire arriver une contribution au bon endroit;
• spécialisation : choisir des objectifs complémentaires;
• coordination : éviter que les membres d'une guilde reproduisent le même effort;
• géographie : accepter que la distance et le terrain limitent la puissance brute;
• efficacité : chercher un meilleur rapport entre hachage, énergie, température et stabilité.

Ces leviers ne doivent pas falsifier la contribution. Une petite machine ne produit pas secrètement le même travail qu'une grande. Elle peut toutefois être utile d'une manière que le débit seul ne remplace pas.

La réalité financière reste séparée

Le mot idle peut attirer un langage dangereux : « revenu pendant votre sommeil », « gain passif », « récompense toutes les dix minutes ». Aucune de ces phrases ne décrit correctement DCENT_Pool.

Le matériel et l'électricité coûtent réellement

Un ASIC approprié, son alimentation, sa connexion, sa ventilation et son espace ont un coût. L'appareil produit de la chaleur et parfois beaucoup de bruit. Une installation électrique inadéquate peut être dangereuse.

La progression n'est pas la rentabilité

Le XP, les titres, les constructions et les contributions de guilde n'améliorent pas la rentabilité minière. Ils ne réduisent pas la difficulté et ne créent pas de droit à une récompense.

Un bloc n'arrive pas à heure fixe

L'intervalle de dix minutes est une moyenne pour tout le réseau. Il ne crée pas un tirage programmé propre à DCENT_Pool.

La récompense n'est pas un montant fixe

Lorsqu'un mineur produit un résultat à la cible du réseau, un bloc candidat doit encore respecter les règles Bitcoin. La récompense disponible combine la subvention applicable et les frais des transactions incluses. Les sorties coinbase, la politique de frais du pool, les confirmations, la maturité et le statut dans la meilleure chaîne comptent.

Les échecs précédents ne rendent pas la prochaine tentative « due »

Un compteur de jeu peut avancer. La probabilité du prochain hachage ne se souvient pas du compteur. Le calcul de probabilité doit porter sur un taux de hachage et une durée, avec des hypothèses visibles.

À quoi pourrait ressembler une journée

La scène suivante décrit une cible d'expérience, pas une fonction déclarée en production.

Le matin, vous constatez que votre ASIC est resté connecté pendant la nuit. Le tableau de bord était fermé, mais l'appareil a soumis du travail. Le monde a avancé selon les blocs Bitcoin arrivés pendant cette période. Une construction fictive a progressé grâce au travail admissible; un trajet est devenu plus risqué.

Vous prenez une décision. Les prochaines shares admissibles serviront à renforcer une position plutôt qu'à bâtir. Le bouton enregistre l'intention. Il ne crée ni défense gratuite ni meilleur hachage.

Pendant la journée, le mineur poursuit son fonctionnement normal. Le pool accepte ou rejette les soumissions. D'autres membres choisissent leurs propres objectifs.

À un nouveau bloc, le monde franchit un tick. L'interface indique clairement si le bloc a été trouvé par DCENT_Pool ou ailleurs. Le tick existe dans les deux cas; la récompense de minage solo, elle, n'existe que dans le cas approprié et vérifié.

Le soir, vous consultez la chronique, les shares acceptées, les interruptions et les mesures du matériel. Vous choisissez ensuite où diriger le prochain travail.

La satisfaction ne vient pas d'une application qui a inventé une journée de production. Elle vient d'un système qui a continué parce qu'une vraie machine a continué.

Pourquoi cette proposition est différente

Les adeptes de jeux incrémentaux comprennent déjà les horizons longs, l'automatisation, les systèmes imbriqués et les décisions prises entre deux périodes d'attente. DCENT_Pool ajoute trois contraintes :

1. la progression minière exige un travail matériel réel;
2. les événements fondamentaux suivent une horloge de blocs irrégulière;
3. le résultat monétaire demeure rare, probabiliste et séparé du jeu.

Pour certaines personnes, ces contraintes sembleront trop lourdes. Pour d'autres, elles donneront enfin du poids à la boucle incrémentale.

Le monde ne progresse pas parce qu'un serveur imagine que la machine a tourné. Il progresse seulement lorsque des machines ont réellement travaillé et que les règles peuvent montrer comment ce travail a été interprété.

Questions fréquentes

Est-ce vraiment un jeu « hors ligne »?

La personne peut fermer le tableau de bord, mais le mineur doit demeurer alimenté, refroidi, connecté et autorisé à soumettre du travail admissible. « Progression sans surveillance » est plus précis.

Les shares remplissent-elles une barre vers le prochain bloc?

Non. Elles mesurent du travail qui atteint la cible plus facile du pool. Elles ne rendent pas le prochain hachage plus probable et ne garantissent aucun bloc.

La progression fictive représente-t-elle un revenu?

Non. Les ressources, niveaux et événements du monde ne sont ni des bitcoins ni une créance sur un paiement futur. Le minage conserve ses coûts et sa forte variance.

Suivre le projet

Avant d'acheter ou de connecter un appareil : vérifier le matériel pris en charge et l'état courant du nœud, de Stratum, des shares, des frais, de la garde et du paiement. La publication de cet article ne prouve pas que le service est prêt à recevoir le taux de hachage principal.

La lecture devrait commencer par la définition actuelle du MMORPP en anglais, puis se poursuivre avec le guide complet du minage solo Bitcoin. Cet article fournit le contexte français; aucune page centrale française distincte n'est présumée. Consultez ensuite la page d'état qui sépare clairement les fonctions en production, en essai et sur la feuille de route.

Sources

• Bitcoin.org, FAQ française, vocabulaire français et Comment fonctionne Bitcoin?, pour le minage, la preuve de travail et l'intervalle moyen entre les blocs.
• Documentation pour développeurs Bitcoin, Mining, pour la distinction entre une share du pool et un résultat qui atteint la cible du réseau.
• Office québécois de la langue française, preuve de travail, chaîne de blocs et vocabulaire des jeux vidéo.
• Steam, catégorie Incremental, comme signal du vocabulaire courant du marché; les étiquettes Steam sont produites par les utilisateurs et ne constituent pas une définition linguistique officielle.