Réflexions sur LyokoCMD

Lucidiot — Informatique — 2019-10-02
Je pars à la quête de vos retours sur quelques idées pour relancer un vieux projet !

Un peu d'histoire

Ce jeudi 3 octobre, ce sera le dixième anniversaire de mon inscription sur un forum de fans de Code Lyoko où j'ai fait une rencontre qui m'a lancé dans la programmation ; j'en avais déjà parlé plus en détail dans de précédents articles. Cette rencontre a été permise par ce que je considère être mon premier projet un tant soit peu sérieux : LyokoCMD, une recréation de l'interface du Supercalculateur, en Batch. Ce n'était pas fabuleux, avec juste une interface qui répondait à quelques commandes et affichait du texte en couleur en bloquant pendant quelques secondes pour simuler des temps de chargement, mais pour le moi de l'époque c'était assez impressionnant de pouvoir créer ça de mes propres mains. Le projet a presque été complètement tué avec l'arrivée du 64-bits dans ma maison, puisque le script Batch dépendait d'un programme étrange que j'avais "emprunté" à un autre développeur du forum et qui me permettait d'afficher le texte en couleurs, et ce programme ne fonctionnait plus du tout sur les Windows en 64 bits.

Il y a un an et demi ou deux ans, un ancien camarade de classe du lycée m'a donné dans un train un Acer Aspire 7220 en échange de la modique somme de rien. Chouette, un laptop gratuit ! Après avoir joué un peu avec, notamment en installant Arch Linux et i3wm et en constatant qu'il n'était même pas capable de faire tourner un navigateur web récent, je décide d'y installer un OS qui lui serait probablement plus adapté : un bon vieux Windows XP.

Ah, la nostalgie ! Je profite que l'ordinateur soit en 32 bits et ressors tous mes scripts Batch des archives, ainsi que quelques projets en Visual Basic. Je m'installe tout un environnement de développement et m'amuse un peu avec mes vieux projets, en envoyant des screenshots à quelques amis de longue date que j'avais rencontrés sur le forum. L'instinct qui me pousse toujours à commencer des projets sans les terminer me fait commencer une réécriture de LyokoCMD en C# sur ce laptop ; il me faut un moment pour réapprendre la syntaxe des anciennes versions du langage et oublier le sucre syntaxique des versions modernes.

Je commence à avoir un peu plus d'idées sur ce que je veux faire de ce projet, et finalement je le déplace sur mon environnement normal de développement et le convertis à .NET Core pour pouvoir y travailler sous Linux. Je ressors de mon grenier numérique DasConzole, un projet de framework pour créer des interfaces graphiques en ligne de commande — ncurses, mais structuré comme Windows Forms et en C#.

Avec le déménagement et mon rapprochement géographique avec ce cher Valou, nous sommes motivés à reprendre le développement de ce projet et avions des idées pour en faire un MMO avec plusieurs front-ends (une interface en ligne de commande, une interface web, une application mobile, etc.) et même des attaques de XANA qui pourraient impliquer un Minitel. Les idées partaient un peu dans tous les sens mais je n'avais pas vraiment de direction claire pour le projet, donc tout s'est résumé à quelques soirées en mode hackathon, chez lui ou chez moi, à rajouter une ou deux fonctionnalités. Depuis, on a perdu un peu la motivation ou le temps pour y faire quelque chose, et le projet est retourné dans le grenier.

Dans le cadre d'un grand nettoyage de ce « grenier » suite à l'élaboration de mon rapport d'intégrité, où j'ai proclamé un bon nombre de projets « en attente » comme abandonnés pour me forcer à arrêter d'y penser et décidé de laisser tomber des idées de projets superflues, j'ai décidé de tuer DasConzole, voyant notamment que depuis le début de ce projet, des librairies bien meilleures ont vu le jour, par exemple gui.cs. L'idée était donc de migrer LyokoCMD à gui.cs dès que je décide de reprendre le développement dessus.

Je code occasionnellement en C# principalement pour des raisons historiques : j'ai appris le Visual Basic juste après LyokoCMD, et je me suis converti au C# très rapidement durant mon BTS juste parce qu'on devait utiliser ce langage pour un petit projet ; je ne suis pas revenu au VB ensuite. J'ai beaucoup plus de compétences en Python qu'en C#, mais j'aime bien retourner dessus notamment pour un peu de nostalgie, et pour faire du code beaucoup plus orienté objet sans les prises de tête de Java. Mais j'ai récemment remarqué qu'un des plus gros blocages que j'ai sur ma motivation à coder dans ce langage, c'est qu'il fait ressortir mon syndrome de l'imposteur : quand je vois que mon niveau en C# est en fait plutôt bas — je connais le langage en lui-même plutôt bien, mais je ne connais aucun des frameworks utiles comme ASP.NET pour créer des sites web ou Entity Framework pour interagir avec des bases de données —, et que j'ai un mal fou à développer des projets qui font vraiment quelque chose, ça me désespère un peu.

Bien évidemment, je peux juste suivre des tutoriaux et expérimenter un peu plus, mais ça reste assez frustrant de ne pas pouvoir faire grand chose, et ma patience et ma motivation sont actuellement beaucoup trop limitées pour que je puisse me permettre de faire ça. De plus, ce n'est pas aussi simple que ce serait de passer de Python à Ruby par exemple : on parle de changer ma manière de penser et de structurer les programmes, parce que Python permet de faire un peu tout ce qu'on veut et de perturber complètement le fonctionnement normal du langage pour faire du code presque magique, alors que C# est plus strict.

J'ai donc gardé dans un coin de ma tête une réflexion sur une manière de coder LyokoCMD dans des technologies sur lesquelles je suis plus à l'aise, sans pour autant bloquer Valou qui n'a pas tant que ça de langages en commun avec moi. Et puis c'est mon retour récent sur tilde.town, sur lequel je reviendrai plus en détail dans un autre article, qui m'a inspiré pour un reboot du projet.

Dans le premier reboot en C# du projet, j'avais utilisé des commandes inspirées des Linux modernes, avec par exemple une commande service qui prenait des paramètres similaires à systemctl, notamment en référence au supercalculateur de ma fiction Vacances. J'envisageais aussi d'avoir un système d'autocomplétion similaire à zsh. Et je me suis dit qu'il serait probablement beaucoup plus simple de juste directement utiliser zsh au lieu de se compliquer la vie à réinventer la roue, un schéma que j'admets avoir énormément suivi dans LyokoCMD et encore plus dans DasConzole. Et le fait de travailler autant à créer des programmes en ligne de commande tels que pylspci en tentant de respecter un peu le principe KISS (Keep It Simple, Stupid) de UNIX, m'a donné des idées.

Nouveau concept

Rouages de la machine

L'utilisation de LyokoCMD pourrait commencer par une simple commande lyokocmd, qui pourrait prendre des paramètres un peu comme ce qu'on choisirait dans un menu de démarrage de jeu (un fichier de sauvegarde par exemple). Entrer cette commande démarre le jeu, et ne fait pas grand chose que rajouter dans le PATH un dossier d'exécutables supplémentaire. Le PATH est la liste des dossiers où un shell va chercher le programme correspondant à une commande (par exemple, yes sera trouvé dans /usr/bin/yes) ; en ajoutant un dossier soi-même, on ajoute donc un accès à de nouvelles commandes, qui sont chacune des scripts, des programmes différents. La commande lyokocmd fonctionne donc d'une manière similaire aux environnements virtuels Python.

LyokoCMD ne serait donc plus un projet monolithique mais un grand groupe de tous petits projets relativement indépendants, qu'on peut découper facilement, et sur lequel on peut faire de courtes itérations rapidement ; ça nous permet de caser un peu de travail sur LyokoCMD entre du travail sur d'autres projets, ce qui aide pour mon trouble de l'attention ou pour gérer un emploi du temps surchargé. On peut aussi choisir différents langages et expérimenter autant qu'on veut entre les commandes sans que ça n'aie de grosse incidence.

L'une de nos idées très ambitieuses pour le projet était d'avoir des possibilités de programmation, d'automatisation dans le supercalculateur : avec l'utilisation des outils standards de Linux, tout est déjà là et les joueurs pourront automatiser autant qu'ils veulent de toutes les manières existantes sous Linux : scripts shell ou n'importe quel langage, tâches CRON, démons, etc.

Mais il faut bien une façon de centraliser toutes les informations du jeu, sinon les commandes ne pourront pas faire grand chose de sensé ensemble. J'ai pensé au départ à une simple base de données SQLite, ce qui irait très bien pour un seul joueur. Mais en regardant la connexion SSH ouverte sur tilde.town sur mon autre écran, je me suis dit qu'on pourrait réessayer l'idée du multijoueur, mais cette fois-ci au sein d'un même ordinateur. Un démon (ou service si vous préférez les termes Windowsiens) pourrait être démarré et arrêté automatiquement par la commande lyokocmd pour un jeu solo, ou maintenu allumé en permanence pour un jeu multijoueur, et utiliserait une socket UNIX pour fournir une API REST à la manière de dockerd ; on pourrait tout aussi bien mettre le serveur sur un port IP normal et l'utiliser depuis un autre ordinateur. Grâce à ça, on peut aussi gérer des actions « hors ligne », quand le joueur n'est pas dans le jeu.

Gameplay

Je reprends le concept de notre premier reboot : avoir plein de joueurs qui jouent des Jérémie Belpois et combattent XANA en PvE (avec peut-être la possibilité de choisir de devenir XANA aussi ?). Chaque joueur doit gérer son équipe de lyokoguerriers : je pensais à un système similaire aux Pokémon où on peut les nommer, développer leurs attaques ou leurs compétences, etc.

Le jeu serait relativement lent, dans le sens où il se jouera en tour par tour et aura des côtés « idle game » : on peut laisser des programmes s'exécuter en arrière plan et ils pourraient durer des jours, des semaines. On pourrait avoir une quantité limitée de ressources, une limite sur la fréquence de retour vers le passé, ou on pourrait juste être bloqué dans sa progression dans le jeu en attendant une nouvelle attaque de XANA. Avoir un tel fonctionnement lent et asynchrone rendra le jeu similaire à ceux qu'on rencontre sur tilde.town, puisque c'est adapté aux fuseaux horaires très variés des utilisateurs et parfois au peu de temps dont ils disposent chaque jour pour venir. Je m'inspire pour cela de jeux comme Neverending Legacy.

Les joueurs pourraient peut-être assigner des scripts permettant de faire des commandes de déplacement ou d'attaque, des IA, d'une façon similaire à LeekWars. Durant les attaques de XANA, on pourrait imaginer un fonctionnement comme sur un jeu de stratégie tel que Battle for Wesnoth, avec un nombre limité de pas et d'attaques par tour.

Si on met en place un mode multijoueur, je pense qu'il se déroulerait dans la mer Numérique : il faut construire son Skidbladnir pour obtenir l'accès, et ensuite chaque joueur possède en fait un Réplika ; il pourrait être possible de s'envoyer des messages dans le jeu et de coopérer.

Exemple

Ce qui suit est un script de ce que j'imagine pouvoir être le début d'une session de jeu dans LyokoCMD :

$ lyokocmd
LyokoCMD 0.1.0 - lucidiot@localhost
$ lw list
Name   Status HP
------ ------ ---
Aelita Idle   100
Bob    Idle   100
$ vw status
Service status: running (uptime 10d 2h 5m)
Core health: Shield #1 100%, Shield #2 100%, Core 100%
Objects: 4 Sectors, 40 Towers, 4 Way Towers, 1 Core
$ sc task
Name       Status
---------- -------
skid_build Running
$ sc task skid_build
Name: skid_build
Description: Build the Skidbladnir
Status: Running (3d 1h)
Resource usage: 23 quantum bits
Logs:
...
[INFO] Successfully built Navskid #3
...
$ vw tree
Forest
├── Tower 1
├── Tower 2
...
Fifth Sector
├── Tower 40
└── Core
    └── Shield 1
        └── Shield 2
$ vw virt Aelita 'Forest/Tower 1'
Cannot virtualize to this object directly; will try the closest coordinates
Using coordinates 1024.0, 54.2, -88.6 @ Forest
Transfer…
Scanning…
Virtualizing…
$ lw list
Name    Status      HP
------- ----------- ---
Aelita  Virtualized 100
Bob     Idle        100

Mais tout cela n'est encore que très hypothétique : qu'est-ce qui pourrait être vraiment intéressant pour ce jeu ? Qu'est-ce qui pourrait être une première version jouable du jeu, pour qu'on puisse commencer à itérer dessus et l'améliorer ?

C'est là que j'essaie de faire entrer en jeu d'autres personnes au travers de cet article : seriez-vous intéressé par un projet de ce genre ? Avez-vous des suggestions ? Voulez-vous carrément contribuer ? N'hésitez pas à suggérer des choses dans les commentaires ou à ouvrir des issues sur l'ancien projet GitLab. Je mettrai à jour cet article si de nouvelles idées nous viennent ou si les choses se précisent un peu.

Commentaires

Il n'y a pour l'instant aucun commentaire. Soyez le premier !