dopop
Céroce
Membre, Modérateur
Bonjour à tous,
Après de longs mois de travail, je vous présente dopop. Il s'agit d'un ensemble de jeux pour apprendre le solfège (sur iPhone).
Je ne vais pas m'étendre sur le principe, toutes les infos se trouvent là : http://www.dopop.net.
Tout d'abord, je tenais à remercier les membres de ce forum qui ont testé les pré-versions, et m'ont donné quelques idées, et du courage pour avancer le projet. Je n'ai pas intégré toutes vos idées, c'est parce qu'il y avait d'autres priorités. Pour l'instant, je me suis avant-tout attaché à faire un jeu jouable, intéressant et pédagogique.
Puisque nous sommes ici pour parler de programmation, je vais partager les difficultés que j'ai eu.
Sprite Kit
La première version était jouable en juin. Cependant, elle était basée sur l'animation de UIViews, et même si j'aurais pu en rester à cette solution, je lui trouvais plein de défauts:
- le code était crade
- les animations étaient parfois étranges, en particulier à cause des courbes Ease in-out de Core Animation.
- il était difficile de faire des transitions d'écran, ou même d'ajouter des petits éléments marrants.
Ce que j'aurais pu faire était d'utiliser Cocos2D dès le départ, seulement, je n'aime pas cette bibliothèque dont les API sont mal fichues et l'intégration avec UIKit encore pire. Quand Apple a annoncé Sprite Kit à la WWDC, j'ai tout de suite essayé et j'ai été séduit.
Je ne regrette pas cette décision, même si elle a le défaut de limiter le jeu à iOS 7. Finalement, Sprite Kit a bien eu quelques bugs et quelques incohérences dans sa conception, mais tous mes radars furent corrigés pendant l'été, y compris ceux relatifs à Xcode 5.
Sprites et polices de caractères
Ceci m'a fait perdre beaucoup de temps. Je voulais utiliser un format vectoriel pour les notes et la portée. Mon idée était de créer une police de caractère pour cela. En pratique, dessiner les éléments dans Sketch fut rapide, par contre, il fallait utiliser un logiciel pour créer la fonte, et là c'est la cata. En gratuit, le moins pire est FontForge, mais il faut l'installer avec MacPorts, il fonctionne sous X11, et ça se voit.
Ensuite, je pouvais certes dessiner la portée avec la fonte, mais il y avait toujours des problèmes de taille ou d'alignement, d'un pixel ou un demi-pixel. Un beau jour, je me suis dit: " fini c'est conneries ! ". J'ai exporté mes graphismes en bitmap, je les ai mi dans le projet Xcode et je n'ai plus eu de problème.
La leçon apprise: les sprites, par définition, sont des bitmaps.
Niveaux
Une des difficultés quand on crée un jeu vidéo, est qu'il faut définir les niveaux. Pour ma part, j'ai créé un langage un peu spécial pour cela. Par exemple:
[T=76 (F3 G3 A3 B3 C4)%12]
Les [ ] délimitent le niveau.
T=76 indique le tempo.
F3 G3 A3 B3 C4 sont des notes (une lettre qui donne le nom de la note, suivie de l'octave).
Enfin, %12 indique qu'il va falloir répéter aléatoirement ces notes 12 fois.
Ce système me permet de décrire précisément le niveau, tout en n'ayant pas à écrire toutes les notes (dans cet exemple il y a 5x12 = 60 notes).
La première difficulté fut de créer un parseur pour ce format. Je n'avais aucune expérience dans ce domaine. Au final, je m'en suis sorti avec des regex et une sorte de machine d'état.
La deuxième difficulté fut de doser la difficulté: les premières versions était quasiment injouables. Il a aussi fallu réduire la durée des niveaux. Vous verrez que le jeu est encore assez difficile, et que vous perdrez souvent: c'est normal. On gagne quand on sait les notes, or cela demande des répétitions pour mémoriser.
Son des notes
Là encore, une grosse perte de temps. Il est important dans le jeu que les notes soit dites. En effet, le but n'est pas que vous deveniez bon à taper sur le clavier à l'écran, mais vous mémorisiez les noms des notes.
Mon idée de départ était de m'enregistrer à chanter toutes les notes: do ré mi fa sol la si, mais aussi A B C D E F G, puisque le logiciel permet de changer de notation. Il fallait le faire pour toutes langues. Le résultat fut décevant. Franchement, c'était horrible, tous les testeurs me l'ont dit.
Une deuxième piste était de créer un synthétiseur vocal chantant. J'ai fait un peu de recherche, et même si ce que je voulais restait simple, j'ai vite compris que c'était un travail bien trop gros.
Au final, la version actuelle est un compromis: j'ai utilisé le synthétiseur vocal introduit par Apple dans iOS 7, et je joue la note en même temps.
D'ailleurs, jouer la note n'a rien de simple. Je ne suis pas sûr que ce soit la technique la plus facile, mais j'ai carrément créé un synthétiseur basé sur une AudioQueue. Le synthé sonne vraiment bien, c'est une grande fierté.
Organisation
C'est la première fois que j'écris un jeu vidéo. J'avais bien quelques idées sur la manière de faire, mais pas vraiment d'expérience. La difficulté fut donc de savoir comment organiser l'appli. Déjà , j'ai respecté le principe du MVC, avec succès. Ensuite, la conception a émergé progressivement, au fil des remaniements. Au final, ce n'est pas parfait, mais c'est assez modulaire, assez gérable.
Achats in-app
à‰tant dans le cas le plus simples (achats non-renouvelables), je pensais que ce serait vite réglé, en fait, ça m'a pris une semaine. Pour ceux qui n'en n'ont jamais faits, disons qu'il faut gérer la transaction, et surtout, présenter tout ça dans une interface utilisateur perso, Apple ne fournissant rien de standard.
Au final, le code n'est pas très lourd, mais il y a un tas de petits détails à régler. La doc d'Apple est répétitive et manque d'exemples (comment savoir si un achat a déjà été effectué ?).
Voilà , si vous avez des questions ou des commentaires, ils sont les bienvenus.
Réponses
Au final, on achète quoi avec les in-app ? Des niveaux ?
Je pensais que l'application serait payante quand-même. Tu nous donneras tes retours sur ton in-app.
EDIT : ah oui des niveaux.
Je l'ai téléchargé.
Je n'avais pas eu la version avec le synthétiseur. C'est vrai qu'il s'en sort bien !
Ah ok, vu le cadenas, je pensais qu'il fallait payer dès le niveau 4.
Dans ce cas, pourquoi le niveau 3 est marqué "fond blanc" alors que je ne l'ai pas encore réussi ?
Il faudrait p-e une icône différente pour différencier les niveaux non faits des niveaux à acheter ?
Je n'ai pas voulu me prendre la tête, parce que de toute façon, on ne peut pas finir un niveau qu'on n'a pas acheté.
J'ai 2 choses à dire :
Bravo !
Et merci pour ce retour d'expérience très riche
Et je "plussoi", les achats InApp, rien de bien compliqué mais fastidieux...
Félicitations ! Moi qui cherchais quelque chose de ludique pour faire bosser le solfège à mon gamin, je suis comblé.
My 2 cents:
Désolé si ce message apparaà®t un peu négatif, mais ce n'est pas du tout le cas. J'aime beaucoup ton app et j'ai bien l'intention de l'utiliser avec mon gamin et de la montrer à mon prof.
Ce n'est pas un bug, c'est un choix pour ne pas rendre le jeu trop facile. Autrement, quand il ne te resterait plus qu'une vie, il vaudrait mieux perdre pour recommencer le niveau avec 3 vies.
Le jeu peut être mis en pause et être quitté à tout moment. Je préfère que le joueur reste immergé dans le jeu.
Pas tout à fait. En fait, le moteur de jeu est déjà en marche quand se fait le décompte. En pratique, ce qu'il faut que je fasse est de désactiver le clavier quand il n'y a pas de notes à l'écran. Je ne l'ai pas encore fait, parce que savoir s'il y a des notes à l'écran n'est pas si simple !
C'était le cas dans les premières versions, mais ça ne donnait pas bien. La limite coupait la portée juste après la clef. Il y a sans doute un axe de progrès de ce côté.
C'est une idée de Yoann... mois aussi, je suis fan !
J'y ai pensé, j'ai même une solution, mais je ne suis pas très sûr, parce que je ne veux pas rendre l'affichage des niveaux trop complexes.
Je comprends, mais là encore, il faut garder les choses simples, je pense. Ce n'est pas très grave de jouer 20 niveaux " faciles ", je crois.
Non, le but de l'exercice est d'apprendre à lire les notes selon leur hauteur. Je me suis posé la question; les dièses et bémols étaient d'ailleurs présents dans la première version. Mais quand tu y réfléchis, là encore, ça complique le jeu sans apport pédagogique évident. De plus, le clavier est déjà petit " plus petit, ce serait injouable " alors j'ai décidé que les seules les touches blanches seraient actionnables.
C'est prévu dans une prochaine version !
Dans un sens, le problème est que le clavier ressemble à un clavier de piano. Je me suis demandé si je n'allais pas retirer les notes noires; je les ai laissé parce qu'il faut quand même des repères visuels.
Ce sera effectivement l'objet du prochain jeu. Il faudra taper l'écran en rythme. Je n'ai pas encore commencé sa programmation, je réfléchis au concept.
Je te remercie beaucoup pour tes remarques qui me font avancer et me confortent dans mes choix ou les remettent en cause.
L'appli t'aide, le nom des notes étant parfois écrit sous la portée. Notamment quand on voit une note pour la première fois.
D'après les essais, plusieurs personnes n'ont pas vu ce texte. Il va falloir que je l'écrive plus gros ou que je trouve une autre solution.
Et la première journée sinon ?
71 téléchargements, zéro ventes la première journée complète. C'est à peu près ce à quoi je m'attendais.
(Quoi, on ne devient pas millionnaire en une nuit ?)
Tu ne devrais pas utiliser une boà®te de dialogue pour prévenir le joueur qu'il a perdu. ça fait trop "tech". Affiche plutôt un texte en surimpression, se déplaçant vers le haut de l'écran, avec un effet de disparition progressive, comme les bonus des jeux d'arcade.
Pourquoi ne pas utiliser un fond d'écran très légèrement jaune, suggérant l'idée d'un vieux papier ? Ou une texture de parchemin à peine visible ?
Le panneau en haut de l'écran me gêne, en écrasant visuellement l'espace de la partition. Le tempo, le niveau et les coe“urs/points de vie pourraient très bien être affichés en superposition sur la partition.
C'est pas étonnant si les niveaux payants sont après le 20è.
Il faut déjà avoir fait les 19 premiers... et avoir un bon niveau pour le coup. Trop bon niveau ? Là , est la question.
Non vraiment, aucune connaissance préalable n'est demandée. Par exemple, dans le premier niveau, un "sol" apparaà®t sous la note. Si l'utilisateur ne comprend pas qu'il faut appuyer sur la touche marquée "sol", je ne peux rien pour lui.
Après, je peux comprendre que tu n'aies pas vu l'indication. J'ai fait des essais avec des gens qui ne l'ont pas vu non plus. Il faut que je la rende plus visible.
Ce n'est pas faisable parce qu'il n'y a qu'un seul clavier (une seule octave) pour une portée qui peut en représenter 5. Si l'utilisateur appuie sur une touche, dans quelle octave dois-je afficher la note ?
Je sais que de nos jours, on n'y est plus habitué, mais perdre n'est pas grave. On recommence, c'est tout. L'apprentissage se fait par la répétition. Quelqu'un qui a beaucoup perdu a beaucoup appris.
Oui, je suis d'accord. J'ai fait au plus rapide à coder.
Parce que je suis tout seul sur ce projet et que je n'ai pas les moyens de payer décemment un graphiste. Donc, je fais au plus simple; il faut juste que ce soit propre.
Je suis d'accord, ça manque d'unité. Cependant, la portée peut comporter 5 lignes supplémentaires en haut et en bas. Je ne peux donc pas superposer les compteurs au risque qu'ils s'affichent par-dessus les notes.
En tout cas, merci beaucoup pour tes remarques.
ça représente environs 7 minutes de jeu en continu. Pour moi, c'est ce qu'il faut pour vraiment tester le jeu, et adhérer au principe... ou pas.
Je me demande dans quelle mesure tu ne pourrais pas enlever complètement le clavier de piano et le remplacer par des boutons avec les noms des notes. Le clavier me " gêne " pour plusieurs raisons :
- Les touches noires ne fonctionnent pas;
- On a juste une octave alors qu'on peut en afficher au moins 3 sur une armature;
- Et si on ne fait pas de piano ?
De plus, le risque au niveau de l'apprentissage est de faire directement le lien entre le symbole sur la partition et la touche sur le clavier sans passer par la note proprement .
À condition de pouvoir recommencer directement au niveau que l'on a échoué et pas au niveau précédent.
Avec du cuir de Corinthe ?
Je trouve au contraire que l'app est vraiment en phase avec l'esthétique iOS, le nom est sympa, l'icône est bien.
- ça manquera de repères visuels
- on ne comprendra pas bien où il faut appuyer. (Alors, que justement, tout le monde a déjà vu un clavier de piano et sait que ses touches s'enfoncent).
Pour l'instant, ça va donc rester ainsi. Je ne suis pas certain que ce soit un bon choix, mais pas non-plus que ce soit un mauvais choix.
Tu remarqueras que quand on perd, c'est souvent parce qu'on était déjà "limite" au niveau d'avant. Reprendre à un tempo inférieur me semble une bonne chose pour ancrer davantage les notes dans la tête.
Tu design une UIView avec les 7 boutons avec les noms des touches, une autre UIView avec le clavier (celle que tu as actuellement), et une préférence pour choisir entre les 2 et savoir laquelle utiliser.
Alors, là , c'est hors de question.
Moi, je crois ferme que décider fait partie de notre travail de designer. Ce que tu me proposes ne résout rien, parce qu'il faudra quand même que je choisisse le réglage par défaut (avec, ou sans touches noires ?). Les utilisateurs ne changeront probablement pas ce réglage: certains ne comprendront pas à quoi il sert, d'autres quelle est la meilleure option; enfin la plupart s'en moqueront.
De mon côté, il faudrait que je rajoute du code et que je teste les deux options. C'est du code en plus à déboguer et que je devrai maintenir par la suite.
Ne pas faire de choix complique la programmation et surtout, transfère la responsabilité à l'utilisateur.
Avoid Preferences
Dans le cas précis, j'admets que mon choix n'est pas forcément le meilleur pour tout le monde, mais je n'admets pas que ça pénalisera les utilisateurs qui auraient préféré l'autre option.