Présentation des capsules (v1.0) sur lesquelles le joueur devra tirer pour libérer des sons.
Parlons un peu background en quelques lignes :
Le jeu se passe dans le futur, en 2084 pour être précis. Les libertés se sont peu à peu évaporées et une loi stipula que toute forme de musique était alors interdite. Tous les sons créés pour le plaisir furent enfermés dans des capsules et envoyés dans l’espace.
Le joueur incarne deux vaisseaux : le blueKorg et le whiteMoog (Korg et Moog étant des marques d’instruments électroniques foudées dans les années 60 et 70). Ces vaisseaux ont été créés par un groupuscule pirate souhaitant déjouer les lois pour redonner aux humains les sons qui leur ont été volés.
Le joueur devra alors jouer de rythme, de précision et de réflexes pour détruire ces capsules et libérer les sons enfermés pour reproduire des mélodies.
Présentation des barres d’énergies (v1.0) de chacun des vaisseaux (blueKorg / whiteMoog). J’expliquerais le background du jeu un peu plus tard. Sur les parties remplies (bleues et blanches) en coin, figureront la la formation des vaisseaux qui seront détermines par l’orientation de la carte (qui va devenir une pyramide pour des raisons techniques et ergonomiques). En fonction de cette inclinaison, le joueur pourra libérer différents samples ou jouer sur des effets.
La jauge d’énergie représente la vie restante de chaque vaisseau. Si l’un des deux arrive à 0, la partie est perdue.
Voici un petit test d’intégration des glyphes sur les marqueurs fiduciaires. J’envisage d’oublier les carte pour les remplacer par des pyramides à base carré. De cette manière il serait possible, en tournant la pyramide, d’obtenir en fonction de l’orientation, la génération d’un sample différent. Le joueur pourrait alors se sentir un peu plus agir sur la musique.
Voici quelques tests de collision dans un environnement processing avec tracking de tags fiduciaires.
Il était important de pouvoir dissocier chaque marqueur, ce que TUIO fait très bien ici.
getX(), getY() et getAngle() permettent de récupérer la position des marqueurs et getSymbolID() récupère l’identifiant du marqueur.
Voici donc un exemple dans lequel j’ai placé une zone de collision. Lorsque les carrés (représentation des marqueurs) rentrent dans cette zone, ils deviennent vert et les boutons de la partie basse deviennent actifs. Un clic sur un de ces boutons déclenchera alors un « tir » du carré (futur vaisseau) correspondant.
Ayant publié hier un petit article sur l’utilisation combinée de flash et reacTIVision, j’ai été confronté à quelques problèmes. La technologie utilisée étant rudimentaire, il était impossible d’obtenir des interactions viables. Après quelques heures d’essais, impossible également de faire fonctionner les autres méthodes sous flash.
Je me suis donc tourné vers processing, qui présente une utilisation du protocole TUIO vraiment plus agréable et simple à exploiter.
Voici, ci dessous, un lien permettant de communiquer aisément entre reacTIVision et processing :
Après quelques test j’ai pu sans problèmes mettre en place une zone de collision, qui me permettra de localiser des cartes munies de marqueurs fiduciaires, comme expliqué dans le second concept.
4. Lancer reacTIVision en prenant soin d’avoir une camera ou une webcam branchée.
5. Lancer le fichier « run.bat »
6. Lancer « TuioDemo.swf »
7. Prendre soin de d’autoriser les transferts de donnés dans les paramètres flash, sans quoi la connexion serait impossible.
8. Cliquer sur « Connect »
Et voici le résultat :
Ce système est seulement fait pour supporter des interactions « simples ». Un trop grand nombre de marqueurs pourra faire freezer l’application, cela reste tout de même largement suffisant dans pas mal de cas.
Voici le troisième et dernier de mes concepts de jeux vidéos musicaux. Ce dernier propose de mélanger le genre musical avec le « shooting » au pistolet. La réflexion nous amène tout d’abord sur un concept basé sur la Wiimote, pour ensuite ouvrir sur une réflexion réalité virtuelle / réalité augmentée.
