[CoRoLia] Programmation

Citation :

Lol powned par ta propre censure

Epic fail.

Citation :

En fait si je rajoute des frame de prise en compte de la touche saut, ça permettra de rendre le début du saut moins accéléré si c'est ce que tu veux surtout (si la partie après le pic du saut ne pose pas problème )

Oui, on peut essayer cela. C'est vrai que c'est cette acceleration qui m'ennuie. Le fait qu'un perso qui peut sauter haut ait du mal à faire un mini saut. L'idéal serait aussi que si on saute haut l’accélération soit moins intense dans sa vitesse (donc qu'on reste plus longtemps dans les airs, style on "plane" un peu).

En fait, je pourrai essayer de faire des animations pour illustrer mes idéaux.

Citation :

Oui, on peut essayer cela. C'est vrai que c'est cette acceleration qui m'ennuie. Le fait qu'un perso qui peut sauter haut ait du mal à faire un mini saut. L'idéal serait aussi que si on saute haut l’accélération soit moins intense dans sa vitesse (donc qu'on reste plus longtemps dans les airs, style on "plane" un peu).

Normalement ce que j'ai proposé aurait cet effet là, je vais faire une démo pour qu'on voit

Merci !

En fait, j'y pense, tu pourrais faire que la gravité commence plus tard ou va moins vite lors des sauts ?

Parce que je remarque que ce n'est pas tant que ça l'acceleration qui cause un problème pour faire un petit saut (ça reste possible même avec l'archer) mais ce qui gène est vraiment cette acceleration pour monter dans les airs, très visible sur l'archer (quand un perso saute plus haut que 4 cases).

En fait, si tu saute avec l'archer au maximum de sa hauteur pour le moment la durée du saut complet est d'environ 1 sec. Ce serait bien d'arriver à une durée de 2 secondes en gros donc que le personnage flotte un peu plus dans les airs => son accélération pour monter (et descendre) doit être moins rapide et arrivé à son point culminant il y reste un peu plus longtemps.

De même ça devrait influencer un peu le temps du saut, je peux aussi mettre une vitesse de chute limite plus basse pour le joueur, histoire qu'on ne puisse pas tomber trop vite

Je pense que ce serait bien, oui.
Mais tout se joue dans les détails, je pense. Ma première impression serait que la gravité fait tomber les choses un peu vite (héros, ennemis, ...) peut être que 25% moins vite serait déjà bien.

J'y repense, au cas où si ça t'aide...

en fait c'est possible mais très dur de faire un mini saut avec l'archer, le problème vient donc du fait que l'acceleration frame par frame est trop rapide. Soit tu ajoutes, comme tu le disais, des slots pour adoucir cette acceleration, soit tu fais que ce n'est plus 1 frame entre chaque slot mais 2 ou 3. Actuellement pour faire un petit saut avec l'archer il faut appuyer à peine et très vite sur la touche, je pense que c'est trop précis, pouvoir laisser le doigt 1 ou 2 frames de plus devrait avoir le même résultat.

Ca faisait un moment que je voulais en parler mais je pense que maintenant ça va devenir assez utile de se charger d'un petit problème.



Imagine ce niveau. Quand le joueur est en face d'un trou il faut que l'écran ne défile pas trop vers le bas, pour que ce soit clair que ce n'est pas un chemin. Et aussi parce que ce n'est pas très élégant. Dans la première partie tout marche facilement car les trous sont fait vers le bas de la map. La bordure rouge montre la limite visuelle et là où l'écran arrêtera de scroller.

Si le joueur monte en hauteur et se trouve de nouveau fasse à un trou, il ne faut pas qu'en tombant dedans l'écran se mette à défiler pour les raisons précédemment expliquées et parce que ça manque de logique d'un trou à l'autre.

Il faudrait que, là aussi, la bordure rouge soit la limite visuelle et que le scrolling arrête d'opérer. La zone hachurée ne devrait même pas être vue, comme si c'était en dehors de la map.

Il va falloir trouver un moyen, pour arriver à ce résultat. La plupart des jeux ont ce genre de système. Il faut savoir que ce système sera utiliser par moi et doit donc être changeable facilement suivant la topologie du terrain. Peut être des trigger (zone de déclenchement de script) qu'on croiserait après un changement de hauteur qui activerait un nouveau "bas de l'écran" ou dans chaque trou un trigger qui bloque la caméra de scroller vers le bas.
Au mieux tu arriveras à faire un système intelligent qui marche sans que j'ai à faire quoi que ce soit au cas par cas, mais là encore, vois ce qui coûte le moins cher : si mettre des events cas par cas n'est pas trop long pour moi et que c'est plus simple pour toi, allons-y avec ça !

EDIT : prends soin d'en parler avec moi avant pour être bien sur de ce que j'attends d'un système comme tel.

Hum, je pense pouvoir y arriver, ça serait surement des event qui bloquerait le scrolling vers le bas s'ils sont à l'écran et qui tueraient le joueur au contact

Ok, en fait, l'idéal serait que ça puisse marcher aussi vers le haut, genre des fois l'écran ne devrait plus monter. C'est moins important mais quand même... Genre si on fait un saut d'une plateforme haute vers une basse, il faut que notre perso soit non pas au milieu de l'écran mais en haut, quitte à sortir un peu de l'écran s'il saute (on évitera mais c'est pour illustrer) afin de voir la plateforme en bas même si elle est assez loin de celle du haut.

Dans le fond faudrait des event qui bloquent la cam, oui...

Je suis pas sur de comprendre l'exemple, actuellement le scrolling fait que le joueur n'est pas exactement au milieu de l'écran, mais sur une segment vertical centré, ça ne résout pas le problème que tu viens d'évoquer ?

Haut gauche : in editor

Haut droite : plan global, la zone rouge est là où je veux que la caméra soit bloquée (l'écran ne doit pas y scroller)

Bas gauche : ce qu'on voit en ce moment in game.

Bas droite : ce que j'aimerai qu'on ait comme résultat.



Ce genre de problème arrive si on a une map avec des niveaux de hauteur qui changent beaucoup, par exemple si tu regarde mon plan du premier niveau tu peux voir qu'on monte en altitude et donc que j'ai besoin d'avoir une map très haute.





Regarde comment sont faites les map des Megaman X :
- http://www.vgmaps.com/Atlas/PC/MegaManX-ChillPenguin.png
- http://www.vgmaps.com/Atlas/PC/MegaManX-StingChameleon.png

on voit bien que certains endroits sont vides, car le joueur ne peut pas les afficher (il est même possible que même avec un cheat en volant il n'y aurait rien d'affiché) pour éviter que l'on voit ça le jeu bloc le scrolling à certains endroits.
Tu devrais peut être jouer ou voir vite fait ça par toi même, comment le jeu réagi, pour mieux saisir...

Si tu veux je peux t'envoyer le niveau actuel pour que tu vois ce que ça donne, tu verras le problème arriver plusieurs fois, j'ai toujours essayé de minimiser mais c'est quand même visible. Je pense que ce point est crucial pour la démo, quand tu es sur de bien saisir le problème, et que tu vois des solutions, parles-en moi afin de voir si les moyens de corriger l'axe de l'écran sont humainement réalisable à grande échelle.

Oki je comprend le problème (je vois pas encore de façon simple de le résoudre, mais ça viendra ). Je veux bien le niveau actuel en effet.

Voilà : http://www.sendspace.com/file/mnyslq
Tu as le niveau, tileset et son background a ajouter dans les dossiers respectifs.



As-tu un controle sur la caméra, le défilement de l'écran ? Genre pour le bloquer horizontalement et verticalement ? C'est ça qu'il nous faut... après je peux pas trop t'aider pour la prog. ^^' Je peux juste te dire si la solution que tu trouve est acceptable à gerer niveau level design (car j'imagine qu'elle va être complexe donc à faire au cas par cas.)
L'idéal serait vraiment un type de tile qui délimiterait les frontières de la map, il me suffirait de peindre les endroits où je ne veux pas que l'écran puisse se rendre en faisant attention de laisser toujours assez de place pour qu'il puisse avancer (ce n'est qu'une idée... ^^)

Merci beaucoup !

Le défilement de l'écran, c'est deux variables modifiées lorsque le héros se déplace. J'ai peut-être une idée avec des tiles effectivement. J'attend de régler les bugs amenés par les nouvelles hitbox (des erreurs dans la conversation des anciennes vers les nouvelles ) et par la nouvelle gravité (le float de la valkyrie notamment ) et j’essaierai ça.

Je vais essayer de te faire une version avec la nouvelle gravité, le blocage du scrolling et l'agrandissement du niveaux dans toutes les directions dès que possible

Merci !

Pour le float de la Valkyrie, l'actuel avait un léger défaut, important toute fois, je devrais peut être te le dire de suite au cas où :

En gros, quand on appuie pour flotter, elle bat des ailes une frame ou un peu plus mais vraiment pas longtemps, ce qui fait que on sent qu'elle chute un peu entre chaque battement d'elle. C'est très subtile mais ça se ressent. Il faudrait faire que ce laps de temps soit plus long. Le seul moyen de tomber sans à-coup est d'appuyer sur la touche ultra rapidement. ^^'

Essaye Mario 3 avec la queue de raton laveur, au premier niveau, fais comme si c'était la Valkyrie, tu verras que si on appuie à vitesse rapide (pas ultra rapide) il tombe en douceur.

PS : il faudrait aussi désactiver l'impulsion du dash si on float avec la Valkyrie.

J'ai essayé de recréer le feeling de mario 3, tu me diras ce que tu en penses. Tu préfère une case spécifique du tileset, une nouvelle propriété de terrain ou un event (le moins pratique je pense ) pour les nouvelles limites du scrolling ?

Un tile c'est très bien, mais il doit se trouver sur un endroit précis du tileset ? Tu as trouvé comment faire ?


Merci pour la Valkyrie. ^^

Ca marche, il reste encore quelques trucs à ajuster pour pas que ça plante à la moindre situation étrange mais c'est plutôt pratique. Ca sera un le deuxième tile de la première ligne de chaque tileset :


Le résultat au début du niveau par exemple :

Oh génial !!!

Oui, je me doute que des erreurs peuvent arriver genre si l'écran n'a pas la place de passer entre deux lignes de ces tiles, par exemple. Ça va vraiment améliorer la présentation d'avoir cela en tout cas, merci.

J'ai ajouté la gestion des trous, même lorsque le scrolling est bloqué. Il faudra rajouter un tile spécial sous les tiles bloquant la caméra dans ce cas là, ça sera le deuxième tile de la première ligne de la première couche.

Exemple :

Super !
Et si un trou est tout en bas de la map on a pas besoin de ces tiles si je comprends bien ?

Si j'avais su j'aurai laissé plus de place dans les tiles pour ces choses là, en gros, sur les prochains tileset je le ferai mais pour les actuels la plupart du temps ce serait chiant de les changer car les tile sont déjà bien utilisés.




EDIT : lis ce sujet, c'est à propos de comment on pourrait s'organiser pour les tile de type gameplay comme la cam, et les trous.
=> https://e-magination.jeun.fr/t4074p125-projet-corolia-discussions#261968