[CoRoLia] Programmation

Sujet relatif à la programmation.
Afin de pouvoir connaitre les contraintes et possibilités du moteur de Coco.

Je sais pas si on en avait déjà parlé :

Il faudrait des Background pour le fond de nos niveaux. Un peu comme sur 16-bit des background qui ont un effet de parallaxe (se déplacent 2 fois moins vite que l'écran). Ils devraient être affichés sous les tiles et être visibles seulement si le tile est transparent.

L'idéal serait de pouvoir stocker des fichiers (avec des normes techniques ?) dans un dossier et attribuer un Background a un niveau de la manière de ton choix (le + simple et rapide pour toi car ce n'est pas un boulo qui va être répété plein de fois pour le LD).

En fait dans la façon dont son enregistrés les map, il y a déjà une partie réservée au background. Ce sera un nombre modifiable dans le fichier texte (le faire par l'éditeur serait compliqué pour pas grand chose )

Cool !
Donc c'est fonctionnel ?
Comment je pourrai tester ? (Ou tu penses qu'ils vaut mieux que ce soit toi qui intègre cela ?)

Pour l'instant ce n'est pas fonctionnel car je ne savais pas comment exactement le gérer : comment le fond boucle, comment on organise la liste des background (les fichiers image ) je pense que un nom générique suivi du nombre correspondant au background devrait suffire.

Mais une fois que ce sera fait, tu pourras tout à fait le faire toi même : si tu ouvres un fichier ".lvl", il y a une ligne "Panorama" avec pour l'instant il y a 4 emplacements mais je vais corriger ça (je l'avais fait au tout début du projet quand romain participait )

Allo !

J'ai découvert une sorte de bug qui pourrait un peu gêner la maniabilité des personnages.
C'est au sujet des plateformes. Elles sont solides (ont une collision), normalement, seulement quand on tient dessus, sinon on peut les traverser par le bas ou les bords.
Cependant elles sont solides dans des cas un peu spéciaux. Par exemple avec le Knight, si on lance la Rocket en face d'une plateforme on va se cogner contre sa bordure et s’arrêter comme si c'était un mur, alors qu'idéalement il faudrait qu'on la traverse. Pire, si on tente de lancer la Rocket alors qu'on touche une plateforme (par exemple qu'on est en dessous en sautant et la touchant avec la moitié supérieure du corps) on ne pourra tout simplement pas lancer la Rocket.

Tu as une idée pour contourner ce problème ?

Up. As-tu vu ce message ?

Yep, je l'ai ajouté à la liste des taches ^^

Super, merci !!

Je suis en train de réfléchir pas mal sur les tirs et j'aimerai tester des choses... J'ai une demande pour toi, Coco, concernant tout ça. Dis-moi si tu peux le faire sans trop de mal pour la prochaine fois.

Délai des tirs.
Actuellement quand on appuie sur la touche de tir le héros joue son animation et en même temps le projectile est lancé.

Il faudrait ajouter un délai de quelques frames au moment où la touche est appuyée avant que le projectile ne se lance réellement ? Ce serait un délai très court, sûrement 1 à 5 frame max, je pense. Ça permettrait que le tir parte quand l'animation est un peu plus avancée. Il faudrait que cette valeur puisse être différente sur les différents héros. Pour éviter les problèmes (si le joueur appuie très vite, par exemple) il faudrait que pendant ce laps de temps il soit impossible d'entrer la commande d'un autre tir.

Il faudrait en plus, un deuxième délai, à la fin. Je te fait un schéma (tout se déroule à la suite, les séparation ----------- montrent qu'il faut que la condition juste avant soit remplie pour continuer).

Code:

-Appuie de la touche
-------------------------
-Animation tir
-Wait A (en frame)
-------------------------
-Projectile lancé
-Wait B (en frame)
-------------------------

Ça revient à :

Citation :

-le joueur appuie sur la touche
-l'animation de tir se lance (elle ne finie pas, elle se lance et commence)
-en même temps un Wait de X frame se lance

-Une fois le Wait fini : le projectile se lance
-en même temps un Wait de X frame se lance

Et le joueur peut de nouveau tirer. (Appuyer sur la touche pendant ce processus ne fait rien). En général les Wait seront très courts pouvant aller chacun de 0 à 5 frame, je dirai.


Si cela marche bien et que les tests sont satisfaisant ça reviendra a une nouvelle caractéristique des héros : la rapidité d'attaque.

D'après moi c'est assez prioritaire de tester, car ça débloquerait du coté graphique tous les doutes que j'ai.

Aussi, ceci serait pou un test avant tout, donc il suffit de l'intégrer pour le Knight et c'est tout. Il est possible que ce soit retiré par la suite si on ressent trop ce délai comme une gène.

Je ne pense pas que ça pose de problèmes. Je devais revoir le système d'animation d'attaque de toute façon ^^

Ce serait cool ! Merci !

Voila je l'ai inclus dans le projet. Il ne faudra pas abuser du premier wait je pense car la sensation est étrange quand il dure trop longtemps (plus de 2 frames je dirais ), on dirait qu'il y a une latence entre l'appui sur la touche et le tir (c'est le cas en fait ). Ca peut être désagréable en plein saut.

J'ai aussi rajouté la possibilité de choisir la durée de chaque frame d'animation de l'attaque pour chaque héros.

Tu crois qu'il faudrait que je fasse une nouvelle démo, ou je te la passe juste en mp ?

Tu as été super rapide ! O__O

Oui pour la latence, c,est ma crainte mais on va voir comment trouver un bon compromis. De plus, c'est vrai que dans Megaman il n'y a aucun latence et que c,est mon modèle principal. Mais il ne faut pas oublier que dans Megaman c'est un robot qui tir des balles. En fait, dans beaucoup de jeux le coup a une latence avant d'être effectué. Par exemple dans castlevania on voit le fouet en l'air avant qu'il s’abatte sur l'ennemi, logique, car le mouvement du coup est justifié. Un bruit et une anim se jouent dès qu'on appuie sur la touche mais le coup a une latence, pourtant c'est acceptable à nos yeux vu que quelque chose réagi juste après l'appuie.


Dans notre jeu c'est des personnages qui donnent un coup avec une arme et d'où un projectile sort. Je pense que ça peut être acceptable de voir ce mini delai. Forcement vu qu'il existe le LD ne sera pas automatiquement le même, principalement pour les coups en l'air. On va voir. Je pense que certains persos n'auront pas ce délai (ou quasiment pas) comme le Dragon qui crache une boule de feu, par exemple. Ca donnera un petit quelque chose en plus ou en moins à certains persos. Mais aussi peut être que ce délai sera identique sur tous les héros si ça devient dur de voir la différence entre les différents délais et que ce soit une gène.

Peux-tu me l'envoyer par MP ? Et si possible un petit screen ici de où modifier les choses. Merci.

Citation :

Tu as été super rapide ! O__O

Plus d'une heure quand même (j'ai pas encore le niveau de Slump qui peut poster la minute d'après )

L'anim d'attaque est bien plus belle et réaliste en fait avec la petite latence. C'est vrai que dans castlevania ça devient même un avantage parfois cette latence (ou du moins ça n'est pas un désavantage ).

Oki je vais te faire un mp alors (pas sur que tu puisse compiler par contre, vu que j'ai changé quelques librairies par rapport au réglage que l'on avait faits via le stream )

Ah merde... Faudra recommencer tout le truc sur Livestream alors ?
Parce que l'idée c'était justement que je teste pour les 3 héros.

Par défaut tu as mis combien pour les wait A et B ?

Tant mieux si au final tu trouves ça déjà mieux en tout cas. ^^

Citation :

Ah merde... Faudra recommencer tout le truc sur Livestream alors ?

J'en ai bien peur Mais ça devrait être plus rapide (moins de trucs à changer )

Par défaut j'ai mis les 2 wait à 2 frames chacuns et l'anim totale du knight à 7 frames.

Ok !

Bah, si ça te gène pas on pourrait vérifier que tout marcher ce week-end ?

Je serais pas là ce week end, mais j'essayerais de te faire un topo sur la procédure à appliquer avant de partir

J'avais fait une erreur dans le code, du coups dans mes test les wait A étaient équivalents à un wait de 5 frames. Donc au final je pense qu'on a pas mal de marge sur les wait

Ok ! Merci !

Allo !
Je me demande si c'est simple/possible pour toi de faire un projectile qui serait à tête chercheuse sur les ennemis ? Genre un tir qui se dirige vers l'ennemi le plus proche du héros.

Ça me semble peut être un peu dur donc avant que je fasse la fiche de la magie en question dis-moi si oui ou non tu crois pouvoir faire ça sans trop de difficulté. Merci.

Je peux faire sans trop de difficultés des projectiles qui repèrent quel est l'ennemi le plus proche d'eux et qui se dirigent ensuite vers lui. Par contre il y a pas mal de variantes dans les projectiles à tête chercheuse :
- le projectile cible un ennemi lorsqu'il est lancé et se dirige ensuite vers lui
- le projectile cible un ennemi lorsqu'il est lancé et change de cible si sa cible actuelle meurt
- le projectile change de cible s'il trouve un ennemi plus proche de lui que sa cible actuelle
En plus de ça il existe des projectile avec inertie (dans Megaman X par exemple il me semble )

Je pense pouvoir arriver à programmer toutes ces variantes (peut-être un peu plus de difficultés pour les projectiles à inertie, mais ça reste largement faisable )

Tu as tout bien résumé. Et si tu peux faire tout cela se serait parfait. L'inertie serait un grand plus aussi. Cependant c'est très difficile de te donner des directions à ce sujet mais vu que tu as cité Megaman X restons sur ce modèle.


A partir de 2:30 il y a plein d'exemples.

Ps : c'est pour une magie, et il n'y aura qu'un seul projectile à la fois. Je te ferrai la fiche pour cette magie alors.
Merci !

Citation :

le projectile change de cible s'il trouve un ennemi plus proche de lui que sa cible actuelle

On garderait uniquement cette règle alors ?

Sinon tu te rappelles ce que l'on avait décidé pour les projectiles traversant les ennemis ?

Citation :

- le projectile cible un ennemi lorsqu'il est lancé et se dirige ensuite vers lui

Oui.

Citation :

- le projectile cible un ennemi lorsqu'il est lancé et change de cible si sa cible actuelle meurt

Oui mais pas obligé du tout*. Il peut partir tout droit hors de l'écran.

Citation :

- le projectile change de cible s'il trouve un ennemi plus proche de lui que sa cible actuelle

Oui mais pas obligé du tout*. Il peut garder sa cible initiale.


*si ajouter ses options ne demande pas beaucoup de temps, ajoutes-les sinon laisse tomber.

Citation :

Sinon tu te rappelles ce que l'on avait décidé pour les projectiles traversant les ennemis ?

Pas exactement...
Mais en gros je pense que chaque projectiles peut avoir une case cochée true/false genre "traverse ennemi". Si c'est true le projectile ne disparait jamais au contact de l'ennemi, une fois qu'il a touche l'ennemi il continue sa route. Au même de la collision le dégât se fait, puis l'ennemi devient invulnérable à ce projectile pendant un faible instant (1, 2, 3 frames ou + ?).

J’essaierai de définir cela encore plus en détail si tu en a besoin. Aussi, si c'est complexe de sélectionner l'ennemi touché plutôt que le projectile qui touche pour l'invulnérabilité, tu peux rendre le projectile inefficace plutôt.