Plonger dans la création d’un jeu vidéo à partir d’un simple jeu de société

J’ai créé un prototype de jeu vidéo basé sur un jeu de société. Découvrez cette histoire mêlant abandon, persévérance et évolution. Qui a mené à la création de ma chaine Youtube et à un besoin de partage.

Il y a quelques mois j’ai créé un prototype de jeu vidéo basé sur un jeu de société que j’apprécie nommé pingouin dans lequel on amasse des points en récupérant des poissons en déplaçant des pingouins sur des cases de banquises hexagonales.

Ce qui ne devait être qu’un prototype

Au début de ce projet mon but était de travailler sur des algorithmes de déplacements hexagonaux simples. Mais aussi de réfléchir et d’implémenter mon propre système d’intelligence artificielle. Ou encore de rendre le jeu multijoueur.

Tout était bien parti

Je me suis pris au jeu et j’ai fini par réaliser le jeu en 3 étapes

  • Créer le prototype jouable en mode console
  • Transfert du code dans Unity et création de l’affichage
  • Développement du mode multijoueur / jeu contre l’ordinateur

La première étape m’a pris 5 soirées, la seconde 2 soirées

Quand tout a dérapé

J’ai pris la décision de créer une interface avec un écran d’accueil, un écran de paramétrage de la partie, etc ce qui m’a pris plus de 10 bonnes soirées et 1 ou 2 week-end. Et c’est là que les temps de développement ont explosés mettant en péril la publication de mon projet.

Certes j’avais une interface graphique mais il fallait revoir la gestion du plateau, les couleurs, la police d’écriture, la génération du plateau et cela plusieurs fois. Chaque modification qui n’avait pas été prévue à commencer à me prendre un temps monstrueux jusqu’à ce que je ne prenne presque plus de plaisir sur ce projet. J’ai quand même persisté en ajoutant le jeu contre l’ordinateur et en réfléchissant à l’implémentation du mode multijoueur. Mais le mal était fait. J’avais visé trop haut pour une aventure de codeur en solitaire sur mon temps libre.

Une lumière au bout du tunnel

J’ai profité de l’été pour regagner quelques forces et reprendre des activités un peu plus sociales comme les barbecues ou les sorties au lac. Suite à de nombreuses discussions, des connaissances m’ont fait comprendre une chose importante à propos de mes différents projets.

Mes projets sont une source d’inspiration

Ce n’est pas parce que je galère qu’il ne faut pas persister et que la direction n’est pas la bonne, au contraire. Toutes les personnes avec qui j’ai parlé cet été m’ont avouées la suprématie de l’informatique dans le monde du travail et même dans la vie de tous les jours. Ils ont réussi à me faire prendre conscience de la force de mes compétences. Et à me rappeler toutes les galères que j’ai surmontées tout au long de mon parcours ce qui a fini par me décider à promouvoir plus mes projets et à mettre en avant mes réflexions, mes échecs, mes découvertes et mes réussites.

Ce qui m’a conduit à créer des vidéos

Il faut cultiver notre jardin, par cette phrase de Candide écrit par Voltaire j’entends désormais bien plus que le simple fait de reprendre chaque année un carré de terre pour en faire jaillir de beaux fruits et légumes. En effet, ça fait plus d’une dizaine d’année que je cultive moi même des connaissances en partageant une partie de ma production mais en oubliant une étape importante. Celle d’en partager les graines. Ces graines ce sont mes vidéos.

Et apprendre à mieux maitriser le sujet

En créant des vidéos j’ai commencé une nouvelle activité. La rédaction et la recherche d’informations pertinentes en plus du montage vidéo et de la création de contenu. Tout ça dans le but de mieux maitriser mon sujet et que la graine prenne dans mon audience.

Et c’est pourquoi

J’ai imaginé une nouvelle série de vidéos qui démarre par l’analyse entre les jeux de société auxquels j’aime jouer et leur portage en jeux vidéo. Ce qui implique toute une analyse comparative des avantage et des inconvénients de ces deux pratiques. Je découvre moi même un nouvel éclairage sur ce qui manquait à mon prototype initial et que j’aimerais pouvoir transmettre dans le futur par l’intermédiaire de mes vidéos.

Enfin la vidéo

Elle est à regarder sans modération. Et à partager si elle vous plait.

Pour mieux comprendre

Si vous ne l’avez pas encore vue, vous pouvez regarder ma série de trois vidéos qui traite de la création d’un jeu de société en utilisant uniquement un ordinateur, un logiciel libre de dessin vectoriel « Inkscape » ainsi qu’une imprimante et une paire de ciseaux ou un cutter.

dotfiles, git et rcm

Dans un billet récent sur le thème des dotfiles, j’évoquais ma migration prochaine de stow vers rcm comme programme de gestion de mes fichiers de configuration. C’est désormais chose faite et j’utilise à présent rcm à la place de stow.

Parmi les améliorations notables apportées par rcm, la principale est la possibilité de déployer l’ensemble de mes dotfiles en une commande, et non plus en exécutant une commande stow par dossier, ou programme. Je l’avais évoqué, l’organisation de mon dépôt git a également gagné en clarté, la seule différence étant l’absence de point devant les fichiers ou dossiers à la racine du dépôt.

La migration d’un système vers l’autre s’est déroulé sans grande difficulté. Comme souvent, la première étape consiste à installer le programme. Pour une fois, celui-ci n’est pas disponible par défaut dans les paquets d’Arch Linux. Je passe donc par yaourt pour récupérer le paquet dans le dépôt AUR.

yaourt -S rcm

L’installation du paquet rcm mets à disposition quatre utilitaires: rcup, rcdn, mkrc et lsrc. Je ne rentre pas dans les détails de chacun des programmes; le programme principal à utiliser est rcup, programme responsable de l’installation et de la mise à jour des dotfiles. Avant d’exécuter la commande de déploiement, j’ai commencé par changer la structure de mon dépôt git dans une branche dédiée. Une fois la structure satisfaisante, j’ai fusionné l’ensemble dans la branche master. Avant d’effectuer la fusion, il faut s’assurer de garder un terminal ouvert, car en ouvrir un avant d’avoir effectuer le redéploiement va conduire à l’ouverture d’un terminal non configuré, dans mon cas, ouverture sur l’interface de première configuration de oh my zsh.

Revenons à nos dotfiles. Après fusion de mes branches, tous mes fichiers dotfiles existants sont désormais des liens cassés vers l’ancien emplacement des fichiers. Il est donc plus que temps de rétablir les liens pour coller à la nouvelle structure du dépôt. Pour cela, j’utilise donc rcup avec les paramètres :

  • x pour exclure un fichier
  • d pour spécifier l’emplacement du dossier dotfiles
  • f pour forcer l’installation (supprime le fichier existant et le remplace par un lien vers le fichier dans notre dossier dotfiles).

Ce qui donne donc quelque chose comme cela :

rcup -x README.md -x LICENSE -d /chemin/vers/dossier/dotfiles -f

J’ai eu quelques erreurs à l’exécution, étant donné que stow avait mis en place des liens symboliques directement sur certains répertoires. Les répertoires ayant changé d’emplacement, rcup n’arrive pas à y accéder pour créer le lien symbolique du fichier de configuration dans le dossier.

mkdir: ~/.config/terminator: Input/output error
ln: ~/.config/terminator/config: No such file or directory
mkdir: ~/.zsh: Input/output error
ln: ~/.zsh/keychain.zsh: No such file or directory
mkdir: ~/.zsh: Input/output error
ln: ~/.zsh/security.zsh: No such file or directory

Pour corriger ces erreurs, j’utilise donc unlink pour supprimer les liens symboliques existants et j’exécute une nouvelle fois mon déploiement via rcup.

unlink ~/.config/terminator

Au final, la migration de stow vers rcm m’aura demandé une petite heure environ et n’aura pas présenté de difficulté particulière. Compter également plusieurs dizaines de minutes, quelques heures peut-être, réparties sur plusieurs jours afin de me documenter, de comprendre le fonctionnement des outils et d’arrêter ma décision. La nouvelle structure de mon dépôt dotfiles me convient davantage et je trouve le fonctionnement de rcm plus simple dans son utilisation basique, mais proposant néanmoins des fonctionnalités avancées qu’il me faudra étudier pour éventuellement décider d’en faire usage. Ma préférence va donc à rcm et l’avenir nous dira si mon choix était pertinent. Enfin, il serait malvenu de tirer un trait définitif sur stow, qui doit rester un outil à ma disposition, si un cas d’utilisation adéquat se présente.

dotfiles, git et GNU stow

En septembre 2016, j’avais commencé à écrire l’introduction de cet article. J’expliquais donc que je venais de réinstaller le système d’exploitation de mon ordinateur portable, pour passer de Debian 8 à Arch Linux. À ce moment-là, c’était donc posé la question de la synchronisation de la configuration de l’environnement entre machines. Par configuration de l’environnement, je désigne ici les fichiers de configuration des différents logiciels que j’utilise, plus généralement appelés « dotfiles », car commençant par un point, ou étant stocké dans le dossier .config du répertoire utilisateur.

Pour gérer mes configurations entre machines, j’ai donc utilisé le duo Git et GNU stow depuis lors. Git bien sûr pour la synchronisation entre machines et l’historisation, et GNU stow, pour le déploiement des fichiers à leur emplacement dédié.

Fonctionnement

Par défaut, stow créé un lien symbolique dans le répertoire parent de celui à partir duquel on exécute la commande, pour tous les fichiers concernés par la commande. Ma configuration part du principe que mon dépôt git dotfiles est stocké à la racine de mon répertoire utilisateur, à savoir donc ~/dotfiles, et que toutes les commandes stow sont exécutées depuis ce dossier. L’installation de la configuration s’effectue alors en appelant la commande stow avec pour paramètre le nom du logiciel dont on souhaite déployer la configuration. Au niveau de la structure, mon dépôt git se présente donc sous la forme d’une liste de répertoire contenant chacun le chemin vers la configuration du logiciel concerné, c’est-à-dire :

  • soit directement le fichier si celui-ci est stocké directement à la racine du répertoire utilisateur: c’est le cas par exemple du fichier .gitconfig.
  • soit dans une arborescence de répertoire correspondant à son emplacement: par exemple pour i3, la configuration est stockée dans ~/.config/i3, j’ai donc dans mon dépôt un dossier i3 contenant l’arborescence .config/i3.

Voici un extrait de mon dépôt en image pour expliciter la situation.

Extrait de la structure du dépôt.

Ainsi, pour déployer le fichier de configuration de Git, j’exécute la commande suivante, depuis mon dossier dotfiles:

stow git

Ce qui aura pour effet de créer un lien symbolique .gitconfig vers le fichier .gitconfig de mon dépôt git. Si on souhaite modifier le répertoire de destination, on peut utiliser l’option -t. Dans l’image ci-dessus, pour déployer la configuration ansible, j’utiliserai alors:

stow -t / ansible

A noter que stow effectue la création du lien symbolique à la condition que le fichier n’existe pas. Si un fichier de configuration par défaut existe déjà, il sera nécessaire de le supprimer d’abord avant de pouvoir procéder à l’exécution de la commande stow.

Dernier point, si je souhaite re-déployer la configuration git, j’utiliserai alors l’option -R, soit la commande :

stow -R git
Conclusion

Le duo git + GNU stow est plutôt efficace pour ce qui est de la gestion des fichiers de configuration, les fameux fichiers dotfiles, et pour la synchronisation entre machines. Je m’en étais également servi pour stocker et déployer facilement certains fichiers de configuration sur mes serveurs, avant de commencer à automatiser avec ansible. Si je rédige aujourd’hui, cet article sur le sujet, c’est pour garder une trace d’une méthode robuste qui m’a été utile pendant plus de deux ans. Néanmoins, la structure actuelle du dépôt git ne me convient plus autant qu’avant et je souhaiterais passer à une organisation plus proche, ou même identique à l’arborescence présente sur le disque. J’étudie donc les autres solutions de gestion des dotfiles, et m’intéresse en particulier à rcm; mais ceci est une autre histoire, pour un autre article.

[ArchLinux] Retrouver du son

Suite à une mise à jour, j’avais constaté une perte totale de son sur toutes les sorties audio de mon système (toutes celles testées en tout cas). Le wiki ArchLinux indique que par défaut tous les canaux sont muets dans ALSA. J’ai donc tenté de leur « rendre la parole » et la première de trois commandes ci-dessous a suffi:

$ amixer sset Master unmute
$ amixer sset Speaker unmute
$ amixer sset Headphone unmute

Un pense-bête pour servir de référence si le problème survient à nouveau.

RSSHub

Ayant testé un moment la plateforme Instagram et souhaitant être en mesure de suivre les publications d’une sélection de comptes publiques directement dans mes flux RSS, je me suis tourné, après quelques recherches, vers une solution open source plus que prometteuse, à savoir RSSHub.

On peut constater rapidement en parcourant le github du projet que les principaux contributeurs sont d’origines asiatiques, comme l’attestent les caractères. Cela ne nuit en rien au projet, puisque la documentation en langue de Shakespeare est plutôt complète, si ce n’est pour la lecture des commentaires présents dans le code, ou des issues sur Github.

J’ai donc fait le choix de tester cette solution, et pour une fois, plutôt que de l’héberger sur l’une de mes machines, j’ai choisi de suivre la solution GCP décrite dans la documentation du projet. Le but étant de savoir si mon utilisation reste dans le palier gratuit fournit par Google pour l’utilisation d’un App Engine, et surtout, de pouvoir tester facilement l’intégration avec FreshRSS. Enfin dernier point, cela me permet de ne pas me poser la question de l’hébergement d’une solution NodeJS, qui nécessiterait un peu de travail de configuration pour arriver à une situation satisfaisante dans mon infrastructure auto-hébergée.

Commençons par quelques notes concernant la gestion de profils au niveau de l’utilitaire gcloud. En premier lieu, création d’un profil rsshub.

gcloud config configurations create rsshub

Voir le détail de la configuration active.

gcloud config list

Lister toutes les configurations de comptes disponibles.

gcloud config configurations list

Et enfin, activer la configuration rsshub.

gcloud config configurations activate rsshub

Passons ensuite à la préparation du déploiement de l’application. Pour cela, je créé un fichier app.yaml à la racine du projet afin de décrire la façon de déployer le programme sur la GCP et le configurer.

# [START app_yaml]
runtime: nodejs10
basic_scaling:
   max_instances: 1
network:
   forwarded_ports:
       - 80:1200
       - 443:1200
# environment variables section, refer to Settings
env_variables:
   CACHE_EXPIRE: '300'
   HTTP_BASIC_AUTH_NAME: '<username>'
   HTTP_BASIC_AUTH_PASS: '<password>'
#[END app_yaml]

Pour terminer, déploiement de l’application dans App Engine.

gcloud app deploy

À ce stade, je dispose donc d’un RSSHub agissant comme proxy entre mon lecteur de flux RSS et Instagram. Celui-ci est hébergé sur le cloud Google et la faible utilisation ne semble pas dépasser les paliers gratuits, ce qui n’est pas plus mal. RSSHub permet également de générer des RSS pour des comptes Twitter ou encore, pour des résultats de recherche leboncoin; la liste est plutôt bien fournie et semble aller en augmentant.

RSSHub est donc un programme que je trouve particulièrement intéressant pour ne plus dépendre d’un compte ou d’une application téléphone pour consommer du contenu. C’est un véritable gain sur bien des aspects, pour Instagram en tout cas, je note: pas de publicité dans le flux (sauf contenu sponsorisé d’un compte), possibilité de supprimer l’application, donc pas de tentation de l’utiliser pour passer le temps ou en cas d’ennui, pas de pistage (ou en tout cas, moins aisé). Au final, retour à un système qui me convient et que je maîtrise, où l’information arrive quand je l’ai décidé et sans essayer de me rendre accro.