=> https://linuxfr.org/users/julien_jorge/journaux/sortie-de-bim-en-version-3-pour-les-fetes
2024-12-15 18:22 UTC,
=> #toc-nouveaut%C3%A9s-sur-le-client
=> #toc-nouveaut%C3%A9s-sur-le-serveur
=> #toc-ci-tests-et-corrections-de-bugs
=> #toc-quelques-anecdotes-de-dev
=> #toc-disponibilit%C3%A9-sur-f-droid-et-le-playstore
Bonjour'nal,
Je t'ai préparé [une nouvelle version de mon jeu Bim!]
=> https://github.com/j-jorge/bim/releases/tag/v3
.
Bim! est un jeu libre (code AGPL3 et assets CC-by-sa 4.0) à la Bomberman qui se joue uniquement en ligne. Il n'est disponible que pour les systèmes Android ([lien direct vers l'APK]
=> https://github.com/j-jorge/bim/releases/download/v3/bim-3.apk
).
Ça tombe bien, avec les fêtes de fin d'année qui s'approchent on va se retrouver en famille ou avec des amis ; ce sont les meilleures conditions pour profiter du jeu. En dehors de la pénibilité d'installer un APK hors store sur les appareils des uns et des autres, une fois que c'est en place on s'amuse bien.
La première nouveauté visible est la nouvelle icône.
=> Source : https://i.imgur.com/PzZDZB9.png
C'est pas mal hein? C'est français. Je ne suis pas sûr qu'elle survive sur la durée mais dans l'immédiat je trouve ça plutôt chouette.
Il y a maintenant un écran de paramétrage accessible via un bouton sur l'écran principal.
En dehors des réglages classiques d'effets sonores, de musique, et de vibrations, le joueur peut aussi y choisir la disposition des boutons. L'intention initiale est d'avoir un mode gaucher et un mode droitier mais personne ne viendra vérifier quelle est votre main dominante. Mettez-donc la disposition que vous trouvez la plus pratique.
Il y a aussi une option pour sélectionner le type de contrôles servant à déplacer le joueur : soit un pad directionnel, fixe à l'écran, soit une simulation de stick analogique qui suit le doigt, comme cela se fait sur les jeux mobiles récents.
Le lancement de la partie a aussi changé. Auparavant l'avatar du joueur pouvait changer d'une partie à l'autre ce qui rendait les débuts de parties un peu chaotiques. Maintenant l'avatar reste le même d'une partie à la suivante tant que les joueurs sont les mêmes. De plus une animation met en évidence l'avatar du joueur local au début des parties. Cette animation est d'ailleurs l'occasion de masquer la synchronisation avec le serveur en début de partie. Il devrait y avoir maintenant beaucoup moins de décalage au lancement lié aux écarts de performances des appareils des joueurs.
J'avais envisagé d'implémenter la solution proposée par zurvan (merci !) dans les commentaires de l'annonce précédente. Il s'agissait d'affecter toujours la couleur rouge au joueur local, ce qui avait l'avantage de résoudre complètement les changements aléatoires d'une partie à l'autre. Malheureusement entre temps j'ai observé des joueurs jouer dans la même pièce et j'ai remarqué qu'ils se demandaient leurs couleurs les uns les autres (« c'est qui le vert qui va brûler là ? »). Or si tout le monde se voit de la même couleur, c'est difficile de répondre à cette question.
Enfin, dernière amélioration sur le client, la pose de bombes dans la partie est plus réactive puisqu'elle s'effectue sur la pression du bouton plutôt que sur le relâchement.
Toutes les parties sont maintenant sauvegardées sur le serveur, ce qui me permet de déboguer plus facilement lorsque je vois un problème dans le feu de l'action.
Une nouvelle application,
bim-player
, permet de convertir une telle partie enregistrée en une représentation textuelle, pratique pour dérouler le jeu itération par itération :
=> Source : https://i.imgur.com/6FELTxh.png
Le serveur gère enfin la déconnexion des joueurs. Si un joueur disparaît il est sorti du jeu et la partie continue comme si de rien n'était.
Pas grand chose à ce niveau. J'ai ajouté une étape dans la CI où les tests unitaires sont lancés avec Valgrind et j'ai aussi mis à jour les images Ubuntu utilisées pour les tests. J'ai corrigé quelques comportements indéfinis, rien de bien transcendant.
Le jeu en réseau est quand même d'un autre niveau de difficulté en termes de programmation. Déjà que le multi-tâches n'est pas hyper simple, mais au moins on peut y synchroniser les tâches à l'aide de quelques primitives. Là il n'y a pas de synchro du tout. Toutes les tâches avancent réellement en parallèle et se transmettent leur progression à travers une autorité (le serveur) qui est le seul à détenir la vérité. Dans ces conditions ce n'est même pas la peine de penser mettre un point d'arrêt quelque part ; il faut en revenir au seul vrai débugueur :
printf
.
C'est d'ailleurs ce qui m'a amené à écrire
bim-player
. À un moment il faut pouvoir dérouler les parties doucement afin de bien comprendre ce qu'il se passe. Et ça a marché dès le début ! Dès que j'ai pu voir une partie avec
bim-player
j'ai immédiatement vu un bug. Un bug tellement bête…
Vous l'aurez peut-être remarqué mais le jeu se déroule sur une grille. Les obstacles, les bombes, les murs, tout est placé sur une seule case. Pour le joueur c'est pareil, bien qu'il se déplace progressivement d'une case à l'autre et semble ainsi être à cheval entre deux cases, d'un point de vue logique il n'occupe toujours qu'une seule case. Or il y a longtemps je me suis dit que ce serait une bonne idée que le joueur soit considéré dans la case voisine quand il est au bord de la case courante. Ça éviterait des cas où il aurait l'air d'être touché par des flammes alors qu'il apparaîtrait visuellement plutôt en dehors.
Ravi de ma bonne idée je l'ai implémentée. Si l'abscisse du joueur dans la case en cours est inférieure à 0,25 on considère qu'il est à gauche. De même si son abscisse est supérieure à 0.75 on considère qu'il est à droite. Idem pour les ordonnées. Et hop j'ai mis ça et je n'y ai plus pensé.
Jusqu'à l'affichage dans
bim-player
où j'ai vu des joueurs osciller à gauche à droite en passant d'une case à l'autre. Ben oui champion, quand le joueur est à x +0,75 ou plus on le considère à x +1, et quand il passe dans la case à droite il commence à (x+1) +0, soit une abscisse inférieure à 0,25, donc on le considère à x . C'est n'importe quoi.
Bref, j'ai viré cette merdveilleuse idée.
bim-player
est aussi un bel exemple, pour moi, de gestion de projet et des priorités. Au départ j'avais juste une fonction de debug pour afficher l'état du jeu dans le terminal. Puis lorsque j'ai eu des sauvegardes de jeu les possibilités ont explosé.
Eh ce serait cool d'avoir une interface pour naviguer dans la partie avec la possibilité de revenir en arrière. Oh et puis je pourrais mettre des commandes genre pour aller à une frame donnée, ou à un événement donné. Je pourrais utiliser libreadline pour cela, ça serait l'occasion d'apprendre à l'utiliser. Ou peut-être que je pourrais l'écrire en Rust pour pratiquer un peu ? Oh et puis ça serait bien aussi d'avoir une version graphique. Après tout j'ai tout ce qu'il faut pour afficher une partie de manière graphique. Eh et puis je pourrais proposer un replay dans le jeu, donner un moyen au joueur de revoir ses parties, ou même celles d'autres joueurs !
Ah l'enfer, en cinq secondes j'avais plus de boulot que pour faire le jeu lui même. Il faut élaguer tout ça, et c'est là qu'intervient la gestion de projet et la priorisation, sous la forme de deux questions simples : (1) quel est mon besoin ? et (2) quel est le dev minimal qui y répond le mieux ? Réponses égalent (1) « je veux pouvoir visionner une partie pas à pas », et (2) « un dump en texte brut fera bien l'affaire ». En effet une fois que j'ai toute la partie dans un fichier je peux la dérouler, revenir en arrière, et même faire une recherche sur le numéro d'itération pour sauter à un moment précis. Ça répond à mon besoin et même plus pour un effort minimal. Parfait !
Dès lors que j'aurai des graphismes corrects pour les parties et que j'aurai terminé quelques ajustements de gameplay, je m'intéresserai à la publication sur le PlayStore.
J'aimerais aussi mettre le jeu sur F-Droid, mais là ça me semble un poil compliqué. J'ai commencé à regarder le principe et je suis un peu inquiet sur la possibilité de faire le build avec mon script maison. J'ai vu aussi que tout cela se passait sur un dépôt sur GitLab et là, pas de chance, pas moyen d'y créer un compte. Il refuse mon adresse mail Gmx et me demande une adresse pro :( C'est nul, je n'ai pas d'adresse pro pour ce jeu ni pour publier sur F-Droid.
C'est doublement nul car j'avais un compte chez GitLab mais j'avais justement mis un e-mail pro, et comme j'ai changé de boîte en laissant le mot de passe dans le KeePass du laptop pro, je n'y ai plus accès. J'ai bien écrit à GitLab pour tenter de récupérer mon compte mais ils n'ont pas répondu. Donc là je suis bloqué. Si t'as un contact là-bas qui peut me redonner mon compte (login [j-jorge]
), ça serait bien, bien, cool. C'est un compte qui n'a servi qu'à ouvrir un bug chez GitLab, donc il n'y a vraiment rien dessus, et sûrement pas un truc pro.
[Télécharger ce contenu au format EPUB]
=> https://linuxfr.org/users/julien_jorge/journaux/sortie-de-bim-en-version-3-pour-les-fetes.epub
Commentaires : [voir le flux Atom]
=> //linuxfr.org/nodes/137641/comments.atom
[ouvrir dans le navigateur]
=> https://linuxfr.org/users/julien_jorge/journaux/sortie-de-bim-en-version-3-pour-les-fetes#comments
=> .. This content has been proxied by September (3851b).Proxy Information
text/gemini; lang=fr
