Sujet:
Salut à tous !
Pour me lancer dans Unity, j'ai démarré un projet juste assez modeste pour bien apprendre, mais assez ambitieux pour me prendre pas mal de temps. J'ai récemment terminé un premier prototype, le moment idéal pour commencer à partager le développement.
Virtual Bongo Session est un jeu de rythme aux mécaniques simples, mais exigeantes. Une image valant mieux que deux tu l'auras, en voici une qui illustre très bien le concept et l'avancée du développement :
(Je ne garantis malheureusement pas la présence du triangle dans le jeu final)
Un concept que presque tout le monde a rencontré au moins une fois : un motif est joué, le joueur doit le répéter.
Le jeu est construit autour de morceaux de musique composés de boucles qui se répètent tant que le joueur n'a pas joué correctement le motif. L'instrument joué est le bongo, avec deux touches pour deux bongos gauche et droite. Le fait d'utiliser deux doigts permet d'avoir des enchaînement rapides de double-croches, et donc des motifs rythmiques d'une plus grande richesse.
***
À l'heure actuelle, j'ai un prototype fonctionnel ! J'arrive à suivre le rythme d'un morceau, lire et jouer une grille de notes, et valider les coups du joueur pour passer à la séquence suivante.
Je suis particulièrement soulagé de ne pas avoir trop de problèmes de synchronisation audio ! 
Les boucles se répètent et s'enchaînent bien, donnant le rendu fluide et ininterrompu escompté. De même, j'ai pu corriger le délai de l'input en paramétrant le projet Unity pour optimiser la synchronisation audio. Je croise les doigts pour ne pas avoir de soucis de performance plus tard, mais pour l'instant le jeu répond très bien.
Seul petit élément de doute : la lecture des inputs et la gestion du délai. Quand le joueur donne un coup, je calcule la demi-croche la plus proche. C'est à la fois précis et ce qu'il faut de permissif. Seulement ça impose de se baser sur la demi-croche (voire le quart de croche si le bpm est très lent) à chaque morceau, même quand on ne veut que des grilles jouant sur la croche. J'hésite du coup à rajouter un "délai maximal", qui estimerait que si l'écart entre chaque "beat" et l'input est de plus de 0.x secondes, le beat joué vaut -1.
Pour l'instant ça serait rajouter du calcul pour rien (la demi-croche étant bien assez précise), mais peut-être que ça pourrait être utile à anticiper (et permettrait de ne pas compter 16 beats sur des mesures en 4/2).
***
Concernant ce qu'il me reste à faire à présent… Bah, tout le contenu du jeu en fait. 
Je vais commencer par les menus, comme ça ce sera fait. Et j'apprendrai dans le même temps comment gérer plusieurs Scènes dans Unity.
Les grosses difficultés à venir sont :
- Composer les musiques. Bah oui. Là je vais pouvoir me mettre à fond dans la composition, ce qui était un de mes objectifs de l'année ! Et cette fois-ci il faut que ça sonne bien, la musique étant un poil au cœur du jeu. La contrainte de boucles m'intéresse, et je compte partir dans de l'électro jazz avec un peu de surréaliste. Je posterai mes inspirations plus tard.
- Établir un univers graphique. Je suis encore dans le flou total. J'imaginais initialement partir sur ma principale inspiration, Rhythm Paradise, avec du mignon et coloré. Mais vu l'univers sonore du jeu, je me suis ensuite demandé si je ne devrais pas aller vers le digital ou psychédélique, avec des figures géométriques et des couleurs froides à la Tron. Et à présent j'hésite même à faire dans le minimalisme et laisser tomber le figuratif ! Dans tous les cas, les décors devront aussi bouger en rythme. Bref, gros chantier en perspective.
- Créer un tutoriel. Je veux enseigner les mécaniques de manière fun. Je sais déjà comment sera la forme, reste à savoir comment programmer et scripter ça. Je suis toujours dans le flou quand il s'agit de faire des dialogues et cinématiques, et là on est à fond dans des trucs scriptés ! Eh, au moins j'apprendrai bien des choses.
Plus qu'à voir où cela me mènera ! Je suis satisfait de ma vitesse de croisière jusque-là, j'espère pouvoir terminer d'ici la fin de l'année.
Il y a quelques autres petites features que je n'ai pas encore mentionné. J'en parlerai en temps et en heure ! 
Salut,
Ton projet a l'air très sympa, hâte d'en voir plus, et surtout d'en entendre les premières pistes musicales !
Pour ta problématique des délais et input, je ne suis pas sûr d'avoir bien compris : la rythmique du joueur est approximée à la demi-croche près, c'est ça ? Si c'est bien le cas (et si je peux me le permettre) cela me semble un choix discutable, car cela voudrait dire que la tolérance est à géométrie variable, selon le tempo du morceau : il me semblerait nettement plus judicieux de prendre ne compte le délais absolu (en fraction de secondes) entre la note jouée et la note la plus proche, indépendamment du tempo. Cela garantirait une homogénéité de la précision demandée, et serait surement bien plus naturel à appréhender pour le joueur (qui au final essaiera d'être le plus précis possible, et dont l'imprécision des réflexes se comptera en terme de fractions de secondes indépendamment du tempo du morceau joué). Avoir une précision plus élevée qu'1/4 de temps me parait aussi important, pour permettre de graduer le succès du joueur entre "accepté" et "perfect" (avec d'éventuels intermédiaires), et donc de permettre d'être autant permissif pour les joueurs occasionnels qu’exigeants pour les plus chevronnés, et de pousser les joueurs à s'améliorer.
Donc pour faire simple : il faut à mon avis que tu aies une routine qui calcule la "distance" (temporelle) absolue (en fraction de seconde) entre la frappe et la note la plus proche, et à partir de la valeur renvoyée en déduire si c'est (p.ex.) "faux", "ok" "très bien", "excellent" ou "perfect". En plus, partant de là, tu pourras toujours indexer secondairement ce jugement au tempo du morceau en cours, par la simple adjonction d'une variable ; mais je pense que tu réaliseras alors que ce n'est pas une très bonne idée :P.
Tu as bien compris le problème !
Aujourd'hui la précision est au quart de temps, et lorsque le joueur appuie sur une touche, on calcule la demi-croche la plus proche. Et le quart de croche, ça se joue aussi à la fraction de seconde. Est-ce que ça vaut le coup de prendre une valeur arbitraire pour invalider une note, et si oui laquelle ?
En fait, on peut se poser la question avec ce schéma :
Pour une demi-croche, on a un interval t avant et après qui valide l'entrée pour cette note. Du coup entre deux demi-croche, il y a les zones pour la note précédente et la suivante, et un potentiel interval vide d qui ne correspond à aucune note.
Le dilemme : que devrai valoir t ? Comment le calculer ?
S'il est plus élevé que la moitié de la distance entre deux demi-croches, alors ça ne sert à rien de l'avoir puisque d sera nul. On revient sur le calcul précédent. D'ailleurs, avec ou sans d, on choisit toujours la note la plus proche au final. La question, c'est uniquement la présence de d.
Dans ce cas, on rajoute une probabilité de tomber dans un espace invalide selon qu'on soit trop tôt ou trop tard. Forcément plus exigeant, mais comment savoir à quel niveau ? Au niveau de la demi-croche, l'écart est difficilement perceptible. Quand le joueur est trop tard, c'est souvent qu'il est à la note d'avant ou après.
Et l'immense soucis qui entre en jeu là dedans, c'est l'input lag. Qui dépend du joueur, mais aussi de la machine. Faut-il calculer t dynamiquement après un calibrage ? Cela résout-il des problèmes ?
Pour ce qui est de la notation, j'ai l'intention de me baser plutôt sur le nombre d'essais pour chaque mesure. La moindre note non correcte invalide la mesure et la fait recommencer. Si le joueur arrive à jouer une mesure du premier coup, peu importe s'il était plus ou moins précis, on considère qu'il a joué le bon rythme parfaitement. Deux essais, et c'est juste bien, trois moyen, etc… Au final, le joueur terminera toujours un morceau, vu qu'il est obligé de réussir toutes les mesures. C'est le temps qu'il a mis en tout qui déterminera son score !
Le jeu récompense moins la précision arcade que le sens du rythme et le suivi d'un jeu musical. Ça permet aussi au joueur d'avoir un meilleur contrôle en temps réel de sa performance.
Merci du retour et des suggestions en tout cas !
Mes jeux sur itch.io
Mes vidéos sur Youtube
Mes reins sur ebay (pas encore disponible)
A mon sens le problème d'utiliser le quart de temps c'est le caractère mouvant que cela représente, la précision demandée devient variable d'un morceau à l'autre, dépendant du tempo, ce qui peut perturber le joueur et t’empêcher de facilement contrôler la difficulté (qui devient à géométrie variable). Tu me diras que tu émets peut-être l'hypothèse que plus un tempo est rapide plus le joueur est spontanément précis dans ses rythmiques, et qu'il est dés lors plus pertinent de raccourcir les délais tolérés en rapport avec la vitesse du morceau. J'aurais perso tendance à penser que la réactivité est plus une question de secondes (en tant qu'unité je veux dire, pas en tant qu'ordre de grandeur ;)), mais au final il faudrait pouvoir tester les deux config pour savoir.
L'avantage de mesurer le délais en seconde, c'est que tu peux toujours à partir de là en déduire la fraction de tempo que tu veux. Dans l'autre cas, si tu approximes à un quart de temps, tu te retrouves avec une info vachement imprécise à partir de laquelle tu auras du mal à déduire grand chose d'autre. En plus il sera surement important d'ajuster assez finement le délai toléré pour assurer de bonnes sensations de jeu : que certes ça ne soit pas trop dur, mais que le suivi de la rythmique reste suffisamment exigent pour impliquer le joueur et lui faire ressentir la musique ! (c'est quand même ce qui fait l'attrait de ce genre de jeu il me semble, et si la tolérance est trop molle les sensations peuvent être franchement dégradées). Or tu auras infiniment plus de facilité à ajuster ce paramètre si tu peux le régler au centième de seconde près, que si tu t'es coincé dans des considérations en quarts de temps. Tu pourras de toute façon toujours ajouter une variable qui fasse automatiquement varier cette tolérance en fonction du tempo, si les essais te montre que cette mécanique est plus plaisante ou naturelle ; et même tu pourras réaliser une forme hybride : une tolérance variable selon le tempo, mais pas proportionnellement, plutôt selon une valeur que tu pourras définir spécifiquement pour chaque morceau.
Et pour répondre précisément à la question que tu poses : oui il faudra bien définir un délais arbitraire au-delà duquel une note est invalidée. Qu'on parle d'un choix en seconde ou en fraction du tempo, ça reste arbitraire (pourquoi 1/4 de temps plutôt que 1/8 de temps ... ou que 2/10 de temps ?) Et tu devras définir ce délais de façon empirique, en testant différentes valeurs jusqu'à trouver celle restituant à ton sens la meilleure expérience de jeu (ce qui restera de toute façon en partie subjectif ;)).
En passant, il est également important que des notes en excès soient aussi considérées comme des "fautes", parce qu'elles peuvent se trouver dans l'intervalle de tolérance d'une autre note ... mais si cette note est sensée avoir déjà été jouée, il y a bien une "faute" de la part du joueur ; il ne faut pas oublier de prendre cela en considération.
Pour la notation, j'aurai tendance à te conseiller d'utiliser une fusion des deux méthodes : prioriser le nombre d'essais pour la note finale, mais récompenser malgré tout par un surplus de points les joueurs les plus précis ; tu peux même imaginer un système de combo, qui peut être double : par segments successifs sans erreurs, et par notes successives en "perfect" (avec logiquement plus d'effet). Mais de toute façon ces mécanismes pourront être assez facilement implémentés secondairement si tu t'orientes vers une mesure du délais en seconde ; et tu peux sans problème t'en tenir dans un premier temps à la considération binaire "note valide ou non valide".
Enfin, pour tes craintes relatives à l'input lag, je ne sais pas si ce sera si significatif que ça. Dans un jeu de shoot p.ex. je n'ai jamais eu l'impression que les tirs ne soient pas coordonnés avec mes appuis sur la gâchette. A voir ce que tu constates en pratique ?
Après tu peux toujours proposer un réglage permettant d'étalonner le jeu à l'aide d'un retour visuel, ça peut p.ex. prendre la forme d'une barre verticale défilant horizontalement en continue et d'un repère fixe : lorsque la barre passe précisément sous le repère, le joueur doit presser une touche (espace p.ex.), une empreinte de la barre (en rouge p.ex.) reste alors affichée là où le jeu a enregistré l'appui (idéalement il serait bon de pouvoir cumuler les empreintes, voire ajouter un effet d'estompage des précédentes empreintes à chaque fois qu'on en crée une nouvelle ; car le joueur aura besoin de cumuler plusieurs essais pour avoir une chance de faire la part des choses entre un décalage lié à l'input lag et un lié à sa propre imprécision ; et il peut être intéressant de pouvoir identifier facilement les empreintes récentes des anciennes, et même de faire disparaitre les trop anciennes pour garder une bonne lisibilité).
L'idée est que le curseur réglant la compensation du lag entraine la translation des empreintes selon le décalage correspondant : il suffit donc, une fois qu'on a un ensemble d'empreintes bien groupées qui paraissent de qualité, de les aligner sur la flèche de référence en modifiant la valeur de compensation. Et on peut en temps réel continuer les tests avec la barre verticale mobile qui poursuit toujours sa course. La compensation du lag est au final une simple variable que tu additionneras en jeu au timing du joueur avant d'évaluer sa précision.
Bonne nouvelle : le jeu a un menu principal ! \o/
Découvrir l'API de GUI de Unity ne fut pas de la tarte. Au final elle est bien fichu, mais il faut la dompter ! Surtout quand on vient du développement web où… euh… non en fait j'ai rien dit.
Des apprentissages que j'ai pu en tier, les principaux sont :
Ce dernier point m'ayant permis d'implémenter les niveaux de difficulté ! Je pensais faire ça bien plus tard, mais finalement vu que ce n'était pas bien dur à construire, c'était un bon prétexte pour utiliser pleinement les menus.
En quoi ces niveaux diffèrent-ils ? Eh bien il y a d'abord le Facile, que vous connaissez déjà :
Ensuite vient le Normal, qui est tel que le jeu a été imaginé au départ :
Et enfin, ben, le Difficile :
Une petite médaille (et un bonus) étant accordé à ceux battant ce dernier mode.
***
Le menu est donc quasiment terminé. Le principal est là, le reste relève du détail, ce sera traité en temps et en heure. Maintenant je vais me changer les idées avec… la musique !
Ça me libérera un peu de la doc de Unity et des stackoverflow sur le C#.
Pour le premier morceau, je suis parti sur quelque chose s'inspirant de deux titres. Ma première et principale référence est Troupeau Bleu de Cortex. Non, on ne parle pas du rappeur, mais du groupe de jazz-funk des années 70 !
J'adore leur atmosphère, et leur jeu rythmique est fantastique.
Ce funk un peu rétro, je souhaite le mélanger progressivement avec de l'électronique, et lui donner la pêche du morceau Animal Chin de Jaga Jazzist. Un groupe électro-jazz qui fait dans l'atmosphérique, et crée des sonorités souvent folles.
Pour le moment j'ai tout juste commencé la composition. J'ai passé pas mal de temps pour sélectionner des banques sonores d'instruments, et trouver des accords intéressants. Le solfège remonte à loin, et je redécouvre à quel point les neuvièmes dominantes sont diaboliques !
J'ai tout de même une petite ébauche ! Vous pouvez l'écouter par ici pour vous faire une idée du style.
Il est bien sûr certain que cela va évoluer. En tout cas j'y prend beaucoup de plaisir !
***
Enfin, petites notes techniques sur ce qui était discuté plus haut.
Après réflexion, je vais imposer un délai entre les croches. Jusque-là, si j'avais choisi la précision au quart ou huitième de temps, c'était avec l'idée de prendre « l'intervalle le plus court possible qui reste intéressant musicalement et réalisable humainement ». Et finalement, le délai peut reprendre la même idée ! Je vais mesurer à quel rapidité je peux appuyer sur les touches gauche et droite du clavier, et prendre la moyenne (ou deux tiers pour être tolérant) comme limite avant et près chaque note. Cela améliorera effectivement la précision sur les morceaux trop lents pour le quart de note mais trop rapides pour le huitième.
Pour les « notes en excès », aucun soucis, c'est prévu depuis le départ ! En fait, le système prend une grille de partitions définissant les croches à jouer pour chaque double mesure. Il joue ces croches dans la première mesure, écrit la partition jouée par le joueur dans la seconde, puis compare les deux. Ainsi, pour par exemple une mesure de quatre noires en 4/4, la mesure sera [0, 4, 8, 12], et ne sera pas validée si le joueur fait [0, 4, 4, 8, 12] !
Avec le délai absolu, on rajoute la notion de fausses notes qui se traduiront en -1.
Enfin, je laisse de côté le calibrage du jeu. Cela soulève trop de questions pour un problème purement hypothétique, et difficile à reproduire. La notion de « correctif » peut tout aussi bien palier des faiblesses de la machine qu'elle peut fausser le rythme du joueur ou invalider tous ses inputs s'il gagne en réflexe au fil du jeu… Certains jeux de rythme s'en passent sans soucis (notamment le fantastique Rhythm Doctor), donc l'idéal sera d'avoir un jeu fluide avant tout.
Mes jeux sur itch.io
Mes vidéos sur Youtube
Mes reins sur ebay (pas encore disponible)
Un peu de neuf ! Déjà, la composition avance bien.
Ensuite, j'ai enfin trouvé des idées pour le design !
Pour rappel, j'étais parti sur quelque chose proche de Rhythm Paradise (dont il faut impérativement que je me procure le dernier épisode sur 3DS). J'avais alors en tête une scène de concert, qui donnerait quelque chose dans ce genre :
Les points essentiels :
Le problème avec cette vision, c'est qu'elle est impersonnelle. Je l'ai imaginée avec Rhythm Paradise en tête, mais il fallait que je m'en écarte pour trouver une identité au jeu. Seulement je suis resté focalisé sur ce schéma : une scène, un joueur à gauche, un joueur à droite.
L'autre gros soucis, c'est que ce plan laisse beaucoup de vide à combler ! Une scène, ça doit être un peu grand. Comment la remplir ? Un orchestre ? Des décors ? Des jeux de lumières ? Faut-il aussi esquisser la silhouette d'un public ? Tout cela doit être animé. Sans parler des personnages, qui doivent être un minimum charismatique ! Une charge de travail conséquente qui dépasse de loin mes talents actuels.
Et récemment j'ai eu l'idée qui m'a permis de changer complètement le cap, tout en conservant les points fonctionnels essentiels.
Déjà j'ai eu envie de prendre une esthétique abstraite, minimaliste et flashy telle que celle de 140 ou l'intro de Jazzpunk. Couleurs vives, palettes simples, forts contrastes et formes géométriques.
Ensuite j'ai eu le déclic qui m'a permis de me débloquer : mettre les mesures n'ont pas en haut, mais au centre, et les utiliser pour faire une séparation verticale !
Le rendu :
On conserve les aspects importants du schéma précédent. Notamment la dualité : deux bongos, deux mesures, deux batteurs… Seulement ici, plus de personnages ! Uniquement les bongos, davantage mis en avant. On occupe déjà beaucoup mieux l'espace !
Liste des différences dans les approches :
On a donc un rendu de base qui a plus de pêche (par les jeux de lumière et les animations), et qui permet aussi de décorer plus facilement ! Déjà je peux jouer avec différentes palettes de couleur par morceaux, avec trois ou quatre couleurs qui peuvent varier. Ensuite j'ai déjà des idées pour le fond, avec des formes rectangulaires qui s'animent avec la musique et avancent de droite à gauche pour donner l'illusion d'un scrolling horizontal (ce que ne permettait pas le statique de la scène). Même les menus peuvent être faits dans la même veine !
Une bonne étape de franchie donc ! J'ai enfin une idée claire sur l'esthétique, et ça me semble largement réalisable. Les bongos seront le plus dur, ensuite des rectangles, et qui sait, peut-être même un triangle !
Mes jeux sur itch.io
Mes vidéos sur Youtube
Mes reins sur ebay (pas encore disponible)
Grandes avancées de faites, récemment !
Premièrement, le premier morceau a fini d'être composé ! Mieux encore, sa "partition" dans le jeu est écrite, ce qui fait qu'il est dors et déjà jouable !
En voici la première partie (la suite se découvrira dans le jeu) :
Vous noterez au passage un changement de nom. Celui-ci est plus en adéquation avec le nouveau design et a une "rythmique" plus plaisante.
***
Ensuite, je me suis attelé à l'esthétique du jeu. On sort enfin du prototype. Ça me permet d'avoir déjà des visuels bien plus sympa :
Ce n'est pas encore complet, il me reste à rajouter un arrière plan un peu plus vivant. Ca restera des rectangles défilant de droite à gauche, avec la hauteur variant avec le volume de la musique. Pourquoi pas ensuite quelques particules, suivant le mouvement latéral. Également, il va falloir que le centre de l'écran soit plus bavard !
Autre chose qui sera implémentée très rapidement : la configuration des couleurs. Pour l'instant elles sont écrites en dur, mais je compte bien avoir pour chaque morceau une couleur de fond, d'instrument et de décors différents.
***
Enfin, petites notes sur la jouabilité : j'ai pu rajouter un délai de validation avant et après les notes. Le joueur a
0,6secondes pour appuyer sur la touche au bon moment.Ça peut paraître énorme, mais les essais ont montré que le jeu est déjà bien dur de cette façon ! Je rappelle que la moindre fausse note force à recommencer la mesure. Et rien qu'avec un écart de
0,5, le jeu devient frustrant et très tendu. Au final la philosophie du jeu n'est pas d’exiger une précision absolue par note individuelle. Je cherche plus à encourager le joueur à comprendre le rythme de la musique et le faire entrer dans le « courant ».Edit : Petite erreur sur les valeurs ! Je veux bien un écart important, mais plus de la moitié d'une seconde, c'est quand même balèze.
Je parle en réalité de 0,06 et 0,05 secondes ! D'ailleurs, en relisant le code, il s'avère que j'ai opté pour 0,055.
Ça reste quand même bien dur. Je n'ai personnellement pas encore réussi à obtenir le Parfait.
Mes jeux sur itch.io
Mes vidéos sur Youtube
Mes reins sur ebay (pas encore disponible)
Pas mal de nouvelles ces temps ci ! J'ai du mal à trouver du temps libre pour avancer sur ce projet (sachant que j'en ai déjà un autre), mais il progresse tout de même.
Tout d'abord, j'ai pu travailler sur la gestion du score et des feed-back. Un sujet finalement assez délicat, sur lequel j'ai du experimenter un peu avant de trouver un bon équilibre qui amène un dialogue entre le joueur et le jeu. Vous pouvez lire cette rétrospective sur le sujet (en anglais).
Je reviens d'ailleurs sur un point qui y est mentionné : le jeu est dur. Le délai entre chaque note est dur à équilibrer pour ne pas être trop strict, sans pour autant tout accepter. Plus haut, je parlais de 0.055 secondes, j'ai finalement changé ça en 0.056 (le Morbihan, en tant que Vannetais j'aurais dû deviner). Oui, un millième de seconde ça change énormément !
Mais j'ai peur que la précision confortable soit relative à chaque joueur. Aussi, il va vraiment falloir que je fasse un écran de calibration. Plutôt qu'un délai fixe, il sera mesuré en fonction d'un test (disions que le troisième quartile des performances du joueur).
***
Mais ça c'est pour plus tard. Pour l'instant, voilà quelques screens de ce sur quoi je viens de travailler : le look !
En chantier aussi, une refonte du menu, reprenant l'idée de tuyaux traversant l'écran.
Pour le jeu, je suis content d'avoir pu mettre en place ce scrolling infini ! Ce fut assez délicat, et la raison pour laquelle il y a un espace (réglable) entre les barres est que celles popant à droite ne sont pas toujours bien collées, bien qu'étant toutes à la même vitesse.
Il manque encore des particules qui traverseront l'écran à différentes vitesses, donnant je l'espère un effet parallax qui créera de la profondeur. Si je trouve encore les bongos un peu statique par rapport au reste, ça me semble plutôt cool dans l'ensemble. D'autant qu'encore une fois, toutes les couleurs sont configurables pour chaque morceau.
***
Maintenant je vais aborder un autre problème, sur lequel je me pose encore quelques questions. C'est encore lié à la difficulté du jeu, et à la limitation de la frustration.
Le problème est tout simple. Selon vous, est-ce que les points sont alignés dans cette image ?
On serait tenté de dire oui juste d'un regard, mais en réalité…
L'écart est bien là. Seulement, le jeu n'a qu'une moitié de seconde après pour le voir. Une fois la mesure terminée, on efface tout. Dans le feu de l'action, le joueur est trop concentré pour examiner de près l'alignement. Donc ce qu'il se produit souvent, c'est qu'il les trouve a priori alignés, et juste après le jeu lui dit que non, ils ne l'étaient pas. Sans que le joueur n'ait moyen de savoir lequel (ou lesquels) n'était pas correct, et s'il était trop tôt ou trop tard.
Si vous remontez plus haut, ce soucis n'existait pas dans l'ancienne version de la présentation : les points étaient les uns en dessous des autres. On constatait immédiatement lesquels ne collaient pas. Ici, on les a écarté, et c'est beaucoup moins lisible ! On perd une bonne partie de l'intérêt d'avoir ces partitions.
J'ai cherché plusieurs solutions, et celle me semblant la plus optimale pour l'instant est d'ajouter une grille sur l'écran. Le joueur sait s'il joue dans la mesure, et voit plus facilement l'alignement.
Ce qui m'embête c'est que ça charge quand même bien l'écran. De plus, ce côté "grille" est assez austère, et donne une vision trop mathématique du jeu.
Autre idée, créer des beats "fantômes" qui, avec une animation, se positionneront au centre de l'écran :
Mais reste à trouver comment les représenter, sans que ça ne fasse bizarre. Et c'est une manière un peu trop convulsées à mon goût de régler le problème. On tort la logique simple du jeu pour rajouter des machins par dessus… Sachant qu'en cas d'erreurs, il faudrait conserver ces beats pour que le joueur puisse les voir. Mais en cas de succès, on les efface ?
Pour le moment, je vais partir avec la solution 1, en essayant de la rendre esthétique. Mais ce n'est pas dit que ça n'évolue pas par la suite. Si vous avez des suggestions, elles sont bonnes à prendre !
Mes jeux sur itch.io
Mes vidéos sur Youtube
Mes reins sur ebay (pas encore disponible)
Bonne année 2017 tout le monde !
Aujourd'hui, on a des bonnes nouvelles, et des mauvaises nouvelles.
Commençons par la bonne : Bongo Machine est disponible en open beta !
Pile fin 2016. Disponible pour Windows, Linux, et peut-être Mac (je n'ai pas pu tester la build, donc… à vous de me dire si vous avez l'envie d'essayer !).
Obtenez le jeu ici !
La beta contient le premier niveau, et trois modes de difficulté. Elle se paye même le luxe d'avoir une musique pour son menu, chose que je ne pensais pas avoir le temps de faire avant le nouvel an !
Les scores ne sont en revanche pas sauvegardés. S'il existe des bugs divers (j'en connais déjà certains, huhu), merci de me les signaler !
Au fait, il y a un petit message dans le readme, je le détaillerai en fin de ce post.
***
Maintenant, pour les mauvaises nouvelles… Eh bien il y a que le jeu a de la latence sous Windows ! C'est très léger, mais suffisant pour, à mon sens, perturber complètement l'expérience. Pour un jeu de rythme, des décalages aussi infimes, ça joue.
J'ai longtemps cherché la cause, tenté plein de correctifs, mais sans succès. Peut-être Unity n'est-il pas adapté à des jeux de rythme nécessitant une très faible latence et une optimalisation maximale ?
Quoi qu'il en soit, si je ne parviens pas à corriger ce problème… Bah je vous avoue que je suis beaucoup moins intéressé à finir le projet ! Il s'en retrouve plombé dans son fondement même. Ou alors j'encourage tous les joueurs à passer sous Linux ? Haha…
Donc il est possible que je me contente de dernier bug fix pour ensuite laisser le jeu en beta. À la limite j’intégrerai la sauvegarde et les bonus. Mais ça sera plus intéressant pour moi par la suite de passer à un autre projet plutôt que de composer des morceaux pour celui-ci. Pas envie de me débattre avec ce qui ne devait être qu'un petit jeu de rythme, surtout si celui-ci n'est pas fonctionnel. Au final d'un point de vue personnel, j'aurai atteint mes objectif : me faire la main sur Unity, utiliser le rythme d'un morceau dans un jeu, et composer une bande son…
À vous aussi de me dire si vous avez une latence sur vos machines, et si elle vous gêne ! Le contraire m’étonnerait, mais sait-on jamais…
***
Au-delà de ça, j'aimerais revenir sur les histoires de timing dont j'ai parlé plus haut. En fait, après divers essais, il s'avère que même 0.056 c'est beaucoup trop tendu ! Je connais le niveau par cœur, donc forcément ça m'aide. Mais quand on bloque dans le jeu, avec un délai aussi mince, il y a moyen d'y passer des heures.
J'ai pas mal réfléchi à ce problème. Ça m'a amené à me redemander pourquoi, à la base, je souhaite que le joueur répète chaque mesure avant de la réussir. Si c'est pour le punir dès qu'il fait une petite faute, c'est pas vraiment productif. Et j'en suis arrivé à la conclusion suivante : le rythme est moins une affaire de précision que de compréhension de motif. Du moins, tel qu'il est conçu dans ce jeu. Ce que j'ai envie de dégager, c'est un aspect jam de jazz, où on ne va pas en vouloir au batteur ou n'importe quel joueur s'il a une note décalé de quelques millisecondes. Ce qui compte, c'est le motif qu'il joue, et la façon dont il s'intègre dans un "flow" général. Ça demande bien sûr de ressentir le rythme avec une certaine acuité, mais pas nécessairement de placer toutes les notes avec une perfection optimale.
Si le jeu acceptait l'erreur, bien sûr, je pourrais valider les notes selon leur exactitude à la micro-seconde près. Or ce n'est pas le but du jeu : on est dans l'apprentissage de motif, la compréhension du rythme avant tout, avec la répétition jusqu'à ce que le joueur maîtrise le morceau. Et donc une précision exigeante n'a pas sa place, rendant le jeu beaucoup trop difficile et improductif. Finalement ce n'est pas la vocation du jeu d'être dur.
Ainsi, j'ai d'abord remonté la marge à 0.07. Beaucoup plus confortable et tolérant, tout en refusant les notes qui sonnent vraiment fausses.
Sauf qu'avec les problèmes de latences sur Windows susmentionnées… Eh ben le jeu redevient carrément dur ! Donc finalement j'ai dû monter ça à 0.1. Super tolérant pour le coup, mais vu que le jeu n'est pas lui-même précis, bah il faut bien s'y adapter.
C'est là que vous entrez en jeu, si vous avez envie de faire du beta-test poussé. Une fois le jeu lancé une première fois, un fichier de config sera créé. Ce fichier ne contient que le délai de tolérance dont j'ai parlé. Vous pouvez donc le modifier pour essayer des valeurs plus basses ou plus élevées. Ma préférence va à 0,07, mais peut-être préférerez vous plus de difficulté avec 0,065, ou même 0,06 (vous pouvez aussi essayer en dessous, mais accrochez-vous). Ou même cela sera trop dur pour vous, et vous vous sentirez plus à l'aise avec un 0,08 ?
Bref, si vous faites des essais en ce sens, merci de me dire quel est la valeur qui vous a semblé le plus confortable. Je conseille aussi, entre chaque session, de faire autre chose et d'écouter d'autres musiques. Sinon vous ferez comme moi, essayer le morceau alors que vous avez encore le rythme en tête, et donc percevrez moins bien la difficulté !
L'emplacement du fichier est indiqué dans le readme.
Accessoirement, j'envisage de mettre une valeur plus réduite pour le mode difficile. De cette manière, on pourra offrir de la souplesse par défaut, et un challenge exigeants pour ceux qui en veulent…
***
Dans tous les cas, j'espère que vous trouverez de quoi vous amuser sur cette démo !
Mes jeux sur itch.io
Mes vidéos sur Youtube
Mes reins sur ebay (pas encore disponible)
Salut (et bonne année!),
(même en facile 
)
mais en tout cas du coup je suis bien incapable de savoir si se surajoute un problème de latence ou non.
Alors j'ai testé cette démo ... et j'avoue que je l'ai trouvé hyper dure !!
Bon, après je suis surement une bonne quiche en matière de ryhtmique
En revanche, en matière de "feedback" je me permettrai quelques remarques :
- je trouve que le son des bongos et l'importance de la rythmique qu'ils impriment ne sont pas assez prononcés par rapport aux autres instruments, j'aurai tendance à penser que vu le concept (qui place le joueur à la percu), les bongos devraient être bien plus en avant, autant pour la satisfaction du joueur (qui apporte auditivement qqchose au morceau quand son jeu est réussi) que pour bien se mettre la rythmique à reproduire en tête (j'avoue que j'ai beaucoup de mal à bien l'individualiser avec le piaono et la basse nettement prépondérants ; bon après comme je te dis je suis en plus carrément pas doué, alors c'est sûr que ça aide d'autant moins)
- ça manque de retour tant visuels que sonore pour signaler un coup réussi ou raté, c'est une mécanique grisante dans les jeux musicaux quand une partition bien suivie s'accompagne d'un retour sonore où la musique semble s'émanciper ; dans ton cas j'imagine qu'avoir des sonorités bien avant et bien pleines et toniques quand on est "dans le coup" vs. un son sourd et creux quand on est "à coté" pourrait stimuler ainsi le joueur tout en offrant un retour informatif. De même au niveau visuel, appuyer les succès par un flash ou je ne sais quoi peut être sympa (notamment pour les coups "parfaits") ; et en tout cas pour ce que tu évoquais plus haut sur la lisibilité des mauvais rythme, je pense qu'une façon d'améliorer les choses pourrait être, d'une part de rendre les ptits rectangles plus hauts (et peut-être moins larges ?) afin que les alignements soient plus visibles, et d'autre part de jouer sur la couleur p.ex. en affichant les mauvaises frappes en rouge.
- je trouve la perception de quelles bongo est frappée par le meneur difficile à percevoir : le son ténu rend difficile à bien percevoir la différence entre les deux sonorités, le laser et l'animation sont je trouve pas assez impactant pour être bien discernés quand dans le même temps on est concentré sur le rectangle central, et les symboles sur la partition ne permettent pas de différencier les deux bongos. Mettre le son des bongos plus en avant devrait un peu améliorer la chose, mais je pense aussi que, au moins en mode "facile", un symbole différent selon le bongo joué serait une aide précieuse (genre un triangle orienté vers la gauche ou vers la droite plutôt qu'un rectangle ; très étirés en hauteur de surcroit pour bien marquer les alignements) ; au niveau visuel, accompagner chaque frappe par un éclat, un flash ou je ne sait quoi de bien marqué du coté du bongo joué pourrait aussi se combiner utilement au reste.
- sinon, petit soucis dans un des passage où le premier coup est donné sur le premier temps : si on appui un tout petit peu trop tôt, notre coup n'est pas enregistré car le jeu considère qu'on a pas encore la main, alors même qu'on peut être dans la marge d'erreur théoriquement acceptée ; du coup ce coup-ci est bien plus dur à réussir que les autres car seule une imprécision à type de retard est tolérée.
Voilà pour mon retour quand même limité vu que je n'ai pas réussi à aller bien loin :P.
Je noterai juste que pour cette histoire de latence que tu perçois, j'ai du mal à imaginer que cela est directement tributaire de Unity, puisque le moteur est couramment utilisé dans des projets trés ambitieux et volontiers exigeants, comme Ori par exemple, jeu où quand même les réflexes sont à certains moment mis à rude épreuve et pour lequel j'ai du mal à imaginer qu'une latence significative dans les commandes aurait permis une telle réussite.
As-tu fais des tests d'ailleurs pour déterminer si la latence se situe entre les entrées et le moteur de jeu, ou plutôt entre le moteur de jeu et la bande son ?
Si c'est le calage du moteur de jeu (et des entrées) par rapport au son qui pose problème, qu'utilises-tu comme système audio ? (sortie analogique de carte son vers enceintes actives, ou une carte son / DAC externe ? qui pourrait occasionner un retard ; pouvant au passage dépendre du driver audio, pouvant expliquer une différence de comportement selon l'OS).
Merci beaucoup pour ces retours !
Donc le jeu est dur. Bon, d'un côté je craignais qu'il soit ennuyeux. C'est partiellement une bonne nouvelle.
Mais idéalement les niveaux devraient pouvoir se terminer sans trop d'effort, et j'ai l'impression que tu as dû t'arrêter avant la fin !
Peut-être augmenter la latence à 0,2 (carrément) pourrait faciliter le jeu ? Sous Windows, le fichier se trouve dans <user>/LocalLow/Itooh/Bongo Machine/configbeta.ini
Je vais aussi peut-être me débarrasser des notes au tout premier temps, ou trouver un moyen de tricher pour les accepter en avance. C'était voulu qu'elles soient plus dures que les autres, mais si de base la difficulté est bien élevée, on va éviter !
Concernant la latence, c'est uniquement l'input. Le moteur du jeu lui joue bien en rythme ! Une bonne manière de la tester, c'est, à la première mesure, donner des petits coups sur les flèches et tenter de voir si le son et l'animation se jouent bien en même temps. Le décalage est très légèrement perceptible chez moi en tout cas. Je vais regarder ce que j'ai niveau carte son et driver.
Et ouais les feedback j'hésitais à les accentuer, pour ne pas perturber la musique. Mais ça vaudrait mieux qu'ils soient plus prononcés. Notamment comme tu dis indiquer les fausses notes dès qu'elles sont jouées. Jusque-là la validation se faisait à la fin de la mesure uniquement, mais au vu de ton ressenti ce sera préférable de la faire dynamiquement. J'avais peur de « déconcentrer » ou démotiver le joueur, mais avec le recul je pense que ça apportera en clarté et en satisfaction s'il sait immédiatement quand il se trompe (et sait aussi quand il est juste).
Pour l'histoire des bongos gauche et droite : en vérité, leur ordre n'a pas d'importance ! Tu peux jouer l'un ou l'autre à l'envers, tant que le rythme est respecté, c'est validé. Mais du coup ça gagnerait à être plus clair… Je pense déjà avoir fait une erreur en leur donnant deux sons différents. Si j'arrive à faire comprendre sans texte au joueur que les bongos partagent la même fonctionnalité et sont identiques, ce sera pour le mieux.
Historiquement d'ailleurs, il y avait une règle qui voulait que le joueur ne pouvait pas frapper deux fois le même bongo d'affilée. Mais elle s'est révélée inutile et trop compliquée à introduire, donc elle s'est retrouvée zappée. Mais la logique du lead, c'est celle-là : il alterne gauche et droite sans se poser de questions.
Mes jeux sur itch.io
Mes vidéos sur Youtube
Mes reins sur ebay (pas encore disponible)
Pages