GUI, FX et autres…

En ce début 2014, je me consacre principalement à obtenir une expérience de jeu telle que j’ai pu l’imaginer. Depuis fin novembre, le jeu est « autonome ». J’entends par là qu’il y a un menu fonctionnel qui renvoi vers le premier niveau, si le joueur meurt le niveau se relance et s’il atteint la fin du niveau, quelques statistiques sont affichées et on retourne au menu étant donné qu’il n’y a qu’un niveau pour le moment. Presque tout les éléments de gameplay sont intégrés, le scoring par exemple reste à finaliser. Ce qu’il manque le plus à ce premier niveau, c’est un bon rythme et une difficulté progressive.

Du point de vu design, j’ai retravaillé le HUD pour qu’il soit proportionnel quelle que soit la résolution. J’ai aussi fixé le ratio au 16/9. Dans le même esprit, j’ai lu sur un forum une discussion à propos des frame rate fixe (30 ou 60fps) dans les shmup. C’est un point auquel je n’ai pas pensé. A voir s’il je l’applique mais, pour le moment j’ai des soucis de performance sur les machines peu véloces. Je me suis rendu compte qu‘iTween en était la principale cause : j’ai voulu faire simple et animer les rotors des avions avec iTween. Sur ma machine princpale (core i5 3570k, gtx 670) ça passe sous soucis et je n’avais pas l’impression que ça ait un impact. Mais sur mon portable (core2Duo T9400, ati HD3650), le jeu était étrangement lent, j’ai pensé d’abord à l’impact des shaders. Les supprimer n’a rien changé, j’ai fini par désactiver les rotors et le fps à doublé…

Toujours sur le HUD, j’ai ajouté une « barre de scratch » qui permet de se représenter la quantité de scratch à faire avant de franchir un nouveau palier. J’ai aussi représenté dans chaque palier le coût de celui-ci.

Côté FX, j’ai retravaillé les sons de tir du joueur, c’est pas encore ça…mais c’est en progression. Mais chose pour l’aspect des bullets qui devient plus convainquant. Il me reste encore à faire pour présenter et diffuser une version convaincante et fun à jouer.

A suivre…

Publicités

Prodonfeur, oh profondeur!

En début d’année j’avais mis en place un système de collision reposant sur les axis-aligned bounding box (AABB). Cela fonctionnait et fonctionne toujours très bien. Voilà que cette semaine, je me suis enfin décidé à travailler sur un niveau pour mettre en place le gameplay, le rythme de jeu et donc tester « en condition » tous ce que j’avais écrit comme code jusqu’à présent.

J’en arrive aux NPCs terrestres. Depuis le début je veux les inclure dans le jeu mais, j’ai toujours repoussé leur intégration. Naïvement je me suis dit que le code AABB allait marcher comme sur des roulettes…que nenni! J’ai remarqué que plus le NPC  était en-dessous du plan (Y = 0) sur lequel évolue le joueur, plus le zone de collision était désaxée. On observe clairement ce phénomène due à la projection en plaçant deux NPCs à la verticale, l’un avec un Y à 0 et un second à -35 par exemple.

Vue dans l'éditeur / Vue ingame

Bien que les coordonnées X et Z servant au test de collision soient identiques, la collision du NPC à -35 se fait au niveau du NPC à 0. Je me suis donc attaché à trouver comment corriger cela. Après des journées à potasser de la doc sur les projections, tester des ratios ne fonctionnant qu’une fois sur trois, je me suis replongé dans la doc officiel de Gamecore…j’aurais dû faire ça depuis le départ.

La solution se résumait en un mot : ProjectToScreen.  J’avais pensé le AABB à partir des « coordonnées world » donc quand les objets évolues sur le même plan il n’y a aucun problème. Pour éliminer la contrainte de la profondeur, il faut simplement convertir les coordonnées world en coordonnées normalisées grâce à la fonction ProjectToScreen et effectuer les collisions AABB sur ces dernières.

Au final, je retiens une chose : lire d’abord la doc officielle avant de partir sur de « grandes » formules.

Camera…

La création d’un script de base pour le déplacement de la camera et du joueur avance doucement. Je suis parti d’un script fourni avec GameCore mais, l’adapter à mes besoins nécessite plus de modifications que prévu. Par défaut, le script original oriente le déplacement de l’objet « joueur » selon la direction de la caméra, pour un shmup la caméra doit garder la même orientation.