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.

quoi de neuf depuis…

Alors histoire de donner des nouvelles fraîches et de montrer qu’il y a au moins encore une personne qui utilise Gamecore voici deux, trois infos.

Depuis plusieurs semaines je travaille en dilettante non sans faire de bonnes avancées, comme un problème de synchronisation entre la vitesse de déplacement de la camera et du joueur. Ce bug était présent depuis la première version du script et le problème venait d’UNE variable exécutée au mauvais moment 😦

Le point sur lequel j’ai le plus avancé est le système de création de pattern de tir. Dans cette première version, chaque NPC dispose de 5 slots. Selon le type de pattern voulu, un ou plusieurs slots peuvent être utilisés. Le principe de base repose sur une rotation de la bullet par rapport à son point de départ, rotation qui s’incrémente d’une x valeur à chaque nouvelle création jusqu’à atteindre un maximum. Après soit la rotation est remise à zéro ou inversée. Voici à quoi ressemble la liste des variables pour un slot :

patternType[0].fireRate = 4;
patternType[0].fireRateReset = 4;
patternType[0].patternLoop = 4;
/***********************/
patternType[0].activSlotOne = true;
patternType[0].invOne = true;
patternType[0].slotOneRot = 0;
patternType[0].slotOneRotRst = 0;
patternType[0].slotOneRotVal = 0;
patternType[0].maxOneRot = 0;
patternType[0].minOneRot = 0;

A l’écran voici à quoi ressemble mes premiers essais avec ce script de pattern :

 [vimeo  28306310 w=400&h=245]

Ces nouvelles lignes de codes m’obligent à faire beaucoup de nettoyage, entre du code obsolète, les doublons, les loops qui devraient ne faire q’un tour… Côté level design, je concentre sur un premier niveau et principalement sur le rythme de celui-ci : où et quand envoyer des NPC, quels patterns  les faire tirer, etc…

Enfin, côté design pur c’est toujours le calme plat bien que, tout en travaillant sur le rythme d’un premier niveau, j’essaie différentes façons d’accélérer la modélisation. Au final, la plus évidente est de partitionner les objets pour les assembler ensuite, pourquoi refaire 5 fois la même chose. Il me sera plus simple, et plus rapide, de faire 5 variations d’un fuselage et d’y ajouter les mêmes ailes. Vu de l’extérieur cela peut paraître évident, mais pas pour moi quand j’ai commencé ce projet.

Video : First prototype

Voici l’heure de la première présentation de mon prototype de shoot them up.

Cette vidéo ne présente que les éléments actuellement fonctionnels : collisions entre les bullets et le joueur ou les NPC, le déplacement de ces derniers selon des courbes de Bézier puis leur « dispersion » en fin de parcours, un comptage du score ultra basique et des premiers essais de fx. Le tout fonctionne bien, il ne faut pas se fier aux chute des framerate durant la vidéo, elles sont dues à la capture vidéo.

Lire la suite

Une histoire de cubes…

La mise en place du prototype passe par la création d’un niveau bien plus développé que celui que j’utilisais jusque là. Les NPC sont disposés via de simples cubes associés à un script, ce dernier défini, entre autres, la direction que doit prendre le NPC. Au départ l’idée me semblait bonne mais voilà, plus le niveau se rempli, moins je sais qui va où!!

Qui fait quoi?

Lire la suite