🔀 Darkwaar33 - Seedwake : un mode multijoueur asynchrone sans serveur

Même graine. Même obscurité. Des choix différents.

Et si le mode multijoueur ne nécessitait pas que les joueurs soient en ligne en même temps ? Et si la comparaison de deux parties ne nécessitait ni serveur ni base de données, mais simplement une graine et une séquence d’actions ?

C’est ce que j’ai exploré avec Darkwaar33 - Seedwake, un petit roguelike tactique au tour par tour développé avec Godot 4.6.

Deux joueurs peuvent explorer exactement les mêmes sept étages, prendre des décisions différentes, puis comparer leurs parties par la suite. Une partie importée devient un « fantôme », montrant où l’autre joueur est allé, comment il a survécu et le moment exact où leurs décisions ont divergé.

Ce qui est intéressant, ce n’est pas seulement le gameplay. C’est l’architecture qui rend possible la compétition asynchrone sans infrastructure en ligne.

Une graine, un monde

La génération procédurale apporte généralement de la variété. Chaque nouvelle partie produit un monde différent, ce qui favorise l’exploration et la rejouabilité.

Mais la génération procédurale peut également créer un point de référence commun entre les joueurs.

Dans Seedwake, une graine de 30 bits détermine l’environnement dans son intégralité :

• Sept étages, chacun contenant une grille tactique de 7×7.
• Les positions des murs et l’emplacement des escaliers.
• Le placement des ennemis et leur comportement initial.
• Les « glints » à collecter et leurs durées d’expiration.
• Les offrandes des sanctuaires entre les étages.

Deux joueurs partant de la même graine se retrouvent face aux mêmes conditions initiales.

Plus important encore, aucun nombre aléatoire n’est généré pendant le jeu.

Une fois qu’un étage a été généré, chaque résultat obéit à des règles déterministes. Les ennemis agissent en fonction de leur état actuel, les attaques sont prévisibles, et la même action appliquée au même état produit toujours le même résultat.

La graine détermine le monde. Le joueur détermine ce qui s’y passe.

Le déterminisme en tant que contrainte architecturale

Godot permet de générer des nombres aléatoires via RandomNumberGenerator, mais son algorithme sous-jacent est documenté comme un détail d’implémentation.

Pour un jeu classique, cette distinction n’a peut-être pas beaucoup d’importance. Pour un jeu où les joueurs échangent des codes de relecture, elle est en revanche cruciale.

Une rediffusion créée aujourd’hui ne devrait pas produire silencieusement un résultat différent après une mise à jour du moteur.

Seedwake utilise donc un petit générateur xorshift32 explicitement défini, avec des flux indépendants dérivés à l’aide de FNV-1a.

Les flux sont séparés par responsabilité :

Flux	Responsabilité
map	Murs, escaliers, reflets et disposition des étages
enemy	Positions, orientations et cycles des ennemis
offer	Récompenses des sanctuaires

Chaque flux est également isolé par étage.

Modifier la génération du troisième étage ne devrait pas modifier de manière inattendue celle du quatrième.

Cette séparation évite un problème courant lié à la génération procédurale : l’utilisation d’un nombre aléatoire supplémentaire dans un sous-système peut modifier l’ensemble de la séquence utilisée par un autre.

Cela signifie également que les décisions de gameplay ne peuvent pas influencer la génération future par une utilisation accidentelle du générateur de nombres aléatoires (RNG).

Une simulation indépendante de son interface

Seedwake sépare ses règles de la couche de présentation Godot.

L’architecture est délibérément légère :

main.gd
    Entrées, écrans, HUD, animations
 |
 v
rules.gd
    Génération, actions, combat,
    score et simulation
 |
 v
board_view.gd
    Grille, unités, intentions,
    fantôme et retour visuel

codec.gd
    Graines, codes d’exécution et sommes de contrôle

Le fonctionnement central est conceptuellement simple :

Rules.apply(state, action)

Elle prend un état et une action, valide le coup, puis renvoie l’état résultant ainsi que les événements décrivant ce qui s’est passé.

L’interface utilise ces événements pour animer les déplacements, les dégâts, la destruction des ennemis et les transitions.

Les animations ne modifient pas la simulation.

Cette distinction est importante. Une interpolation d’une durée de 120 millisecondes ne doit pas modifier le résultat d’un tour, quels que soient la fréquence d’images ou les performances du navigateur.

La logique du jeu reste indépendante du rendu, du timing et des périphériques d’entrée.

Cette même architecture rend également l’intégralité du jeu rejouable.

Une rediffusion n’est qu’une liste de décisions

Les enregistrements de jeux traditionnels stockent des images ou des images vidéo.

Seedwake n’a besoin ni de l’un ni de l’autre.

La simulation étant déterministe, la reproduction d’une partie ne nécessite que deux éléments :

1. La graine d’origine.
2. La séquence ordonnée des actions du joueur.

Une rediffusion est reconstituée en appliquant ces actions à un état initial nouvellement généré.

Rules.simulate(seed, actions)

Le résultat comprend l’état final du jeu et une trace de la progression du joueur.

Il n’y a pas de moteur de rediffusion distinct ni de deuxième implémentation des règles de combat.

La même simulation est utilisée pour le gameplay ordinaire, la validation des rediffusions et les fantômes rivaux.

La rejouabilité découle des règles elles-mêmes plutôt que d’un sous-système supplémentaire ajouté a posteriori.

Partager une partie sans backend

À la fin d’une partie, Seedwake génère un code de partie compact.

Par exemple :

SW1-04V9P-NR2B5-…

Ce code contient la version des règles, la graine, l’identifiant du joueur, les actions enregistrées, le résultat revendiqué et une somme de contrôle.

Les actions utilisent des identifiants à quatre bits, ce qui permet de faire tenir deux actions dans un octet. Les données obtenues sont encodées à l’aide du codage Crockford base32, un alphabet convivial qui évite plusieurs caractères ambigus.

Un code peut être copié dans un message et importé par un autre joueur.

Le jeu qui importe le code ne se fie pas aveuglément au résultat.

Il décode les données, vérifie leur intégrité, valide la version des règles, puis réexécute l’intégralité de la séquence d’actions.

Si le score simulé, les niveaux terminés ou le nombre de tours diffèrent du résultat déclaré, le code est rejeté.

Il ne s’agit ni d’une authentification cryptographique ni d’un système anti-triche. Une somme de contrôle ne peut empêcher une falsification délibérée, et les joueurs hors ligne peuvent réessayer une graine autant de fois qu’ils le souhaitent.

Mais cela fournit un résultat reproductible et cohérent, sans nécessiter de comptes, de bases de données, d’API ou de simulation côté serveur.

Pour un petit jeu partagé entre amis, c’est un compromis utile.

Le « fantôme » est l’historique d’un autre joueur

Une fois qu’un code rival a été validé, sa trace de simulation devient un « fantôme ».

Le fantôme apparaît sous la forme d’un losange cyan creux se déplaçant sur les mêmes étages que le joueur.

Il ne participe pas aux combats, ne bloque pas les déplacements et n’influence pas les décisions des ennemis.

En revanche, il fournit des informations.

Au troisième étage, au cinquième tour, le jeu peut afficher l’endroit où se trouvait l’adversaire au troisième étage, au cinquième tour.

Si l’adversaire a déjà atteint l’escalier, le jeu indique à quel moment il en est sorti. S’il est mort, sa position finale devient un marqueur de mort.

Une courte traînée de positions précédentes rend les déplacements du fantôme lisibles.

C’est le multijoueur asynchrone réduit à son essence informationnelle.

Les deux joueurs n’échangent jamais de messages avec un serveur. Leurs parties n’ont jamais besoin de s’exécuter simultanément. Ils partagent simplement un monde déterministe et comparent leurs historiques.

Déterminer le moment exact où deux parties divergent

La fonctionnalité que je trouve la plus intéressante est le marqueur de divergence.

Imaginez deux joueurs partant d’une même graine.

Ils effectuent le même premier coup, puis le même deuxième coup, puis le même troisième coup.

La simulation étant déterministe, leurs états restent identiques.

Au quatrième tour, l’un se déplace vers le nord tandis que l’autre repousse un ennemi vers l’est.

C’est là la première divergence.

Seedwake enregistre cette décision et marque sa position sur le plateau à l’aide d’un symbole en forme de fourche.

À partir de ce moment, les deux parties peuvent évoluer vers des résultats complètement différents.

Un joueur pourrait récupérer une étincelle sur le point de s’éteindre. L’autre pourrait éliminer un ennemi, préserver sa santé ou atteindre l’escalier plus tôt.

Le jeu peut identifier l’action précise à partir de laquelle l’histoire commune s’est scindée en deux chemins différents.

C’est plus intéressant que de se contenter de comparer les scores finaux.

Un score vous indique qui a obtenu les meilleurs résultats selon le système de notation.

Un marqueur de divergence vous indique à quel moment leurs décisions ont commencé à diverger.

La comparaison devient alors un moyen de comprendre le jeu lui-même.

Rendre les règles tactiques lisibles

L’architecture déterministe n’aurait guère de sens si les joueurs ne pouvaient pas comprendre les conséquences de leurs actions.

Seedwake utilise donc un plateau tactique compact et entièrement visible.

Il existe trois types d’ennemis :

• Les Brutes poursuivent le joueur et attaquent les cases adjacentes.
• Les Lanciers tirent dans une direction fixe selon un cycle de trois tours.
• Les Sentinelles attaquent périodiquement leurs quatre cases voisines.

Leurs intentions s’affichent avant que le joueur n’agisse.

Les cases hachurées en rouge indiquent où les attaques vont frapper.

Le joueur peut se déplacer, attendre, sprinter ou pousser des ennemis. Pousser un ennemi contre un mur, un autre ennemi ou le bord du plateau le détruit.

Les attaques ennemies peuvent également toucher d’autres ennemis.

Cela crée de petits défis tactiques où le positionnement importe davantage que la vitesse de réaction.

Les reflets ajoutent une deuxième dimension décisionnelle. Ils disparaissent après un nombre limité de tours et peuvent soit être conservés pour marquer des points, soit dépensés dans des sanctuaires pour obtenir des améliorations de survie.

Le joueur doit constamment choisir entre collecter des ressources, éviter le danger et progresser vers l’escalier.

Comme les règles ne comportent aucun élément aléatoire en cours de partie, les conséquences de ces décisions sont reproductibles.

Pourquoi pas de serveur ?

Un classement en ligne serait possible.

Un backend pourrait collecter les scores, gérer les défis quotidiens, valider les soumissions et diffuser les parties des adversaires.

Mais cela impliquerait également des contraintes liées à l’infrastructure, à l’authentification, au stockage, à la prévention des abus, à la maintenance et au déploiement.

Pour Darkwaar33, je voulais tester jusqu’où le concept de multijoueur asynchrone pouvait aller sans tout cela.

Le résultat prend en charge trois interactions simples :

• Partager une graine pour relever le même défi.
• Partager un code de partie pour comparer les performances complètes.
• Importer un code de partie pour jouer aux côtés du fantôme d’un autre joueur.

Le navigateur exécute tout localement.

La limite est tout aussi claire : il n’y a ni recherche automatique d’adversaire, ni classement global, ni application contraignante des tentatives quotidiennes.

Ces fonctionnalités nécessiteraient un modèle d’infrastructure différent.

Pour cette expérience, elles ne sont pas nécessaires.

Un petit jeu, une idée réutilisable

Darkwaar est une expérience en cours visant à créer et à publier régulièrement de petites idées jouables.

Seedwake suit cette approche : un plateau limité, un petit ensemble d’actions, sept niveaux, trois types d’ennemis et une mécanique asynchrone distinctive.

Le projet utilise Godot 4.6 et GDScript, avec une exportation HTML5 publiée via le pipeline existant de Darkwaar.

La leçon plus générale dépasse le cadre des roguelikes.

Lorsqu’une application est construite autour de transitions d’états déterministes, une séquence d’entrées peut devenir une représentation compacte et portable d’une exécution complète.

Cela ouvre des possibilités pour les systèmes de relecture, le débogage, les tests reproductibles, les simulations et la collaboration asynchrone.

Dans Seedwake, cela se traduit par un fantôme qui marche à vos côtés dans un donjon.

Mais en réalité, il s’agit simplement d’une nouvelle exécution des mêmes règles.

Même graine. Même obscurité. Des choix différents.

Jouez à Darkwaar33 - Seedwake

Jouez à Seedwake sur itch.io

Sept étages. Une graine partagée. Aucun serveur requis.

Jouez de manière indépendante, partagez votre code d’exécution et mettez quelqu’un d’autre au défi de prendre de meilleures décisions dans exactement le même monde.