Re: IRENA - Genesis Metal Fury

[Invité]

Bravo Shingo !!
Faut continuer !!!

[Invité]

Oui doucement, mais sûrement

Voici ma feuille de route pour la fin de l'année :

- Intégrer et définir le comportement des astéroïdes
- Permettre aux modules de se déplacer autour du vaisseau
- Refonte complète du menu principal
- Création d'un utilitaire destiné au scénario des niveaux

C'est déjà pas mal de boulot en perspective !

[Invité]

On trouvera une soluce pour tes modules.

[Tryphon]

C'est quoi le problème avec les modules ?

[Invité]

Pour les modules, il faut que j'apprenne à déplacer un sprite de façon circulaire sans que cela soit très gourmand en ressources. C'est une feature que j'aurais vraiment adoré ajouté.

D'ailleurs je songe à proposer au joueur, en début de partie, de choisir la position des modules :

1) Tourner autour du vaisseau
2) Au dessus et en dessous du vaisseau mais orienté vers le haut et le bas.
3) Derrière le vaisseau.

Pour le moment je les ai désactivé du code.

[Invité]

Allez une petite vidéo pour vous montrer ce que donne les astéroïdes

[Invité]

cool 
Par contre ça fait bizarre les tir qui passent à travers les astéroïdes

[Invité]

C'est tout à fait normal, je n'ai pas encore fait de collision entre les differents sprites. C'est assez rapide à mettre en place, le plus important c'est de coordonner les astéroïdes de manières à ce que les ennemis ne les traverse pas en les évitant ou en ayant une trajectoire différente.

[Invité]

Ca rend très bien comme ça.

[Invité]

Merci je pense que le résultat sera top quand j'aurais intégré les autres astéroïdes. Je vais également pouvoir mieux travaillé le mouvement du robot !

Au boulot !!!!

En fait je me rends que j'avais déjà bien avancé sur le projet mine de rien et qu'il me reste surtout à créer les maps pour les autres niveaux et définir les comportements ennemis.

[Tryphon]

Pour les modules, il faut que j'apprenne à déplacer un sprite de façon circulaire sans que cela soit très gourmand en ressources. C'est une feature que j'aurais vraiment adoré ajouté.

C'est très facile. Tu stockes dans deux tableaux dx[] et dy[] les coordonnées des différents points du cercle par lesquels tu veux que ton module passe, et tu les ajoutes à celles de ton vaisseau.

Par exemple, si tu veux que ton module aille de 45° en 45° sur un cercle de rayon 2O pixels, tu vas prendre :

Code:

u16 dx[] = {2O, 14, O, -14, -2O, -14, O, 14}; // tu peux aussi prendre des fix si tes coordonnées sont en fix
u16 dy[] = {O, -14, -2O, -14, O, 14, 2O, 14};


et, à chaque frame, tu mets à jour un champs "index" dans ta structure module (pour savoir où tu en es) :

Code:

module->x = vaisseau->x + dx[module->index];
module->y = vaisseau->y + dy[module->index];
module->index++;
if (module->index >= 8) module->index = O;


Bien sûr, 45° ça fait tourner trop vite, prends plutôt 6° (mais ça fait deux tableaux plus longs).

Pour calculer les données de ton tableau, tu fais r*cos(k*2*pi/N) pour dx, r*sin(k*2*pi/N) pour dy, où N est le nombre d'étapes pour faire un tour complet (donc moi j'ai prix N = 8, mais si tu fais 6° tu prends N = 6O, donc 1 seconde pour faire un tour complet), r c'est la distance entre le vaisseau et le module (rayon, moi j'ai pris r = 2O) et k va de O à N - 1.

[Stef]

SGDK inclus des fonctions trigo (sin et cos), c'est pas bien compliqué de faire tourner les modules avec Le problème de Shingo, je dirais que c'est plutot les maths et non l'algorithmie (j'ai le même soucis, mon niveau de maths me limite parfois dans ce que je veux faire...).

[Invité]

Oui je confirme, je suis une quiche en math et ça me freine beaucoup.

Merci @Tryphon pour avoir apporter la solution, je tenterais d'implémenter ça prochainement :)

[Tryphon]

stef : ce sont des tables tes fonctions trigo ou tu les calcules ?

[Hpman]

Code:

u16 dx[] = {2O, 14, O, -14, -2O, -14, O, 14}; // tu peux aussi prendre des fix si tes coordonnées sont en fix
u16 dy[] = {O, -14, -2O, -14, O, 14, 2O, 14};


Code:

module->x = vaisseau->x + dx[module->index];
module->y = vaisseau->y + dy[module->index];
module->index++;
if (module->index >= 8) module->index = O;


Une table suffit, avec un décalage de 90°:

Code:

u16 dx[] = {2O, 14, O, -14, -2O, -14, O, 14};

module->x = vaisseau->x + dx[module->index];
module->y = vaisseau->y + dx[(module->index+2)&0x7];

module->index=(module->index+1)&0x7;


Je recommande une table relativement grande (512 ?), ce qui permet de faire varier la vitesse des modules en incrémentant plus ou moins rapidement l'index.

[Invité]

Allez une petite vidéo pour vous montrer ce que donne les astéroïdes

Très sympas, mais je trouve les astéroides bcp trop lents .
Mais sinon c'est vraiment pas mal .

Pour les pods j'avais commencé un shoot sur SGX, et j'avais codé les pods qui tournent,tu peux te servir d'une table preclac de valeurs X/Y pour les rotations, c'est ultra rapide,et de toutes façons je vois mal les calculer en temps réels .
Bon moi j'avais utilisé des valeurs au pif, et en très petit nombre, donc ça rendait pas top, mais l'idée c'est ça .

[Invité]

Vous êtes des dieux, merci.

[Tryphon]

Une table suffit, avec un décalage de 90°

Oui, mais je voulais garder un truc assez général (tu peux facilement modifier pour n'importe quelle trajectoire) et facile à comprendre.

Sinon tu peux aussi ne stocker qu'un quart de table et ajouter ou soustraire le dx, dy selon le quadrant.

Je recommande une table relativement grande (512 ?), ce qui permet de faire varier la vitesse des modules en incrémentant plus ou moins rapidement l'index.

Ouaip, bonne idée.

Je pense aussi qu'un module qui continue de tourner même quand le vaisseau se déplace, ça va rendre bizarre (si mes souvenirs sont bons, dans R-type, ils te suivent en léger décalé et ne se remettent à tourner que quand ils t'ont rattrapé).

[Invité]

Je pense aussi qu'un module qui continue de tourner même quand le vaisseau se déplace, ça va rendre bizarre (si mes souvenirs sont bons, dans R-type, ils te suivent en léger décalé et ne se remettent à tourner que quand ils t'ont rattrapé).

TF3 et 4 le font, et ça choque pas, y'a pas de raisons,cependant ils sont collés au vaisseau (rayon fixe) et n'ont pas d'inertie .

[Stef]

stef : ce sont des tables tes fonctions trigo ou tu les calcules ?

Oui bien sur ce sont des tables (sinon ça serait pas vraiment utilisable ^^) et de mémoire elles ont 1024 entrées (pour avoir une précision assez fine).
Les valeurs sont encodés en fix32 (donc 10 bits pour la partie décimal avec un bit de signe).

[grostonton]

Ca déboite sévère Shingo ! bien joué !

@aux_autres, j'adore quand vous parlez chinois ^^

[Invité]

@grostonton merci :)

@Stef dès que j'en aurais fini avec la cave map, je me penche sur cette table.

Je pense qu'une fois que j'aurais terminé de bien assimiler le scrolling et cette fameuse table pour faire bouger les modules autour du vaisseau, je pourrais avancer plus rapidement et me concentrer vraiment sur le level design.

J'y suis presque !

[Invité]

Bravo à toi.
Ne jamais lâcher et aller au bout d'un projet, c'est la chose la plus importante au bout du compte.
En plus tu lui a donné un sens en choisissant le nom de ta fille, c'est vraiment sympa.

Tu vas apprendre de cette expérience et passer un cap pour aboutir sur d'autres projets qui federeront des talents et de nouvelles amitiés.

[Invité]

Bonjour à tous les amoureux du shmup !

Je viens dé-poussier un peu le topic officiel de mon projet "IRENA" que je songe sûrement à renommer en "MEGA IRENA" pour bien souligner le fait que c'est un jeu Mega Drive et me motiver à donner le meilleur de ma personne.

Merci à ceux qui soutiennent le projet et qui m'aide à comprendre le fonctionnement du SGDK et de la réalisation d'un jeu 2D sur ce type de machine.

Pour l'heure, j'ai décidé de tout recoder pour avoir une meilleure organisation. J'ai revu entièrement le système d'ennemi et je n'avais pas envie de faire X modification dans le code actuel. De plus, cela me permet de me remettre à niveau, car cela faisait des mois que j'avais pas vraiment codé avec SGDK.

Alors contrairement à ce que pourrait @marmotjoy et certains d'entre-vous, non le projet n'est et n'a jamais été abandonné ! Pour preuve, j'ai réalisé une première ébauche de la cave map faisant 4096x208 ce qui n'est pas du mal du tout.

Je me suis grandement inspiré de Thunder Force III en insérant pas mal de petits pièges avec des ennemis pouvant survenir par des trous situés en haut, en bas, mais ils pourront aussi survenir par l'arrière. Des piliers en roche seront bougeront très lentement, parfois rapidement et il faudra vraiment bien gérer vos déplacement avec une grande précision. Des bonus seront disponibles, mais difficilement accessible :)

Actuellement, je travaille sur la collision des tiles et grâce à @Touko @Tryphon j'ai bien avancé avec une précision convenable. Je tiens à apporter une certaine précision, non pas pour frustrer le joueur, mais de justifier l'explosion du vaisseau.

Voici la marge d'erreur possible :







Donc le joueur pourra analyser frame par frame qu'il ne s'est pas fait avoir par un développeur faignant et vicieux.

Ce n'est pas évident de concevoir ce genre de niveau, car j'avoue être tenté par mettre le paquet sur la difficulté afin de satisfaire les fous d'entre vous, mais j'ai envie également de permettre à tout le monde d'en profiter. Donc, il faudrait que je trouve le juste milieu ou bien alors créer des niveaux de difficulté intermédiaire.

Merci @StudioVetea pour tes conseils et tes messages qui me donne la motivation de continuer.

[Invité]

Il manque des ajustements sur la collision top et bottom, mais ça semble déjà bien fonctionner.

Parfois la collision n'est pas active, mais c'est normal, car quand le vaisseau vient juste d'apparaître se serait bien bien cruel de ma part de détruire le vaisseau aussitôt à la prochaine collision.

[Invité]

Forcément quand on a compris comment fonctionne une tilemap, tout va plus vite.

Prise en charge de la collision des bullets, j'ai fais au plus simple histoire de ne pas bouffer trop de ressources. Je me contente de tester sur 8 tiles max et suivant une logique déterminant quelle type sera le plus susceptible d'être en collision avec une bullet. Le reste est ignoré.

[Invité]

Dans TF3 les collisons sont aussi tres laxistes,donc faut pas s affoler.

[Invité]

Oui t'en as que ça fonctionne et ne gâche pas le plaisir de jeu c'est l'essentiel.

Je pensais pas que se serait la carte définitive, mais en la parcourant j'ai pleins de petites idées en tête en fonction du parcours choisi la par le joueur.

Par exemple, quand t'as le choix d'aller par le bas ou par le haut, je voulais qu'en bas un mecha déboule et comme le joueur n'est pas présent il revient en arrière et il va attendre le joueur un peu plus loin. Si le joueur ne l'a pas éliminé à temps, ce dernier va se retrancher dans un trou pour ressortir subitement derrière lui lançant un tir fatal !

[Invité]

Faut innover et essayer de pas copier ce qui a deja ete fait.

[vincent2105]

Je suis de loin mais non sans intérêt le topic. 
Une des difficultés j'imagine, ça va être d'adapter les déplacements des ennemis en fonction du background.
Bon courage pour la suite shingo

[Invité]

@vincent2105 merci ^^ Pour le déplacement des ennemis, vraiment pas le choix, se sera scripté au cas par cas, mais ça permet de vraiment bien travailler chaque phase d'action plutôt que faire du générique.

Le truc un peu chiant c'est qu'on a pas une console en sortie qui pourrait nous afficher chaque données en temps réel histoire de gagner du temps. SGDK peut afficher des infos dans une console, mais c'est une boîte de dialogue qui scroll en permanence donc... c'est peu lisible.