Sommaire
Bonjour 'nal,
Ah je suis content de te voir :) Je viens de sortir un nouvel APK de mon jeu Bim!, le deuxième depuis la dernière fois que je t'en avais parlé. Entre temps j'ai surtout travaillé sur l'interface des menus, plus quelques corrections et ajustements ici et là.
Bim! est un jeu de type last-man-standing, très arcade, et fortement inspiré de Bomberman/Dyna Blaster, même s'il doit à terme s'en éloigner. Il se joue uniquement en ligne, de deux à quatre joueurs. Il n'y a pas d'IA ici ; les parties se font toujours entre humains.
Des menus
Le jeu utilise le moteur Axmol, qui est très bien pour afficher des trucs mais a peu de facilités pour gérer des écrans de jeu. Il y a bien quelques trucs mais de souvenir de Cocos2d-x, dont Axmol est un fork, ce n'était pas top. Du coup je bricole un truc par dessus pour faire mes interfaces.
Pour commencer, fini l'écran noir en entrant dans le jeu, on a maintenant un peu de couleur et d'animation :
C'est quand même plus sympa. Là on ne le voit pas mais le fond de l'écran et le fond du bouton sont animés. Il manquerait plus qu'un logo. De là on ne peut que lancer une partie et tomber sur l'écran de recherche d'adversaire :
Après que tous les joueurs aient validé cet écran on passe au match en lui-même :
Bon, là aucun travail n'a été fait, donc ça reste moche. Mais ça n'empêche pas de s'amuser !
Lorsque le match est terminé on passe sur l'écran de fin de partie d'où on peut relancer un match ou revenir à l'écran principal :
Et voilà. Ça va, c'est pas moche ! Et si on n'a pas de chance on peut aussi apercevoir la belle interface des popups :
Pfiou, trois mois pour ça… Bon ça va, il y a aussi du travail sous le capot dont je parle dans la section suivante :)
On ne le voit pas sur les captures mais il faut aussi savoir que tout cela appelle une gestion de transition d'un écran à l'autre qui demande un peu de rigueur. Il y a aussi pas mal de travail fait pour que l'interface s'adapte joliment aux diverses résolutions de téléphone (e.g. réduction globale de la taille des polices sur les écrans plus petits que le modèle de référence).
Tiens, un petit exemple du besoin de faire quelque chose au dessus d'Axmol et autres subtilités pour s'adapter aux différents appareils.
Le fonctionnement d'Axmol est de placer les nœuds d'affichage dans un canevas d'une taille fixe puis de redimensionner l'ensemble à la résolution de l'écran de l'appareil. Par exemple si je fais la conception sur un canevas de 768×1280 et que l'appareil a une résolution de 1536×2560 alors tout sera étiré ×2 sur les deux dimensions. En particulier, les textes seront un peu flous. Il vaut donc mieux avoir un système qui augmente la taille des polices globalement pour garder un rendu net.
Autre subtilité, pour les boutons j'utilise un 9-slices, ce qui est assez classique :
Illustration de la différence d'un redimensionnement d'un carré, à gauche, vers un rectangle, à droite, en étirement classique en haut, et 9-slices en bas — Alwik, Wikipedia.
Selon ce principe les coins des composants sont toujours à l'échelle 1 tandis que les zones centrales sont étirées pour remplir l'espace. Et bien si je prenais juste le 9-slices d'Axmol alors mon coin de 50×50 pixels sur mon 768×1280 ferait toujours 50×50 pixels sur l'appareil en 1536×2560. Il aurait l'air deux fois trop petit ! Pour compenser cela il faut adapter l'échelle du 9-slices en fonction de la résolution de l'appareil.
Grace à ces changements le jeu s'affiche maintenant correctement sur un Nexus 4 tout comme sur un Pixel 3.
Nouveautés de gameplay ou internes
J'avais précédemment tenté de compenser un peu la latence du réseau en forçant un petit délai entre le moment où le joueur presse le bouton et le moment ou l'action est effectuée. Ça évitait quelques surprises où on voyait un joueur faire une action pour ensuite la voir annulée parce qu'elle avait été mal prédite. Malheureusement cela causait aussi des difficultés de jeu puisqu'on déposait par exemple les bombes quelques cycles plus tard, donc pas là où on était quand on a appuyé sur le bouton. C'était très frustrant. Maintenant les bombes sont toujours posées là où le joueur était quand il a appuyé sur le bouton.
De plus, les bombes sont affichées dès que le bouton est pressé, bien qu'elles ne seront prises en compte par la boucle de gameplay que quelques cycles plus tard. Cela réduit fortement l'inconfort lié au lag.
Toujours sur le sujet de la synchro réseau, j'ai augmenté la fréquence d'envoi des actions de jeu, réduisant ainsi l'écart de la simulation avec le serveur. De plus, si un joueur va trop vite (il a trop d'avance sur le serveur) alors la simulation sera légèrement ralentie de son côté pour tenter de réduire l'écart.
Une liste de serveurs de jeu est maintenant récupérée du serveur web lors du lancement de l'application. Celle-ci se connecte alors au premier serveur disponible qui utilise la même version du protocole de communication. Cela devrait permettre des montées de version plus douces en laissant des serveur anciens tourner le temps que les joueurs fassent la mise à jour.
J'ai revu le système de matchmaking au niveau du serveur. Il faut savoir qu'il y a un mode permettant de trouver des adversaires dans une salle nommée, afin de jouer avec des amis. Ce n'est pas encore disponible dans le client mais le serveur le supporte et des tests valident la fonctionnalité. Auparavant ce mode et le mode adversaire aléatoire partageaient la même collection de parties. Ce n'était vraiment pas pratique dans des scénarios où les joueurs lancent des parties en boucles. Maintenant chaque service gère ses propres parties et il est plus simple pour le serveur de savoir si un joueur est toujours dans une partie.
En parlant de parties sur le serveur, celui-ci fait maintenant tourner la simulation du jeu. Auparavant il se contentait de faire le passe-plat entre les joueurs, transmettant les actions des uns aux autres. Maintenant il sait où en est la partie et peut donc savoir si elle est terminée ou non. C'est aussi lui qui dit aux clients que la partie est terminée, avec tel résultat.
Il faut voir qu'avec la communication en UDP entre les clients et le serveur les infos arrivent vraiment n'importe comment. Elles arrivent vite, mais en vrac. Cela fait qu'on peut sans difficulté se retrouver avec un message de recherche d'adversaire de la part d'un joueur suivi d'une action en jeu de ce même joueur ! Il suffit que le joueur ait rapidement enchaîné une partie puis une recherche pour qu'un message de la première, un peu perdu sur Internet, se fasse doubler par un message de la seconde. Dès lors, c'est l'enfer à gérer côté serveur. Maintenant que le serveur sait si la partie est en cours, il peut ignorer les messages qui ne concernent pas la partie, et inversement, il va ignorer les messages d'une partie une fois que celle-ci est terminée.
Le matchmaking est un gros sujet, ça mériterait un article à part.
En dehors de tout cela il y a eu pas mal de « petites » choses telles que les adaptations pour développer directement sur le téléphone (cf. mon dernier journal), quelques mises à jour, de bibliothèques et d'outils sur la CI, pas mal de tests automatiques supplémentaires, et enfin l'ajout d'un readme !
Un coup de main
Je t'épargne l'habituel « on cherche des contributeurs », parce qu'en fait je n'aurai pas le temps de gérer des contribs :) Par contre j'aimerais bien ton avis sur un truc.
Au départ j'avais un client en mode texte, pour valider les premières étapes du développement (gameplay, communication client-serveur). Je l'ai ensuite supprimé car c'était difficile de le maintenir mais finalement je me dis que ça serait bien pratique, en plus d'être hyper cool. Par exemple, si j'avais un client texte, je pourrais m'en servir pour faire tourner des robots pour les tests. Malheureusement je bloque sur un truc.
Le problème étant que le joueur se déplace en jeu progressivement d'une case à la voisine. Même s'il est toujours dans une seule case du point de vue du jeu, il y a quand même une progression visuellement. Cette progression, je ne vois pas du tout comment la faire dans un affichage en mode texte. J'ai le sentiment que dans une telle interface ce sera très frustrant de voir le joueur « bloqué » sur une case pendant 8 cycles avant de passer à la suivante.
Je sais bien que je n'ai pas besoin de l'affichage pour avoir des robots mais quitte à avoir un client sans GUI, autant qu'il soit cool (et l'affichage c'est quand même bien pour debuguer).
Toi qui a connu les jeux en mode texte, as-tu connaissance d'une astuce, d'une technique, pour rendre progressive la transition d'une case à sa voisine ? Si tu as des références de jeux qui faisaient ça bien, ça m'intéresse.
On joue ?
Jusque là le serveur a plutôt tourné en mode facile, genre trois clients max en simultané en dehors des tests. Est-ce que ça te dirait de le faire chauffer un peu ? On dit rendez-vous à 13 h (France métropolitaine) tous les jours de cette semaine pour une petite partie en attendant le dessert, et puis tu me diras dans les commentaires si tu as rencontré des problèmes.
Pour l'installation, c'est par ici.
# transition
Posté par nizan666 . Évalué à 2 (+1/-0).
Tu pourrais faire clignoter le caractère dans la case de départ et dans la case d'arrivée, éventuellement en faisant diminuer / augmenter le temps "affiché" dans la case départ / arrivée en proportion de l'achèvement de la transition.
[^] # Re: transition
Posté par pas_pey . Évalué à 2 (+1/-0).
Ou sinon tu représentes tes personnages par différents caractères unicode successifs faisant croire à une transition : moins de pixels à droite et plus à gauche sur plusieurs frames, jusqu'au transfert complet. Ne reste qu'à trouver les caractères adaptés.
[^] # Re: transition
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
La grille de jeu dans la capture d'écran ne fait que 12x12 cases à peu près. Si on la dessine en mode texte sur 24x24 caractères, on a la possibilité de dessiner le joueur entre 2 cases, et ça rentrera toujours bien dans n'importe quel terminal
# retour
Posté par zurvan . Évalué à 4 (+2/-0).
salut, j'ai fait quelques parties, voici mon retour :
les graphismes sont assez simples / moches, ça gagnerait à être un peu plus vendeur (l'écran d'accueil est bien), quitte à réutiliser des sprites libres (genre Frogatto ou autre)
il me semble que la couleur du joueur est aléatoire, si bien que d'une partie à l'autre on va être rouge ou vert, et commencer aléatoirement d'un côté ou de l'autre. Bon, en bougeant on va vite découvrir qui est qui, mais c'est un peu déstabilisant et ça ne semble pas super niveau ergonomie. Idée : permettre au joueur de choisir sa couleur librement, ou bien définir une couleur fixe pour le joueur qui joue (vert par exemple, de son point de vue), et les autres pour les adversaires (rouge, orange, jaune etc).
en parlant de bouger, le point noir du jeu c'est quand même le contrôle, il est extrêmement difficile d'utiliser le joystick car il reste statique, il faut limite cliquer en regardant l'écran. Ce qui serait bien c'est que le joystick s'active dans une zone définie de jeu (gauche ou droite), et qu'en glissant le doigt ça indique les directions. Un exemple de jeu android qui fonctionne bien avec ça c'est brawl stars.
il faudrait une petite explication / guide de jeu d'à quoi servent les bombes que l'on découvre ainsi que les flammes. Je crois que les bombes permettent d'en lancer plusieurs, et les flammes augmentent la portée, mais ça serait bien de préciser.
la partie où on "creuse" tout seul dans son coin est un peu fastidieuse. Ça serait peut-être pas mal d'avoir un écran un peu moins répétitif avec plus de trous et de passages.
ça serait pas mal d'avoir un mode contre des bots, pour s'entraîner et se faire la main.
En tout cas c'est un petit jeu sympa avec un potentiel intéressant…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: retour
Posté par Julien Jorge (site web personnel) . Évalué à 5 (+3/-0).
Merci pour les retours ! C'est exactement ce dont j'avais besoin :)
Ouais c'est vraiment en mode placeholder là. J'ai commandé des sprites pour la partie jeu, ça ne fera pas de mal.
C'est pas hyper simple l'attribution des couleurs. J'ai pensé à laisser le joueur choisir mais si plusieurs joueurs choisissent la même couleur alors il va falloir les distinguer, et je me retrouve dans la situation initiale. Avoir une couleur pour le local ça doit pouvoir le faire oui, bonne idée, merci.
Pas évident ça non plus. Au départ j'avais mis un stick (fixe, pas de déclenchement par zone) mais c'était assez frustrant car le personnage sur l'aire de jeu suit une grille et bouge à vitesse fixe. Or le stick donne l'impression que l'on pouvait bouger à des angles variés et des vitesses différentes. Cela dit depuis j'ai amélioré le mouvement, donc peut-être que ce serait mieux. Je vais retenter.
[^] # Re: retour
Posté par zurvan . Évalué à 4 (+2/-0).
ce n'est pas important, dans le sens où chaque joueur ne se voit que lui-même sur son écran et n'a pas à connaître la couleur préférée des autres, donc si je choisi la couleur verte, et joueur B également, moi je me vois en vert et je vois B en orange par exemple, et lui de son côté il se voit en vert et me voit en orange. Ce n'est pas un match retransmis à la TV comme pour le foot :)
ça serait peut-être mieux quand même au final, plus pratique pour se déplacer sans regarder cette zone de l'écran. Les jeux sur android ont quasi tous ce même problème de toute façon, à moins de faire déplacer dynamiquement le joystick sur la zone touchée
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Ne démarre pas ; dépendances ou version d'Android ?
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0).
Hello Julien, ça a l'air cool !
Juste, parmi les infos souvent omises que j'aurais aimées trouver sur la page des releases, il y aurait la version minimale d'Android et les éventuelles dépendances (genre Google Play framework etc).
Ma remarque n'est pas innocente : j'ai installé l'APK et il ne démarre pas sur mon Android 9 habituel (bref écran noir, puis retour au homescreen).
Je n'ai pas le nécessaire ici pour t'en dire plus avec Logcat (ou son équivalent); par contre si tu veux bien me renseigner, je peux regarder -pour lundi au plus tard.
[^] # Re: Ne démarre pas ; dépendances ou version d'Android ?
Posté par Julien Jorge (site web personnel) . Évalué à 3 (+1/-0).
Merci :)
Mmh c'est une bonne question, à laquelle je n'ai pas la réponse… Il me semble l'avoir testé sur un Android 8 sur lequel j'ai eu et corrigé ce bug qui ressemble aussi à ce que tu décris. Je commence à me demander si j'ai bien uploadé le bon apk.
Si tu peux me confirmer que logcat te sort bien un truc de ce genre, ça serait top :
[^] # Re: Ne démarre pas ; dépendances ou version d'Android ?
Posté par Tarnyko (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 27 septembre 2024 à 21:39.
Wow, merci pour la réponse 😀!
Eh bien du coup, je te le confirme, preuve à l'appui :
09-27 21:12:54.142 31981 31981 E AndroidRuntime: FATAL EXCEPTION: main
09-27 21:12:54.142 31981 31981 E AndroidRuntime: Process: bim.app, PID: 31981
09-27 21:12:54.142 31981 31981 E AndroidRuntime: java.lang.NoSuchMethodError: No static method createPredefined(I)Landroid/os/VibrationEffect; in class Landroid/os/VibrationEffect; or its super classes (declaration of 'android.os.VibrationEffect' appears in /system/framework/framework.jar!classes2.dex)
[^] # Re: Ne démarre pas ; dépendances ou version d'Android ?
Posté par Julien Jorge (site web personnel) . Évalué à 3 (+1/-0).
Effectivement je m'étais bien planté en uploadant l'apk. Peux-tu tester avec celui-ci ?
[^] # Re: Ne démarre pas ; dépendances ou version d'Android ?
Posté par Tarnyko (site web personnel) . Évalué à 3 (+1/-0).
Installé… parfait, ça marche, merci !
Maintenant il me reste à trouver 1) un ami 2) un 2ème Android
pour tester toussa 😉.
# Communauté dev indé
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Est-ce que tu t'es rapproché de communautés de dev indé ? Ils seront, j'en suis sûr d'une grande aide pour donner des conseils de game design et faire des play tests.
Moi j'ai lancé le jeu mais il n'a trouvé personne
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Communauté dev indé
Posté par Julien Jorge (site web personnel) . Évalué à 2 (+0/-0).
Pas encore :) Déjà il faudrait que je me mette à jour sur les communautés à contacter, et puis je voudrais aussi que les graphismes de la partie jeu soient jolis avant de le montrer d'une manière plus large, pour éviter les critiques évidentes. Après je ne suis pas pressé non plus de prendre les vagues de moqueries, trolls, et sarcasmes habituels des internautes. Au moins sur LinuxFr.org je sais à quoi m'attendre, et les gens s'y expriment plutôt bien.
Oui il faut vraiment fonctionner en rendez-vous pour un jeu comme ça, surtout en l'état. Pour trouver un adversaire en moins de 15 secondes n'importe quand il faudrait pas loin de 6000 joueurs par jour, et encore je ne mets pas de critères de ping ou d'expérience dans le matchmaking.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.