Encore un fois, le site de Gamecore est H.S depuis la semaine dernière.
Once again, Gamecore’s website is down.
R.I.P !?
Répondre
Ça sent le sapin…
update : Les sites d’Helios sont de nouveau en ligne, fausse alerte. Helios website are back online, false alarm.
Depuis le 21/12, le site de Gamecore est H.S ainsi que tous les sites liés à la société Helios, propriétaire du moteur. Au vu de leur silence depuis près d’un an, il y a peu de chance que cela annonce une refonte des sites.
Pour ceux que cela pourrait encore intéresser, voici le lien vers la dernière version de Gamecore :
http://www.fileserve.com/file/b3GG3Ex/GameCore_2.5.6.26_Installer.exe
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 :
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.
Scratch system
Les premières lignes de code pour le scratching sont en place. Il me reste à y associer le principe des paliers de scratch que je désire pour que le système soit pleinement opérationnel, et par la suite associer des patterns différents à chacun des paliers.
The first few lines of code for scratching are in place. I still have to involve the principle of levels of scratch I want to make the system fully operational, and then associate different patterns at each level.
New Sponza demo available
update Sponza demo
Parallèlement à mon shoot’em up, je me suis remis sur ma demo de Sponza. Au bout d’un an j’ai enfin ajouté le cycle jour/nuit. La nouvelle demo devrait être disponible en fin de semaine.
Along with my shoot’em up, i’m back on my demo Sponza. After a year i finally added the day/night cycle. The new demo should be available this weekend.
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.
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?
Prototype, phase 2
Les choses avancent bon train. Suite à de nombreuses prises de têtes en raison de mon obstination à vouloir faire simple, c’est-à-dire écrire peu de code, en utilisant un système de collision “clé en main” à base de bounding boxes pour les bullets, je me suis décidé à faire autrement.
En relisant différents article ici et là (en particulier ce dernier), j’ai finalement implanté un système de collision inspiré des Axis-Aligned Bounding Boxes (ou AABB). Dans le cas des bullets des NPC, pour chacune d’elles, on définit une paire d’axes XZ minimum et une maximum. Le carré ainsi défini représente la zone de collision de l’objet, il ne reste plus qu’à comparer ces axes à ceux du AABB du joueur. Chaque bullet vérifie si son axe X min. est supérieur à l’axe X max. du joueur et si l’axe X min. du joueur est supérieur à l’axe X max de la bullet. Tant que cette condition est vrai, il n’y a pas intersection. Même chose pour l’axe Z. Lorsque les conditions sont inversées pour les deux axes, il y a intersection et donc collision entre la bullet et le joueur.
Voilà pour le principe, il me reste plus qu’à faire plus de tests et à affiner la taille des boxes le cas échéant mais ce système est fiable et simple en calcul.
