mrqqn.net

Aller au contenu | Aller au menu | Aller à la recherche

Programmation › Jeu vidéo

Fil des billets - Fil des commentaires

jeudi 28 février 2013

Revolbeat : Les sets

Par Mr_Qqn le jeudi 28 février 2013, 16:58

Qui dit jeu de rythme, dit forcément musiques et chansons. Voici un petit post sans réel rapport avec l'avancée du projet où je vais juste présenter comment j'imagine la progression du joueur parmi les musique du jeu.

Dans l'idéal, j'aimerai faire un peu plus qu'une simple liste de musiques jouables (si j'arrive déjà à ce stade, je serai déjà très content du résultat). Je pense baser la progression du joueur sur un système de sets à la manière d'un Guitar Hero ou d'un DJ Hero, chacun orienté autour d'un thème et composé de :

  1. 5-6 songs d'environ 2'-2'30. A titre de comparaison, sur IIDX les musiques font entre 1'30 et 2' mais sont vraiment très intenses. Sur Guitar Hero, il me semble qu'on est à peu prêt sur du 4-5 minutes, mais là soit ça devient vite chiant, soit ça joue sur l'endurance du poignet, et ce n'est pas ce que je veux mettre en avant dans ce jeu. Bref, je pense qu'une durée entre les 2 devrait être adaptée, mais ça reste aussi à confirmer.
  2. 1 boss-song d'une difficulté supérieure et débloquée après avoir réussi les musiques précédentes (rien de plus classique).
  3. 1 Mashup final qui est la petite idée que j'ai eu l'autre jour. Son principe est simple : c'est un bonus qui s'enchaine directement après la boss-song dans le cas où le joueur fait un score proche du perfect. Sa musique est tout simplement un remix des musiques précédentes. Et ce mashup est la pour 2 raisons : comme on ne peut le déclencher qu'à la fin de la boss-song et uniquement dans le cas où l'on fait un super score, il devrait considérablement augmenter le stress du joueur et par conséquent démultiplier le sentiment de réussite ou de frustration (en fonction de si l'on réussit ou pas). En plus, le fait d'utiliser un mashup plutôt qu'une musique inédite devrait provoquer un sentiment d'accomplissement et de clôture, comme si l'on passait en revue tout ce que l'on a réussi juste avant. J'y pense juste au moment où j'écris ce post, et ça a dû être inconscient quand j'en ai eu l'idée, mais j'ai dû la repiquer de Rhythm Tengoku : le jeu est lui aussi réparti en plusieurs sets dont chacun comporte à la fin un remix de tout ses mini-jeux. Je n'étais pas totalement sûr de ce concept, mais maintenant que j'en connais l'origine, je suis persuadé qu'il faut le mettre en place.

Par contre, je ne pense pas mettre de progression entre les sets, tout simplement parce qu'un jeu de rythme ne se joue pas comme un plateformer. Il est très frustrant (dans le mauvais sens) de devoir faire et refaire une musique que l'on n'aime pas pour débloquer la suite du jeu, même si l'on joue la meilleur chart du monde. Je me rappelle très bien quand je jouais à pop'n music avoir été forcé de passer par quelques musiques plutôt insoutenables... Je pense que contrairement aux autres types de jeux où la musique vient soutenir l'action, quand elle est au coeur du gameplay, elle est bien plus soumise au goûts du joueur, ce qui fait que la qualité d'un niveau est bien plus subjective. Bref, comme on me l'a si bien appris ne fais pas aux autres ce que tu ne voudrais pas qu'on te fasse, je ne force donc pas à jouer sur tous les niveaux. Ca et puis le fait que tant que ça reste un projet maison, je ne pourrais pas faire des dizaines de sets (ni même une dizaine) et une progression sur 2 ou 3 sets ça ne vaut pas grand chose...

Bref, même si je joue du saxophone et ai fait quelques années de piano, je suis incapable de composer quelque chose de correct. Forcément, je vais avoir besoin de récupérer des musiques ailleurs. Donc soit j'utilise de la musique libre de droit, soit j'arrive à collaborer avec quelques musiciens. J'adorerai vraiment réussir à motiver plusieurs artistes pour travailler (au moins temporairement) sur la musique du jeu. Rien que pour la contrainte du temps, c'est pas spécialement évident de dénicher des musiques qui font pile la bonne durée. Je peux toujours en découper à la hache avec audacity mais je ne garanti pas un super résultat. Et je ne parle même pas du mashup, il faut quand même un certain talent pour en réaliser un... (mais je m'y essayerai quand même pour le fun) Si j'ai la chance de trouver quelques personnes motivées, on pourra faire en sorte de construire quelque chose de cohérent, autrement le jeu évoluera vers quelque chose de communautaire comme Osu! (ou partira à la poubelle, s'il est tout pourri).

aucun commentaire aucun rétrolien

Revolbeat : Avancement #1

Par Mr_Qqn le jeudi 28 février 2013, 13:07

2 semaines... Avec les recherches d'emploi et une bonne petite grippe, je n'ai pas avancé aussi vite que prévu, mais au moins, la partie "éditeur" de l'éditeur est enfin terminée ! Voilà ce que j'ai rajouté depuis la dernière fois :

Le magnétisme Screenshot_2013-02-27-15-53-03.png

Les notes sont calées sur une division de cercle, fixé à 16 et sur une division de pulsation. On peut diviser chaque pulsation en 1, 2, 3, 4, 6, 8, 12 ou 16 divisions avec la réglette sur la droite.

Les ancres

Les ancres permettent de gérer les variations de tempo et de signature (nombre de temps par mesure). Il n'y a que 3 types de signature différents : 3/4, 4/4 et 5/4, tout simplement pour alléger l'interface et parce que en jouant sur la taille de la division, on peut reproduire toutes les autres. Par exemple :

  1. 6/4, 6/8, etc... => 3/4
  2. 2/2, 2/4, 4/8, etc... => 4/4
  3. 10/4, 5/8, etc... => 5/4 (très peu utilisé dans la musique moderne, mais il n'empêche qu'on peut un jour ou l'autre tomber dessus donc autant le prévoir à l'avance)

J'ai été confronté à 2 problèmes quand j'ai implémenté l'édition des ancres :

La dépendance des événements

Dans mon modèle de données, chaque événement (note et ancre) est dépendant de l'ancre précédente, contient une référence vers celle-ci et vice-versa. Et dans le cas où l'on change l'ordre des ancres, l'ancre enfant devient le parent de son parent et inversement et pendant un court instant une ancre pouvait avoir 2 ancres enfant, ce qui déclenchait une boucle infinie. J'ai d'abord renforcé le modèle pour être sûr de n'avoir toujours qu'une seule ancre enfant en lançant une exception dès qu'une seconde ancre est ajoutée. Sauf que ça rendait le modèle "hyper-statique" (ça doit se dire, non ?) : chaque événement devant obligatoirement avoir une ancre parente (qui est indispensable pour calculer sa position exacte), il n'était plus possible d'inverser les 2 ancres du tout. Bref, j'ai transformé cette contrainte en assertion à la fin de l'algorithme d'inversion et j'ai pu tout simplement débugger l'algorithme grâce à ça.

Morale: ne pas mettre trop de contraintes sur les données.

Le format de position

Pour des raisons évidentes d'espace, les positions sont stockées uniquement avec un Int grâce à une value class (que j'expliquerai dans un prochain article) et étaient encodées de la sorte :

| mesure  | division |
| 16 bits | 16 bits  |

mesure représente l'index de la mesure et division la position de la note dans la mesure. Par exemple, pour une division de 16384 : 16384/65536 = 1/4, la note se trouve à 1/4 du début de la mesure. Le problème est que si l'on commence l'édition d'une musique et qu'à un moment on se rend compte qu'on n'est pas en 4/4 mais en 3/4 par exemple, le fait de changer de signature va décaler toutes les notes en les "compressant". J'ai dû recoder les positions en fonction de la pulsation et non plus en fonction de la mesure, de cette manière on peut changer de signature sans problème.

| pulsation | division |
| 16 bits   | 16 bits  |

Mais là, autre problème : avec 2^16 pulsations, la durée maximale qui peut être représenté est relativement courte : à 200 BPM la durée maximale est de 5.46 minutes. J'ai donc augmenté le nombre de bits représentant la pulsation, mais en diminuant le nombre de bits de division on en réduit la précision. Par exemple, à 200 BPM, avec 8 bits pour la division, une division a une durée de 1.17 ms, ce qui est plus qu'acceptable, mais à 10 BPM on arrive à 23.44 ms, ce qui n'est plus franchement précis. J'ai donc essayé de trouver une répartition de telle sorte que la durée soit suffisamment longue à pulsation élevée et qu'une division soit précise à pulsation basse. Finalement, j'en suis arrivé à ça :

| pulsation | division |
| 20 bits   | 12 bits  |

Ca donne une durée de 87.38 minutes à 200 BPM et une précision de 1.46 ms à 10 BPM, un bon compromis !

Fenêtres d'édition

3 fenêtres d'éditions qui sont accessibles en touchant un élément (qui se met alors en surbrillance):

  1. song.png Song : pour modifier l'ancre principale et l'offset de la musique
  2. note.png Note : pour modifier la position et l'angle d'une note
  3. anchor.png Anchor : pour modifier le BPM, la signature et la position d'une ancre

Ce qui m'a pris le plus de temps a été de créer tout les composants d'éditions et surtout d'améliorer la gestion de événements touch du moteur.

Par contre, ces fenêtres ont mis en avant les premières limites du moteur : comme je mélange formes et texte, je doit changer assez souvent de shader OpenGL, ce qui du coup provoque une baisse du FPS... Pour le moment, les performances restent acceptables donc je vais prioriser les fonctionnalités par rapport aux performances et continuer le dev du jeu. Je reviendrai sur le coeur du moteur une fois que j'aurai quelque chose de jouable.

Autre petits trucs

  1. Double-tap sur les boutons d'édition : les 3 boutons d'éditions sur le côté (ajouter, bouger, supprimer) ont 2 modes : note et ancre. On tape une fois pour le mode note et deux fois pour le mode ancre. Et pour éviter les erreurs de manipulations : le mode n'est actif que tant le bouton est pressé, ça évite de modifier une note ou une ancre alors que l'on voulait simplement se déplacer.
  2. Limitation du zoom
  3. Limitation de la position
  4. Suppression de événements superposés

Rien de bien compliqué en somme

Next

La prochaine étape est maintenant d'ajouter un mode lecture à l'éditeur, puis un mode de jeu. Une fois que ce sera terminé, je commencerai à vous faire tester tout ça ! :)

aucun commentaire aucun rétrolien

mardi 12 février 2013

Nouveau projet de jeu

Par Mr_Qqn le mardi 12 février 2013, 15:41

Je pensais commencer le devblog un peu plus tard, mais suite à la demande d'un ami, je vais le débuter aujourd'hui.

J'ai donc commencé il y a quelques semaines le développement d'un jeu pour android (téléphones et tablettes), mais à raison d'une heure ou deux par soir ça n'avançait pas vraiment... Malheureusement, j'ai perdu mon emploi à Mandala la semaine dernière pour cause de liquidation judiciaire :(. J'en profite au passage pour remercier toute l'équipe de Mandala pour cette belle aventure : Nadya, Renaud, Christophe, Guillaume et Axel, ainsi que les stagiaires de passage : Simon, Marine, Alexis, Edouard, Faustine, Elsa, Jeremy et Bastien. Maintenant que je suis au chômage et avant de me lancer à fond dans les recherches d'emploi, j'ai décidé d'utiliser cette première semaine pour bien lancer le développement de ce jeu.

Comme c'est mon premier jeu tactile, je n'ai pas voulu me lancer dans un truc totalement inconnu : ce sera... *roulement de tambours* un jeu de rythme ! Quelle révélation x). J'ai eu l'idée de ce jeu suite à la frustration que j'ai eu sur Cytus (le seul jeu de rythme correct que j'ai trouvé pour tablettes android) qui a un gros problème sur tablette : 50% du temps les mains cachent une partie l'action. Je suis aussi très fan du visuel de Super Hexagon. Et quand je mélange les deux, ça donne un jeu de rythme classique où les notes se déplacent du centre vers l'extérieur du cercle. Le principal intérêt du cercle est de pouvoir justement garder le zone d'action tout le temps lisible : que l'on utilise ses pouces sur un téléphone ou ses mains sur une tablette, il sera toujours possible de garder la zone d'action totalement claire. Ce sera à confirmer dans la pratique, mais je suis plutôt confiant sur ce point.

Screenshot_2013-02-11-17-41-21.png

Le gameplay restera un beatmania-like assez classique. L'intérêt de ce type de jeu réside dans la difficulté d'exécution dû au nombre très élevé d'APM, cependant les appareils tactiles n'ont aucun retour sensitif qui s'apparenterait à celui d'un bouton (il est possible d'utiliser le vibreur comme le font certains claviers virtuels, mais généralement les tablettes n'en n'ont pas), et sans vrai retour sensitif, il est impossible d'avoir une précision correcte dans les parties intenses. L'idée là est, un peu à la manière de Super Hexagon, remplacer une partie de la difficulté d'exécution par de la difficulté de lecture en rajoutant des artefacts visuels de type rotations, flash, etc...

Je ne vais révolutionner ni le jeu de rythme ni le jeu mobile, mais ce n'est pas non plus le but. Mon objectif ici est plutôt de réaliser un jeu dont le feeling est impeccable : je veux que le jeu soit dur et que le joueur rage, mais seulement parce qu'il n'est pas encore assez doué, pas parce que le jeu est mal réglé (timings foirés, mouvements impossibles à réaliser, etc...).

Voilà pour l'idée principale.

Concernant la réalisation, j'ai voulu le développer en Haxe avec NME ce qui m'aurait permis de déployer directement pour Android et iOS, mais le fait de ne pas connaitre le fonctionnement exact du moteur pour un jeu demandant beaucoup de réactivité est un peu dérangeant. Finalement, c'est après avoir découvert l'existence d'Avian (un outil qui compile du code JVM en code natif dont pour iOS) que j'ai décidé de faire un petit moteur perso en Scala.

Je modifie le moteur au fur et à mesure que j'avance sur le jeu, histoire de ne pas coder de composant que je n'utiliserai jamais ou tellement générique qu'en fait il ne fait plus rien :p. Avec mon expérience à Mandala et en reprenant quelques petits bouts dans mon ancien moteur pour Koto, j'ai actuellement un moteur de scène 2D en OpenGL assez basique basé sur les entités qui affiche formes, sprites et textes, et qui dispatch les événements "touch". Ce n'est pas encore le cas à 100%, mais j'essaye d'optimiser au maximum le moteur pour qu'une fois un scène créée, il n'y ait pas d'allocation d'objet supplémentaires. Chose qui n'est pas vraiment évidente en Scala étant donné que le langage met en avant les objets immuables et a quelques overhead syntaxiques (par exemple la boucle for qui est en fait une expression lambda appelée N fois). C'est pas ultime, mais la vitesse de rendu m'a l'air tout à fait honorable (il n'est pas impossible que je risque de pleurer en testant sur d'autres appareils mais bon...). Ce qu'il manque actuellement au moteur est une fonction de cache en tant que texture (comme il existe en flash), pour les parties plus ou moins statiques nécessitant beaucoup de retraçage ainsi qu'une meilleure utilisation des VBO, mais je verrai tout ça quand j'en aurai vraiment besoin.

Sur ce jeu, je ne vais pas faire la même erreur que sur mon précédent jeu de rythme et qui a fait que je l'ai abandonné. Sur Koto, j'éditais les musiques dans un fichier texte en dehors du jeu, et même si le format était assez descriptif et humainement lisible, il fallait faire tellement d'aller retour entre l'éditeur de texte et le jeu qu'au final on perdait un temps pas possible pour faire un truc tout bête... Donc cette fois-ci je code les outils en même temps que le jeu ! A vrai dire, je le code même avant, c'est peut-être pas la meilleure idée, mais je sais que si j'ai un jeu jouable, j'aurai du mal à me justifier le temps de développement d'un éditeur alors que je pourrait à la place améliorer le jeu.

Aujourd'hui je n'ai pas encore la mécanique de jeu de validation des notes, mais j'ai quasiment tout le reste pour me permettre de créer des musiques :

  1. Un système de chart complet avec notes et tempo variable, qui permet une édition des données en temps réel (si par exemple je change le tempo, toutes les notes seront bien replacées)
  2. Un éditeur qui permet
    1. de se déplacer et de zoomer / dézoomer
    2. d'ajouter, déplacer et supprimer des notes

Avant de m'attaquer au coeur du jeu, il me reste 2-3 truc à terminer sur l'éditeur :

  1. Gestion des ancres : pour le tempo variable
  2. Réglage de l'offset pincipal
  3. Réglage du magnétisme : pour caler les notes sur les temps, demi-temps etc..
  4. Supprimer les notes superposées
  5. Limiter le zoom et le déplacement : histoire de ne pas se retrouver à -1 min ou avec 2 min de notes sur un même écran
  6. Améliorer la zone de déplacement : comme on a affaire à un cercle dont le "+" est au centre et le "-" à l'extérieur le feeling dans le déplacement n'est pas top

Une fois tout ça terminé, je vais m'attaquer au développement de la mécanique de jeu, de telle sorte à ce qu'il soit jouable à l'intérieur de l'éditeur pour que les itérations édition / test soient vraiment très courtes.

Voilà pour le moment. Je vais essayer de mettre au minimum un nouvel article par semaine en fonction de l'avancée, avec, je l'espère, pour la fin de la semaine une première version de l'éditeur jouable.

Ah, et au fait, son nom est Revolbeat ! :)

2 commentaires aucun rétrolien

lundi 20 août 2012

Yokai's Song

Par Mr_Qqn le lundi 20 août 2012, 22:23

Petit jeu réalisé en une semaine (soirs et weekend) pour un concours sur Game Jolt. C'est jouable ICI.

screen5.png

aucun commentaire aucun rétrolien

vendredi 27 mai 2011

La latence pour les nuls

Par Mr_Qqn le vendredi 27 mai 2011, 11:58

Petite explication de comment fonctionne la latence dans LR2 à l'intention du forum Bemani-France. C'est pas forcément très clair, donc si y'a besoin de précision, éclaircissement, demandez :) .





    
    
          

              aucun commentaire
              aucun rétrolien              

        

    
          


    
jeudi  5 mai 2011
    
    
Scoring Koto

    
    
Par Mr_Qqn    le jeudi  5 mai 2011, 08:24

    
            
    
    
          
Pour ceux que ça intéresse, pour l'instant le scoring fonctionne comme ça :


Score = Somme( score note )
Score note :





 
Perfect posGreat posGood posBad pos




Perfect timing100603620




Great timing60503017




Good timing36302514




Bad timing20171412





Bien évidemment un miss = 0


Concernant le groove, on démarre à 20 % et on rajoute (ou on retire) à chaque note :




 Perfect posGreat posGood posBad pos




Perfect timing+ 2 %+1.5%0- 5 %




Great timing+ 1.5%+ 1 %0- 5 %




Good timing000- 5 %




Bad timing- 5 %- 5 %- 5 %- 5 %


Et un miss = - 10 %


Et l'overall accuracy dans le result screen correspond à la plus mauvaise précision de chaque note :




 Perfect posGreat posGood posBad pos




Perfect timingPerfectGreatGoodBad




Great timingGreatGreatGoodBad




Good timingGoodGoodGoodBad




Bad timingBadBadBadBad

    
    
          

              aucun commentaire
              aucun rétrolien              

        

    
          


    
mercredi  4 mai 2011
    
    
Avancement Koto #6

    
    
Par Mr_Qqn    le mercredi  4 mai 2011, 23:12

    
            
    
    
          
Nouvelle mise à jour du jeu : alpha 2, avec comme nouveauté



    

  • Le système de scoring
    • 

  • Result screen (encore sans comparatif)
    • 




Et 2 songs pour jouer :




Koto alpha2-1




Donc petit récapitulatif de comment installer le jeu :


    

  • Avoir Java d'installé
    • 

  • Lancer le jeu
    • 

  • Au premier lancement, le répertoire du jeu est créé dans le répertoire utilisateur/koto (le répertoire utilisateur c'est le répertoire parent de "mes documents" sous windows)
    • 

  • Extraire les songs dans koto/songs
    • 

  • Relancer le jeu
    • 

  • Enjoy
    • 




Les commandes du jeu :


    

  • Menus : entrée, flèches et échap
    • 

  • En jeu :

      

    • Toutes les touches entre le 1 en haut à gauche et le ! en bas à droite
      • 

    • Hi-speed + et - avec + et - du pavé numérique
      • 

    • 

  • Result screen :

      

    • Droite et gauche pour le détail de la précision
      • 

    • Tab pour switcher entre les graphiques
      • 

    • 



    

  • Pour lancer une song en mode débug : CTRL + Entrée
    • 

  • Se déplacer dans une songs en débug :

      

    • Home : début de la song
      • 

    • Page down / up : marqueur suivant / précédent
      • 

    • 




Pour configurer le jeu, ca se passe dans le fichier koto/options.properties :


width=800
height=600
game-height=500
fullscreen=false
vsync=true
audio-offset=0.1





Koto alpha2-2




Pour la prochaine mise à jour je prévois :


    

  • sauvegarde des scores
    • 

  • clear/fail d'une song
    • 

  • ranks et les graphs qui vont avec
    • 

  • graphs du highscore
    • 

  • changement de l'api audio (openal est totalement merdique)
    • 



    

  • (et éventuellement je vais tenter une petite refonte du gameplay pour simplifier le jeu, ou tout du moins la lecture des notes)
    • 




Pareil qu'avant, si vous avez des bugs/suggestions, y'a toujours ce petit forum en place : http://mrqqn.net/vanilla/.




Aller, c'est reparti !

    
    
          

              un commentaire
              aucun rétrolien              

        

    
          


    
dimanche 27 mars 2011
    
    
Avancement Koto #5

    
    
Par Mr_Qqn    le dimanche 27 mars 2011, 16:01

    
            
    
    
          
Ca avance beaucoup moins vite quand on est pas en vacances, mais voici quand même une nouvelle mise à jour de Koto. Avec comme nouveautés :


    

  • Un écran titre
    • 



Ecran titre


    

  • Un écran de sélection
    • 



Ecran de sélection




(L'image de fond n'est pas de moi, je l'ai honteusement volé emprunté à cette personne, j'en changerai plus tard.)



    

  • Le chargement de ressources en parallèle pour pas que le jeu se bloque et plusieurs autres trucs dans le moteur de jeu qui servent vachement mais qui ne se voient pas.
    • 




Pour pouvoir tester le jeu, il est préférable d'avoir une song, en voilà une (incomplète) : http://mrqqn.net/koto/natsu-tsukuyo.zip. A dézipper dans répertoire koto/songs/.




Et pour lancer le jeu c'est toujours ici : Lancer le jeu. Et j'ai aussi mis en place un forum pour reporter les bugs : http://mrqqn.net/vanilla/




Maintenant, je m'attaque sérieusement à la création de 4-5 songs, parce qu'un jeu sans niveaux ça sert à rien ! :p

    
    
          

              aucun commentaire
              aucun rétrolien              

        

    
          


    
samedi 26 février 2011
    
    
Avancement Koto #4 : Créer une chart

    
    
Par Mr_Qqn    le samedi 26 février 2011, 22:05

    
            
    
    
          
Le jeu est maintenant suffisamment avancé pour pouvoir créer des charts à peu près convenablement (mais pas encore y jouer).
Pour ceux qui voudraient essayer, je vais donc expliquer comment procéder pour créer une chart pour Koto.




Mise en place de l'environnement


    

  1. Si vous n'avez encore jamais lancé le jeu, lancez le une première fois pour qu'il crée le dossier de jeu et le fichier d'option
    2. 

  2. Dans le dossier de jeu (répertoire utilisateur/koto, par exemple C:\Users\Julien\koto) créez un nouveau dossier. Ce sera le dossier de la chart.
    3. 

  3. Copiez dans ce dossier la musique au format ogg vorbis. (Pour le moment, je ne prend que les formats ogg, c'est ça de tout recoder à la main...)
    4. 

  4. Encore dans le dossier créez un fichier texte vide avec l'extension .koto
    5. 

  5. Dans le fichier d'options (options.properties) ajoutez une ligne contenant debug=dossier de la chart/chart.koto.
    6. 




Voilà, c'est presque prêt, il reste plus qu'à créer la chart. (Si vous lancez le jeu à ce stade là, ça va planter. Normal, le fichier .koto est vide !)




Ecrire le fichier .koto



Maintenant, la partie la plus difficile : écrire la chart. Je vais juste expliquer comment s'écrivent les chart, pas comment en faire une bien, tout simplement parce que le gameplay est encore expérimental et que je ne sais pas encore moi non plus comment faire.




L'en-tête du fichier



Tous les fichiers commencent comme ça :


(Koto Music Sheet v1)

(Informations)

Title : Natsu-Tsukuyo # ca j'explique pas
Genre : Asian Mixture
Artist : Kei Izumi
Author : Mr_Qqn

(Song Params)

File : natsutsukuyo.ogg  # nom du fichier de musique
BPM : 93  # tempo initial
Mesure Size : 4  # nombre de pulsation par mesure
Offset : 0.668  # décalage audio en secondes

(Music) # Indique la fin de l'en-tête, ce qui va suivre sera la chart




Le décalage audio correspond au temps entre l'instant 0 du fichier ogg et l'instant ou démarre réellement la musique. Ca se mesure facilement en ouvrant le fichier dans Audacity par exemple.




Les commentaires débutent avec # et s'arrêtent à la fin de la ligne. Pratique pour se repérer dans un fichier de plus de 1000 lignes.




Les notes



Ici on va positionner les notes sur le clavier et dans le temps.




On positionne les notes sur les lignes (de bas en haut) en les plaçant les unes à la suite de autres (de gauche à droite), et on les positionne à l'intérieur de chaque ligne (de gauche à droite) avec les nombre de 0 à 9. Pour indiquer un vide on utilise le caractère "_". Quelques exemples pour être plus clair :


0 _ _ _ # note 0 de la ligne 1 => W
_ 5 _ _ # note 5 de la ligne 2 => G
_ _ 2 9 # note 2 de la ligne 3 + note 9 de la ligne 4 => E + 0 (ou à)





Si la suite ne contient que des _ pas besoin de les indiquer


5 # note 5 de la ligne 1 => N
_ 6 # note 6 de la ligne 2 => J





Pour positionner dans le temps, on va grouper les notes par mesure et les notes seront réparties équitablement dans la mesure. On sépare les mesures avec une ou plusieurs lignes vides. Par exemple :


2 _ _ _  # 0/4 de la mesure 1
_ 5 _ 0  # 1/4 de la mesure 1
_ # rien
6 # 3/4 de la mesure 1

        # nouvelle mesure

3       # 0/2 de la mesure 2
_ 3     # 1/2 de la mesure 2




Pour trouver la pulsation sur laquelle tombe une note, on multiplie sa position par la taille de la mesure (qui est définie dans l'en-tête). Par exemple :


avec Mesure Size : 4
0/4 => pulsation 0 (0/4 * 4)
1/4 => pulsation 1
2/4 => pulsation 2
1/2 => pulsation 2

avec Mesure Size : 2
1/4 => pulsation 0.5 (donc pile entre les pulsations 0 et 1)
1/2 => pulsation 1





Voilà, avec tout ça vous pouvez déjà écrire des charts de base ! :) Mais voilà, il arrive qu'une musique n'ai pas tout le temps le tempo fixe ou bien il arrive qu'une mesure dure moins longtemps qu'une autre, pour ça on va utiliser des événements pour modifier ces caractéristiques.




Les événements



Les événement permettent de modifier les caractéristiques d'une chart à partir de l'endroit où ils sont indiqués. On les rajoute en fin de ligne en les séparant du caractère "|". Il est aussi possible d'en mettre plusieurs par ligne. Bref, encore un petit exemple :


5 _ _ 6 | size 2 # la taille des mesures est maintenant de 2 pulsations
_ _ _ 6 | bpm 154.2 # le tempo passe à 154.2
_ _ _ 8 | mark # place un marqueur à cet emplacement
_ | mark | bpm 125 # 2 événements ensemble






Au fait, tous les noms des sections (Informations...), des propriétés (Title...) et des événements(bpm,mark...) ne sont pas sensibles à la casse, donc on peut aussi bien écrire Title : Plop, title : Plop ou TiTlE : Plop. C'est exactement la même chose.




"Débugguer" la chart



Parcequ'on va pas relancer le jeu à chaque changement et qu'on a pas envie de réécouter 50000 fois le début de la musique, j'ai inclus quelques fonctions de "débug" pour moins s'emmerder :p.


    

  • Entrée ou espace : switcher entre pause et lecture
    • 

  • F5 : recharger le fichier
    • 

  • Home (ou début) : rembobiner la musique
    • 

  • Page up : aller au marqueur précédent
    • 

  • Page down : aller au marqueur suivant
    • 

  • + du pavé numérique : augmenter de hi-speed
    • 

  • - du pave numérique : réduire le hi-speed
    • 





Voilà, maintenant vous savez tout, sur comment écrire un fichier koto ! Simple n'est-ce pas ? Bon peut-être pas... Si il y a des points que vous trouvez encore obscurs, envoyez moi un message que je détaille un peu le truc.




Alors y'a quelqu'un qui tente d'en écrire une ? :p




Lancer le jeu

    
    
          

              aucun commentaire
              aucun rétrolien              

        

    
          


    
jeudi 24 février 2011
    
    
Avancement Koto #3

    
    
Par Mr_Qqn    le jeudi 24 février 2011, 13:11

    
            
    
    
          
Ca y'est le lecteur de chart est terminé ! (Avant même la fin de la semaine :D) Une petite vidéo donc pour présenter un peu le jeu (musique de Kei Izumi).



La chart a totalement été fait au pif, c'est vraiment histoire de tester. Et en vrai le jeu tourne bien plus rapidement (~700 fps), c'est fraps qui pourri totalement la vitesse de jeu. Donc pas d'inquiétude concernant le timing de jeu ^^. 

    
    
          

              aucun commentaire
              aucun rétrolien              

        

    
          


    
samedi 19 février 2011
    
    
Avancement Koto #2

    
    
Par Mr_Qqn    le samedi 19 février 2011, 22:29

    
            
    
    
          
Pendant cette première semaine de vacances j'ai pas trop mal avancé sur le jeu. J'ai quasiment terminé le moteur 2D, il manque juste une classe d'écriture de chaines de caractères et il me reste à corriger quelques bugs que rencontrent certaines cartes graphiques.




ingame.png




Au tout début le moteur reposait sur une classe de matrice codée dans le style fonctionnel de scala, cependant, c'était très gourmand en ressources puisque la classe peut être appelée plusieurs centaine voir milliers de fois par image. Je l'ai donc remplacée par une classe codée "classiquement" et ça a doublé les performances. Dans le même genre, en regroupant les appels à openGL qui s'effectuent avec la même texture, on augmente aussi considérablement les performances lorsqu'un grand nombre de sprites est dessiné. Avec 1600 sprites, le jeu tourne à environ 200 fps sur ma machine :D.




Le jeu va créer un dossier "koto" dans votre répertoire utilisateur contenant un fichier d'options.


height=600 
width=800
fullscreen=true
game-height=500




Juste une petite explication sur l'option game-height : ça sert à compenser l'étirement du jeu sur un écran large en plein écran. En fait le jeu a toujours une taille de 800 x game-height. Bref les valeurs de game-height en fullscreen sur un écran :


    

  • 4/3 : 600
    • 

  • 16/10 : 500
    • 

  • 16/9 : 450
    • 




Bref, pour ceux qui veulent tester le "jeu", vous avez besoin d'avoir Java installé. Je suis preneur de tout les retours que vous pourriez avoir dessus (même si pour l'instant à part des retour de bugs y'a pas grand chose à rajouter).




Lancer le jeu




Cette semaine, je vais essayer de faire un "débogueur" de chart, un outil pour simplifier la création de charts.




Autrement, je fais part de mon avancement un peu plus régulièrement sur ce forum.

    
    
          

              aucun commentaire
              aucun rétrolien              

        

    
          


    
vendredi  4 février 2011
    
    
Avancement Koto #1

    
    
Par Mr_Qqn    le vendredi  4 février 2011, 19:00

    
            
    
    
          
J'avais une idée de jeu de rythme en tête depuis un moment, mais jamais la motivation de m'y mettre sérieusement jusqu'à il y a 2 semaines. J'ai enfin commencé la programmation du jeu et fait un premier jet pour le design du jeu. L'interface va certainement changer au fur et à mesure du développement, mais l'idée globale est là :




Design #1




J'avoue, l'interface est totalement inspirée de Beatmania IIDX, par contre le gameplay est bien différent. Les joueurs de jeux de rythme auront reconnu le classique j'appuie lorsque la note atteint la barre rouge en défilement horizontal de droite à gauche. 

Mais là où ce jeu est différent, c'est qu'il n'y a pas une touche par ligne mais 10 ! Regardez, les carrés dans les lignes coïncident parfaitement avec la position des touches d'un clavier ! Lorsqu'une note apparait à l'écran, une touche sur la ligne va s'allumer de la même couleur que la note, c'est donc sur cette touche qu'il faudra appuyer un fois que la note aura atteins la barre rouge. Bien évidemment la position des couleurs reste fixe, par exemple, les notes jaunes de la ligne 1 seront toujours sur la touche Y. Au final, ca donne un total de 40 touches et avec 4 touches simultanées au maximum (les 4 lignes).




Ca peut paraître bien difficile présenté comme ça, mais en vrai ça risque d'être encore pire ! :D C'est surtout destiné aux joueurs de jeux de rythme expérimentés cherchant un challenge supplémentaire.




La grosse difficulté dans la création du jeu va être la création de charts (niveaux) jouables. C'est à dire, positionner les notes en fonction de la position naturelle des mains sur le clavier afin d'avoir des charts amusantes mais aussi proposant un certain challenge, et pour ça il faudra beaucoup expérimenter...




Autrement, niveau technique c'est programmé en Scala avec LWJGL (opengl + openal). A part le design, à ce ce jour j'ai un parser de fichier de musique fonctionnel (j'expliquerais le format et comment créer une musique quand ce sera plus avancé) et un début de moteur graphique 2D.




Cette fois je vais vraiment essayer de ne pas lâcher le projet !

    
    
          

              aucun commentaire
              aucun rétrolien              

        

    
          


    
lundi 22 février 2010
    
    
Aperçu de the mean beet machine

    
    
Par Mr_Qqn    le lundi 22 février 2010, 11:37

    
            
    
    
          
Le développement du clone de puyo puyo n'avance pas très vite, mais le mode 2 joueurs est maintenant jouable (il y a encore 1 ou 2 bugs). J'ai aussi décidé de l'appeler "The mean beet machine" pour faire un jeu de mot avec la version européenne du jeu "Dr robotnik's mean bean machine".




puyo-puyo-0.2.png




Depuis le dernier aperçu, a changé :


    

  • La taille du jeu pour du 640x480, on peut comment ça avoir le jeu dans un coin de l'écran et ça permettra plus tard de l'inclure facilement dans une page web en tant qu'applet.
    • 

  • Les garbages puyos gris qui viennent gêner l'adversaire.
    • 

  • L'affichage des 2 groupes de puyos suivants
    • 

  • Les scores et les combos (qui suivent les règles de puyo puyo 2)
    • 

  • Des graphismes plus attractifs avec des animations
    • 




Le jeu est encore loin d'être terminé, il manque entre autres tous les menus avec la gestions de options, le mode réseau, les bruitages et la musique, les puyos d'autres couleurs...




Pour y jouer les touches sont :


    

  • pour le joueur 1 : les flèches  directionnelles
    • 

  • pour le joueur 2 : les touches 8,4,5 et 6 du pavé numérique
    • 




Lancer le jeu

    
    
          

              un commentaire
              aucun rétrolien              

        

    
          


    
samedi 30 janvier 2010
    
    
Aperçu du clone de Puyo Puyo

    
    
Par Mr_Qqn    le samedi 30 janvier 2010, 19:18

    
            
    
    
          
Je poste juste vite fait une version exécutable du jeu via java web start. Pour l'instant il n'y a que le mécanisme de déplacement des puyos et leur explosion quand 4 d'une même couleur se touchent. Y'a encore quelques bugs que j'ai pas corrigé, mais ça ne va pas tarder. Le jeu fonctionne sous Windows et est censé marcher sous Linux et Mac OS.




On joue avec les flèches directionnelles : droite et gauche pour se déplacer, bas pour accélérer la descente et haut pour faire une rotation. Lorsque les puyos sont "coincés" entre 2 colonnes et qu'il n'est plus possible de faire une rotation, appuyer 2 fois de suite sur haut inverse les puyos.




Le jeu nécessite Java 6 d'installé sur la machine. Pour ceux qui ne l'ont pas c'est ici : http://java.com/.




Pour la version web start c'est ici.




Ceux qui veulent le jar c'est là, mais il faut se procurer soit même la librairie Slick ici.




Autrement je cherche toujours un nom autre que puyo puyo pour ce jeu, même si je copie le gameplay, y'aura au moins le nom de différent. :p








Sinon, petit fait intéressant pour les développeurs Java : je n'ai pas été obligé de signer le jar de mon application alors que je fais appel à du code natif. En fait, plutôt que d'indiquer tout les jar et les natifs un par un dans le fichier jnlp, j'ai à la place indiqué l'extension Slick regroupant tous ces fichier. Et cette extension étant déjà signée, je n'ai plus besoin de signer mon application.




Le code du jnlp pour illustrer :



<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE jnlp PUBLIC "//UNKNOWN/" "http://java.sun.com/dtd/JNLP-6.0.dtd">
<jnlp spec="1.0+" codebase="http://mrqqn.net/dotclear/public/puyo-puyo/">
	<information>
		<title>Puyo Puyo clone</title>
		<vendor>Mr_Qqn</vendor>
		<homepage href="http://mrqqn.net/dotclear/" />
		<offline-allowed />
	</information>
	<resources>
		<jar href="puyopuyo-0.1.jar" />
		<extension href="http://slick.cokeandcode.com/demos/slick.jnlp" />
	</resources>
	<application-desc main-class="net.mrqqn.jellyop.Main">
	</application-desc>
</jnlp>


    
    
          

              aucun commentaire
              aucun rétrolien          2 annexes          

        

    
          


    
mardi 26 janvier 2010
    
    
BME Player

    
    
Par Mr_Qqn    le mardi 26 janvier 2010, 17:18

    
            
    
    
          
Je remet aussi en ligne mon player de BME (fonctionnel !) fait à l'occasion du simulateur Beatmania abandonné.




Pour le lancer c'est très simple :


    

  1. On extrait les fichiers du zip
    2. 

  2. On ouvre la console (cmd sous Windows)
    3. 

  3. On se positionne dans le dossier extrait
    4. 

  4. Et on tape qqnbmeplayer "[chemin du fichier bme]"
    Pour ceux qui ne sont pas sous Windows la commande est java -Djava.library.path=lib -jar qqnbmeplayer.jar "[chemin du fichier bme]"
    5. 

  5. Et là normalement ça marche (les nombres qui apparaissent à intervalle réguliers correspondent aux secondes, ça sert pour situer à peu près le bug).
    6. 




Si vous vous retrouvez avec une erreur du genre JavaHeapSpace c'est qu'il y a beaucoup trop de sons et qu'il n'y a pas assez de mémoire allouée à java. Pour corriger ça, il faut utiliser  java -Djava.library.path=lib -Xmx128M -jar qqnbmeplayer.jar "[chemin du fichier bme]" (128M correspondant à la taille de mémoire allouée à java).




Pour ceux qui n'ont pas de fichiers BME, allez jeter un coup d'œil ici : http://www.yamajet.com/music/index.html et pour les BME de Yamajet qui sont plutôt sympas c'est là : http://www.yamajet.com/music/list.html.




Pour le télécharger c'est ici. Je joins aussi les sources pour ceux que ça intéresse, la partie concernant le parsing et la lecture d'un BME peut être utile, on sait jamais.

    
    
          

              aucun commentaire
              aucun rétrolien          2 annexes          

        

    
          


        
    
Formats BMS et BME

    
    
Par Mr_Qqn    le mardi 26 janvier 2010, 10:00

    
            
    
    
          
Je remets en ligne de l'explication sur les formats BMS et BME utilisés sur les simulateurs Beatmania étant donné qu'il y a très peu de ressources à ce sujet en français et même en anglais. En même temps c'est plutôt normal vu que ça reste très marginal comme jeu.




Explication générale du format




Le format BMS (Be-Music Script) est un type de fichier utilisé pour représenter les notes d'une musique Beatmania ou Pop'n'Music. Il a été créé (si je ne me trompe pas) à la base pour Be-Music, certainement un des premiers simulateurs Beatmania. Il a ensuite laissé la place au format BME (E pour extension ou truc du genre :p), du fait qu'avec l'apparition de IIDX on ne joue plus avec 5 mais avec 7 touches.




La particularité du format BME est que c'est une extension du format BMS et par conséquent il assure la rétrocompatibilité (pour peu que ce soit bien codé).




Du côté utilisation, ce format est le plus largement utilisé sur les simulateurs Beatmania existants (en fait je crois que c'est le seul) autant pour les rip des mix officiels que pour les créations indépendantes. C'est donc inconcevable que je fasse le simulateur sans la prise en charge de ce format. Ne pas le faire serait aussi stupide que de faire un éditeur de texte qui ne lit pas les fichiers texte.




Coté technique, la structure du format est assez simple. Il s'agit d'un simple fichier texte contenant les informations de la musique.




2 parties :


    

  • Définition des propriétés de la musique
    • 

  • Déroulement de la musique
    • 




La principale ressource disponible sur le web qui décrit ce format est la spécification du format BME. On y trouve la structure générale d'un fichier type et la liste exhaustive des différents paramètres possibles. Cependant la partie du déroulement de la musique n'est pas très clair; petite explication :




Les événements (notes, changement de tempo, etc...) sont répartis par mesure. Un message va donc être composé du numéro de la mesure de 0 à 999, du type du message (note, note de fond, image de fond, ...) et ensuite des événements à proprement parler.




Par exemple, je veux assigner le son 15 à la touche 1 et le faire jouer sur les 4 pulsations de la mesure 1 :

#00111:15151515




Maintenant je veux assigner le son D8 à la touche 2 et le faire jouer sur les 2 premières pulsations de la mesure 1 :

#00112:D8D80000




Concrètement comment c'est interprété ?


    

  1. On prend d'abord les 3 premiers numéros pour obtenir le numéro de la mesure
    2. 

  2. On prend les 2 suivants pour obtenir le type de message (ici 11 = touche 1 et 12 = touche 2)
    3. 

  3. On prend ensuite tout ce qui se trouve après les <<:>>, ça correspond au message de la mesure
    Chaque <<objet>> est codé sur 2 caractères, ici on a des <<15>>, des <<D8>> et des <<00>>. <<00>> étant un objet particulier signifiant qu'il ne se passe rien.
    4. 

  4. On répartit tout les objets du même message également sur la mesure.
    5. 




Pour l'exemple 1, le message 15151515 contient 4 objets donc on va diviser la mesure en 4 et y répartir ses objets dessus : 


Temps : 0/4 1/4 2/4 3/4
        15  15  15  15



Magie ! Le son 15 est donc joué sur les 4 pulsations de la mesure soit tout les 1/4 de mesure.




Pour l'exemple 2 :


Temps : 0/4 1/4 2/4 3/4
        D8  D8  00  00



On a donc bien ici D8 de joué les 2 premières pulsation de la mesure. Si on aurait voulu les jouer sur les 2 premiers 1/8 de mesure il faut diviser la mesure en 8 soit y rajouter 4 <<00>> : #00112:D8D8000000000000




Note : le message #00111:15151515 est égal au message #00111:1500150015001500 : Dans les 2 cas, les objets <<15>> sont placés sur les temps 0/4, 1/4, 2/4 et 3/4.




La spécification ne précise pas non plus, même si peu utilisées, comment fonctionnent les notes tenues. Pour ça, c'est pas très compliqué : on définit dans le message un point de départ et un point d'arrêt. Le point de départ est un objet correspondant à un son et le point d'arrêt peut être n'importe quel objet excepté <<00>>. Par exemple le message #00151:B000EE00B000EE00 va donner les notes tenues suivantes :


##__##__ soit #_#_
# : note tenue pendant 1/n de la mesure
_ : rien pendant 1/n de la mesure




Et une précision concernant les notes invisibles présentes dans la spécification, celles-ci servent en fait à mapper d'autres sons sur les touches essentiellement si le joueur veux improviser quelque chose pendant certaines parties vides.




(Merci à Ultra Violette, créateur du simulateur Be-Pachi Music, pour son aide sur ce format)




Spécification plus détaillée du format




La spécification anglaise du format est en fait bien vieille et une nouvelle bien trop plus complète et est en écriture et uniquement en japonais ici. Elle regroupe tout les paramètres rajoutés par les différents simulateurs sur le format dont certains sont très peu utilisés, y'a un peu de tri à faire. Si comme moi, vous ne savez pas lire le japonais, Google translate bien qu'il donne une traduction plutôt bizarre permet quand même de déduire le sens des éléments.




Merci à Yamajet pour ces précisions.

    
    
          

              aucun commentaire
              aucun rétrolien          une annexe          

        

    
          


    
dimanche 24 janvier 2010
    
    
Clone de Puyo Puyo

    
    
Par Mr_Qqn    le dimanche 24 janvier 2010, 16:19

    
            
    
    
          
Comme ça faisait longtemps que je n'avais pas programmé de jeu (j'en commence quelques uns mais j'en fini aucun), je me suis lancé dans la création d'un autre jeu, mais cette fois-ci un qui est "simple" à réaliser : un clone de Puyo Puyo. Je préfère pour l'instant réaliser le clone d'un jeu, bien que j'ai plein d'idées de gameplay, pour pouvoir bien prendre en main le moteur de jeu et me concentrer sur la jouabilité du jeu. Comme en plus je n'ai pas trouvé de version PC et que c'est un jeu que j'aime bien, c'est certainement pas du temps de perdu.




C'est un jeu de puzzle que j'ai découvert en tant que Dr. Robotnik's Mean Bean Machine, la version européenne du jeu. Le but est de marquer le plus de points en assemblant 4 puyos ou plus de la même couleur. Là où il diffère d'un jeu de puzzle plus classique, c'est grâce à son mode duel : plus un combo est long, plus l'adversaire va recevoir de puyos gris qui bloquent l'accès à ses puyos de couleurs.




Mais mieux que des mots pour avoir un aperçu du gameplay : des vidéos.




Le gameplay du clone sera basé sur Puyo Puyo 2 et donc il n'est pas prévu de mettre les nouveautés du gameplay des versions plus récentes, comme les blocs composés de plus de 2 puyos.




Dans un premier temps, je vais faire la version 2 joueurs sur une même machine et après je rajouterais le réseau, et si c'est pas trop compliqué, une IA.




Les graphismes sont en 2D et pour l'instant je redessine tout (et y'a pas de raison pour que ça change), par contre au niveau de la musique et des bruitages, je vais m'y essayer au moins pour l'expérience, mais je ne garantie pas un super résultat, alors y'a de grandes chances que je me fournisse sur Jamendo ou 8bitcollective.




Niveau programmation, j'utilise Java en association avec la librairie de jeu 2D Slick qui est vraiment complète. Pour ceux qui ne connaissent pas Vince, voici son site avec de bons jeux faits avec Slick.




Je vais attendre d'avoir quelque chose d'un peu plus jouable et moins buggé avant d'en poster une démo, mais en attendant voilà une capture d'écran de la version actuelle.




Puyo Puyo 0.1

    
    
          

              2 commentaires
              aucun rétrolien