Article précédent : JRI Cône. Oh non, on part sur une série !
Du coup après réflexion sur un JRI avec des cônes, peut-être est-il intéressant de s’arrêter un peu davantage sur l’aspect « jeu » plutôt que sur l’aspect technique. J’ai eu pas mal de réflexions ces derniers jours (i.e., depuis hier…)(edit, en fait j’ai procrastiné sur écrire l’article, donc plus que depuis hier), et voici quelques notes en vrac.
But du jeu
Fondamentalement, plusieurs équipes doivent lutter pour capturer des zones – et les conserver – en utilisant des cônes. L’interactivité vient du fait que l’on vole des points de contrôle, et que l’on puisse les déplacer.
L’objet de base : le cône
Commençons par les contraintes concernant notre objet de base. Dans mon exemple, je suis parti sur un cône connecté à Internet et avec un système de géolocalisation intégré.
Si on veut faire un parallèle avec Ingress ou Pokémon GO, on a deux différences fondamentales avec notre PDC. Ce dernier devra être :
- Déplaçable : toute la partie marrante du projet, c’est que l’on puisse voler des cônes.
- Actif : il ne faut pas « juste » être à proximité du point pour le capturer, mais il faut interagir avec.
Afin de faire en sorte que ces deux éléments soient respectés, notre cône aura les contraintes suivantes :
- Une seule équipe à la fois pourra contrôler un seul cône.
- Le cône peut être recapturé par une autre équipe.
- Au bout d’un temps défini, le cône se libère tout seul, et doit être recapturé de toute façon.
- Il n’est pas possible pour l’équipe en possession du cône de « recapturer » le cône avant qu’il ne soit libéré.
- Si le cône n’est plus capable de transmettre sa position GPS (par exemple, s’il est planqué dans une armoire), alors il est désactivé.
L’idée de ces contraintes, c’est de faire en sorte que les gens ne vont pas tenter de « cheese » le jeu en partant sur un « haha j’ai capturé un cône, je le planque dans une vieille armoire, comme ça c’est easy win ».
Maintenant, quel intérêt de capturer des cônes ? Chaque cône correspondra à une zone d’influence, une sorte d’espace contrôlé. La taille de la zone contrôlée dépendra directement de la « freshness » de la capture : un cône capturé tout récemment aura une zone d’influence légèrement plus grande qu’un « vieux » cône.
Plus une équipe possède de cônes, plus ces cônes sont régulièrement (re)capturés, plus l’équipe pourra marquer des points.
L’éternelle volonté humaine : le territoire
Chouette, mais comment encourager les gens à déplacer sinon ? Et bien pour créer des zones !
Pour créer des zones, il faut d’abord récupérer les zones, les capturer, les rassembler pour créer un lien entre eux, et ensuite les redéplacer de manière stratégique pour couvrir une zone plus importante qu’avec un cône unique.
Après, la réflexion portait sur comment ajouter plus d’interactions entre cônes, et donc encourager plusieurs joueur·euse·s à participer. L’idée a été la suivante : les cônes liés ne servent pas seulement à couvrir de plus grandes zones, mais aussi à se protéger.
En gros, chaque cône lié à un autre cône aura un « lien ». A la capture d’un des cônes, l’autre va recevoir le lien en tant que « fantôme », et donc d’avoir une sorte de bouclier : il faudra réaliser deux captures (soit deux joueur·euse·s, soit attendre un cooldown entre captures) pour réussir à capturer le cône protégé.
Si l’on prend l’exemple d’un pentagramme (donc 5 cônes) avec tous les points reliés (donc 10 liens), si un des cônes se fait capturer, les quatre autres cônes reçoivent chacun un bouclier. Il faudra donc deux attaques pour capturer le prochain cône. Une fois capturé, ce dernier va donner un bouclier pour chaque cône restant, il restera donc trois cônes avec trois boucliers – et ainsi de suite. Une zone correctement protégée, i.e., composée d’un graphe complet, va donc prendre n(n+1)/2 attaques pour être libérée (nombre de liens + nombre de points).
Bien entendu, il sera aussi possible de « briser » la zone en déplaçant les cônes, mais il faudra toujours prendre en compte les liens fantômes pour revendiquer un cône.
Un autre avantage de cette règle, c’est qu’elle peut évoluer facilement en fonction du nombre de joueur·euse·s : il est techniquement possible de créer des patterns complexes seul·e, mais ça reste quand même bien plus fun avec plus de gens.
Stratégies émergentes
Il faut bien prendre en compte que le contrat de base avec le·la joueur·euse, c’est le déplacement de cône. Il est facile de trouver des alternatives pour facilement capturer des zones, par exemple en mettant un maximum de cônes au même endroit, et terminé. Néanmoins, l’idée sera de couvrir des zones relativement grandes, et de voir les cônes également en tant que ressource limitée : il faudra les placer justement et de manière intelligente, pour faire en sorte que les stratégies et les échanges avec les ennemis seront évolutifs.
Au niveau des variables, il faudra réaliser le calibrage des différents cooldowns, du ratio « freshness »/ »zone couverte », et aussi de la distance du lien entre les différents cônes. Également, le nombre de cônes sera un enjeu, mais je le souhaite également évolutif, avec…
J’ai aussi éventuellement songer que le déplacement en lui-même provoquera une réduction du « pouvoir » d’un cône, avec par exemple réduction de la zone couverte à chaque déplacement, mais je pense que pour ceci, il faudra tester en direct.
De l’open source ! (et autres technicités)
Un truc qui me ferait super plaisir et super rire, c’est de faire en sorte que les joueur·euse·s même puissent ajouter des nodes supplémentaires au graphe. En gros, trouver un cône, récupérer le matériel nécessaire, et lier le cône fabriqué par eux-mêmes au réseau du jeu. Ainsi, le jeu se pourrait d’être encore plus évolutif, et de nouvelles stratégies pourraient émerger, par exemple, la création d’une série de nouveaux cônes, pour une attaque surprise sur une zone donnée.
J’en profite pour placer deux choses : j’ai fait un p’tit repo Github pour pouvoir placer le code et les issues, et toutes autres suggestions de la part du public, et deux personnes m’ont chaudement recommandé d’utiliser des ESP32 pour le bricolage final, avec l’avantage d’être pas cher, d’avoir le WiFi intégré, et d’être pas cher. Les parties compliquées seront d’intégrer du GPS et de récupérer les informations par la suite, mais si l’on part du principe que les parties auront lieu dans des zones couvertes, cela devrait bien se passer.
Un dernier détail de réflexion : pour l’interaction avec le cône, il faudra faire en sorte d’avoir quelque chose « d’unique » par capture. De base, j’avais pensé à placer un bête QR code sur le cône en lui-même, mais le problème, c’est que prendre une jolie photo du machin permet de capturer les cônes depuis chez soi, sans avoir à se déplacer. Évidement, il y a déjà la contrainte de la localisation GPS (le cône peut très bien se déplacer), mais je souhaite aller plus loin, en intégrant par exemple une sorte de « nonce« , et générer quelque chose de dynamique à afficher, par exemple avec un petit écran. Je pense pour cela m’inspirer du système d’inventaire du Musée Bolo, qui est relativement malin dans son implémentation.
Et du coup c’est pour quand tout ça ?
Dans l’idée, j’ai bien envie de tenter de travailler là-dessus durant mes vacances universitaires, pour pouvoir lancer le tout sur mon campus à la rentrée de Septembre. La probabilité que ce projet ne reste qu’une idée est néanmoins forte – l’on verra ce que l’avenir nous montrera.