Développement de jeu/application - Emergent
J'ai développé une application Android pour la Belote Tunisienne avec Emergent — incluant les règles spéciales tunisiennes, le mode multijoueur, des adversaires IA, le multilinguisme, AdMob et une publication sur Google Play. Cela m'a fait réaliser : l'IA accélère énormément la mise en œuvre, mais la compréhension technique reste cruciale. Mon rôle a moins été de « coder » et plus axé sur les exigences, les tests, la révision et l'architecture.
Je voulais depuis longtemps créer une version numérique de la Belote Tunisienne, pas seulement un jeu de cartes quelconque avec des règles standard, mais vraiment la variante telle que beaucoup d'entre nous la connaissent : avec les cas spéciaux tunisiens, avec le Contre et le Surcontre, avec le Capot, avec la Belote/Rebelote, avec les discussions typiques autour des mauvaises cartes, des points, des annonces et des situations qui sont généralement résolues intuitivement à table.
De cette idée est née Belote Tunisienne, une application Android que j'ai développée avec l'aide d'Emergent.
Pour moi, le projet était particulièrement intéressant parce que je viens moi-même du développement logiciel. Je n'ai donc pas simplement « fait générer une application », mais je me suis fortement impliqué dans les exigences, les tests, la révision, la vérification logique et les décisions d'architecture. C'est précisément là que le projet est devenu passionnant : Emergent a massivement accéléré la mise en œuvre, mais ma compréhension technique est restée nécessaire.
Pourquoi j'ai créé Belote Tunisienne
La raison principale était simple : je voulais une véritable application de Belote Tunisienne.
Pas seulement un jeu de cartes avec les règles de la Belote française ou internationale, mais une version plus proche de ce que les Tunisiens jouent réellement. Surtout avec les jeux de cartes, on remarque rapidement que « Belote » n'est pas toujours « Belote ». Beaucoup de règles sont locales, de nombreuses décisions sont prises par habitude, et certains cas spéciaux ne deviennent visibles que lorsqu'on essaie de les traduire proprement en code.
De plus, j'avais le désir de construire quelque chose d'unique pour la communauté tunisienne. L'application devait être facilement accessible, gratuite, fonctionner sur mobile et, plus tard, être jouable en ligne avec des amis.
Le plus grand défi : la représentation précise des règles de jeu tunisiennes
La partie la plus difficile n'était pas de dessiner des cartes sur une table. La partie la plus difficile était la logique du jeu.
Dans la Belote Tunisienne, il existe de nombreux cas spéciaux qui, dans un jeu réel, sont souvent résolus simplement par l'expérience. Mais dans une application, chaque situation doit être définie de manière univoque.
Quelques exemples :
- Contré et Surcontré
- Valeurs de points comme 320 / 640
- Capot avec les scores spéciaux correspondants
- Belote-Rebelote avec un score supplémentaire
- Règles d'arrondi
- Cas spéciaux comme le jeu incorrect ou la « Tfaskira »
- Nouvelle donne en cas de certaines distributions de cartes extrêmes
- Visibilité et timing des enchères
- Logique spéciale pour la dernière position
- Jeu automatique du dernier pli
C'est la combinaison des règles, du timing et de l'interface utilisateur qui était particulièrement exigeante. Quand un joueur fait « Contre », l'autre joueur doit avoir la possibilité de réagir dans un court laps de temps. Dans une version ultérieure, une fenêtre de 5 secondes pour Contre → Surcontre ou Ignorer a été intégrée.
Le huitième pli a également été automatisé : le dernier pli est joué automatiquement et animé, sans que le joueur n'ait à cliquer une nouvelle fois. En même temps, il fallait éviter que le son « C’est votre tour » ne soit joué inutilement à ce moment précis.
Cela semble anodin au premier abord, mais c'est exactement le genre de détail qui détermine si un jeu de cartes semble fluide ou non.
UI : Les petits détails font toute la différence
L'interface utilisateur a également demandé beaucoup plus de travail qu'on ne le pense au premier abord.
Dans un jeu de cartes, tout doit être visible, compréhensible et suffisamment calme en même temps. Les cartes, les joueurs, les enchères, le score, les bulles de chat, les sons, les boutons et les modales ne doivent pas se gêner mutuellement.
Au cours du développement, de nombreuses petites ajustements d'interface utilisateur ont été effectués :
- Le panneau d'enchères a été visuellement adapté et mieux aligné.
- Les champs de sélection blancs dans la zone d'enchères ont été corrigés.
- Le décalage du panneau a été réduit de 10 % à 5 %, car 10 % était visuellement trop prononcé.
- L'historique des scores a été rendu défilable pour que les parties plus longues ne soient pas coupées.
- Les bulles de chat « Yezzi! » ont été corrigées pour qu'elles ne disparaissent pas derrière d'autres éléments d'interface utilisateur.
- Un bug a été corrigé où la taille des cartes changeait lorsque l'application passait en arrière-plan et était rouverte.
- Un bouton Mute a été ajouté directement dans le jeu et synchronisé avec les paramètres de profil.
Ce ne sont pas des fonctionnalités spectaculaires, mais elles rendent l'application plus utilisable. En particulier pour les jeux mobiles, la stabilité de l'interface utilisateur est extrêmement importante. Un petit décalage ou un élément superposé peut immédiatement perturber le déroulement du jeu.
Multijoueur et stabilité
Le mode multijoueur était l'un des domaines les plus critiques.
Un jeu de cartes pardonne peu en mode en ligne. Si un joueur minimise brièvement l'application, verrouille son téléphone, a une mauvaise connexion ou passe en mode économie d'énergie, la partie ne doit pas être complètement interrompue immédiatement.
Un sujet important était donc la connexion au backend. Android peut restreindre l'activité en arrière-plan et les connexions réseau, surtout lorsque l'application est minimisée ou que le mode économie d'énergie est actif. C'est pourquoi l'application ne devait pas être conçue pour que la connexion reste stable en permanence.
La solution devait plutôt être pensée ainsi :
- L'application passe en arrière-plan
- Le joueur n'est pas immédiatement retiré brutalement
- Court délai de grâce en cas de coupure de connexion
- Permettre la reconnexion
- Resynchroniser l'état du jeu depuis le serveur
- Le serveur reste la source de vérité
Dans une version, une protection de connexion a donc été ajoutée afin que les joueurs ne soient pas immédiatement éjectés du matchmaking ou des parties en cours si l'application passe brièvement en arrière-plan.
Le mécanisme de keepalive a également été révisé. De plus, des journaux d'erreurs explicites ont été intégrés pour mieux comprendre les problèmes de backend. C'était un point classique où ma compréhension technique est restée importante : il faut comprendre si un problème provient de l'interface utilisateur, du WebSocket, de l'état du backend, du comportement du cycle de vie Android ou d'un timeout.
Adversaires IA et jeu hors ligne
Outre le mode en ligne, l'adversaire IA était également important. Une application de Belote a besoin d'un moyen d'être jouable de manière significative même sans joueurs humains.
Avec les adversaires IA, il ne s'agit pas seulement de jouer des cartes au hasard. L'IA doit au moins jouer conformément aux règles, tenir compte de la couleur d'atout, évaluer les plis et prendre des décisions qui ne semblent pas complètement fausses.
Pour moi, il était important que l'application soit d'abord stable et correcte avant que l'IA ne paraisse particulièrement « intelligente ». Un adversaire parfait ne sert à rien si les règles spéciales sont mal comptées ou si l'état du jeu est corrompu.
Multilinguisme
Belote Tunisienne ne devait pas fonctionner dans une seule langue.
Plusieurs langues sont disponibles dans l'application, y compris le français, l'allemand et l'arabe/tunisien dans le contexte marketing. Pour la communication autour de l'application, il était important pour moi qu'elle corresponde réellement au groupe cible.
En particulier pour la publicité, nous avons travaillé avec des formulations telles que :
- 100 % bou blech
- telechargiha 3al Play Store
- Références à 3 langues disponibles
- Textes de store et de publication en français
Sur Google Play, j'ai également dû saisir les notes de version dans le bon format, par exemple avec les balises <fr-FR>. Cela semble banal, mais de tels détails prennent également du temps si l'on veut vraiment publier l'application.
Android, Google Play et publications
La publication sur Android était un sujet à part entière.
Techniquement, un Android App Bundle devait être créé et téléchargé via la Google Play Console. Ensuite, les étapes classiques suivaient :
- Créer une version
- Rédiger les notes de version
- Mettre en place un test fermé
- Sélectionner les pays et les régions
- Gérer les testeurs
- Remplir les informations de confidentialité
- Lier correctement la suppression de compte et la politique de confidentialité
- Faire examiner l'application
- Publier de nouvelles versions ultérieurement
J'ai parcouru plusieurs versions, notamment des versions comme 1.0.4 et plus tard 1.1.0. Il était intéressant de constater qu'une publication réussie ne signifie pas automatiquement que tous les appareils de test sont immédiatement mis à jour. Lors d'un test fermé, le testeur doit être connecté avec le bon compte Google, l'application doit être installée via Google Play, et les mises à jour ne sont pas toujours distribuées automatiquement et immédiatement.
La Play Console elle-même apporte également de nombreux sujets supplémentaires : noms de package, vérification d'identité pour les développeurs Android, paramètres de store, confidentialité, contenu de l'application et pistes de test. Pour quelqu'un sans formation technique ou proche du produit, cela peut rapidement devenir confus.
Combien m'a coûté le développement ?
Le développement n'était bien sûr pas gratuit. Dans le tableau de bord d'Emergent, le projet a jusqu'à présent affiché 4 975,27 crédits dépensés.
Plusieurs packages étaient visibles sur l'écran des prix : 100 crédits pour 20 $, 500 crédits pour 100 $, 1 250 crédits pour 250 $, 3 000 crédits pour 500 $ et 6 000 crédits pour 1 000 $. Cela donne un prix effectif par crédit différent selon le package.
En gros, la valeur équivalente calculée de mes crédits utilisés jusqu'à présent se situe donc entre environ 829 $ et 995 $. La valeur inférieure résulte du gros package de 6 000 crédits, la valeur supérieure du calcul à 0,20 $ par crédit pour les packages plus petits.
Je ne dirais donc pas que l'application m'a coûté exactement la somme X. Ce que je peux affirmer de manière fiable, c'est : Belote Tunisienne a jusqu'à présent consommé environ 4 975 crédits.
Pour moi, c'est particulièrement intéressant par rapport au développement personnalisé classique. Une application avec des règles spéciales tunisiennes, un mode multijoueur, des adversaires IA, des publications Android, AdMob, des problèmes de consentement et de nombreuses corrections d'interface utilisateur aurait très probablement coûté beaucoup plus cher avec une équipe de développeurs classique. Malgré cela, l'effort personnel reste élevé : il faut tester, vérifier, prioriser, identifier les erreurs et gérer proprement la logique métier.
AdMob : La publicité n'est pas seulement « saisir des ID »
Une grande partie du travail a également porté sur AdMob.
À première vue, cela semble simple : on crée une application dans AdMob, on génère une unité d'annonce bannière et une unité d'annonce interstitielle, on copie les ID dans l'application et c'est tout.
En pratique, plusieurs sujets supplémentaires sont apparus :
- ID de test vs. véritables ID AdMob
- ID d'application dans
app.json - ID d'unité dans la configuration des annonces
- Nouvelle build native après modification des ID d'application
- Message de consentement GDPR
- Google User Messaging Platform
- Dialogue de confidentialité et de consentement
- Profil de paiement AdMob
- Association de l'application au Play Store
app-ads.txt- Site web du développeur dans la fiche du Google Play Store
Un problème concret était qu'AdMob ne pouvait pas confirmer l'application parce que le site web du développeur manquait dans la fiche du Play Store. Par conséquent, AdMob ne pouvait pas trouver correctement le fichier app-ads.txt. La conséquence : la publicité peut être très faible ou ne pas être diffusée du tout.
Ce fut pour moi un bon exemple que la monétisation n'est pas seulement un problème de SDK. Il faut la chaîne complète :
Fiche Google Play Store
→ Site web du développeur
→ app-ads.txt
→ Vérification AdMob
→ Message de consentement
→ Véritables ID d'annonces
→ Nouvelle build native