projet de jeu de plateforme

Bonjour,

Je vais profiter de ce topic pour vous donner les dernières infos sur mon projet
plateforme qui est en fait devenu un vrai projet ^^. dont je vais
garder secret les graphismes en attendant une éventuelle présentation
dans les forum de making et peut-être celui là si je peux ^^.

J'ai amélioré les sauts, il ont vraiment une forme hyperbolique. Pour cela, j'ai mis des vitesses plus précises.

J'ai
modifier l'espace que prend le Game_Player. C'est un rectangle. La
collision avec les case non praticable est donc différentes de la
version précédente.

Voici un screen où je ne sais pas encore comment je vais dessiner certains infos de la fenêtre hud (argent et avatars libérés).




en (4) J'ai rajouter des cubes qui s'enclenche quand on donne un coup de tête en bas. Ici ça fait augmenter l'argent.


devient après utilisation :




Il y a des plateformes qui sont traversables que de bas en haut (3 et 5).

Des plateforme qui bougent verticalement (5).

J'ai
rajouter différentes armes comme le shuriken (2) (après c'est suivant
mon inspiration et mon imagination). Il sera possible d'attaquer dans
divers situation : baissé ou en cours de saut par exemple. Les armes
auront différents niveaux, par exemple pour le shuriken :
Shuriken nv1 : on lance une série de un maximum, direction horizontale
Shuriken nv 2 : on peut lancer 2 shurikens à la suite en directions horizontale ou diagonale.
Shuriken 3 : on peut lancer 3 shurikens à la suite en directions horizontale ou diagonale ou haut.
etc.

Des avatars à libérer. Vous vous demandez pourquoi, ben la réponse c'est dans le scénario ^^.

J'ai
décidé de faire la plupart des animations au maximum avec des charas
car quand je fait avec l'objet "animation" de sprite je ne sais pas
comment l'arrêter quand je fais pause en appuyant sur F5. Je garde
certaine animation comme le "damage" par exemple.

Différentes poses du GP :

baissé :


qui vole en appuyant sur L, la chute est ralentie :


décélération visibles :


Il y a aussi une accélération progressive qui permet de donner une masse au Game_Player.

voici le chara :


Il fait 12 frames. C'est vrai que c'est beaucoup mais vu que le Game_Player est très grand par rapport à ce que l'on peut voir dans les autres projets, les mouvements apparaissent moins fluides donc 4 frames ne suffisent pas. Le nombre de frames est variable suivant le Game_Character. Lorsque j'ai mis ces 12 frames le mouvement était fluide mais trop lent et le move_speed >= 6 n'a plus aucun effet sur l'animation du chara, du coup j'ai modifié une partie de l'update du Game_Character où nb_pattern est le nombres de frames :

Code:

    # valeur limite de l'anim_count pour @nb_pattern égale à :
    #  4 : @anime_count > 18 - @move_speed * 2
    #  8 : @anime_count > 17 - @move_speed * 2
    # 12 : @anime_count > 16 - @move_speed * 2
    # etc.
    a = @nb_pattern / 4

    if @anime_count > 18 + ( 1 - a) - @move_speed * 2
      # 停止時アニメが OFF かつ 停止中の場合
      if not @step_anime and @stop_count > 0   
        # パターンをオリジナルに戻す
        @pattern = @original_pattern
      # 停止時アニメが ON または 移動中の場合
      else

On passe d'une frame à la suivante que quand la valeur @anime_count dépasse une certaine valeur "18 + ( 1 - a) - @move_speed * 2". Normalement il n' y a que le @move_speed qui peut faire changer cette valeur mais je préfère ne pas trop y toucher car avoir un @move_speed constant permet de mieux gérer mes vitesses.
Ne me demandez pas comment j'ai trouvé cette formule, c'est en faisant plein de test j'ai vu que certaines valeurs permettaient d'avoir l'animation que je voulais et j'en ai déduit une formule générale qui n'a aucune logique mathématique.


J'ai aussi programmer les rebonds sur certains évènements (ennemis ou
ressort comme dans sonic) où après rebond la trajectoire dépend en
temps
réél de l'appuie du saut maintenu et des direction gauche droite. Donc
plus on maintient le bouton de saut, et plus on rebondis haut.



J'ai testé en mettant beaucoup d'évènement avec des IA que j'ai fait et
ça rame un peu le fps baisse très vite. J'ai donc décidé de désactiver
automatiquement tous les events qui se trouvent à une certaine distance
(environ un écran) du Game_Player.

J'ai surement oublié de dire des choses mais je rééditerais ^^".

Je
mettrai une démo après avoir finaliser quelques petits trucs graphiques
un peu long à faire et par la même occasion vous dévoilerai une partie
de mon premier chipset.

Après il y plein de choses que je ne sais pas comment je vais programmer :
par exemple :
->
Si on tue un ennemi, et que l'on séloigne de sa position de départ.
Quand on revient à cette position est-ce qu'il vaut moeux faire
réssuciter l'ennemi car un niveau se finit que quand on libère tous les
avatars. Donc si y a un avatars que l'on ne trouve pas et que l'on a
tué tous les ennemis ça peut devenir ennuyeux.
-> est-ce qu'il
faut limiter le nombre d'arme? Sachant que quand on a une arme c'est
comme un bouclier. Quand un ennemi nous touche et que l'on est armé, on
ne meurt pas tout de suite, on perd l'arme comme dans super mario avec
la fleur ou le champignon.
-> puis d'autres questions mais c'est un peu HS là, ^^" donc j'arrête.

Excellent début Dani
J en profite pour te donner un truc pour eviter le lag due a l IA.
La plupart du temps il n est pas necessaire de recalculer les IA a toutes les frames car le joueur, et le jeu, ne vont pas à cette vitesse
Donc l'idée est de calculer l'ia d'un pnj par frame, et ainsi de suite.
Meme si tu as 40 pnj, ce qui est pas mal, il faut 1seconde pour que leur IA soient recalculer pour tous, ce qui en temps de jeu ne se voit pas

merci pour cet astuce, c'est vrai que 40 frame par seconde c'est assez rapide. Je vais y penser quand je voudrais écononimisé du temps de calcul pour d'autres choses peut-être.

Je viens en fait de trouver pourquoi ça lagguait :
J'ai abusé de la boucle for sur les events de la map.

"for event in $game_map.events.values etc."
Chaque event à chaque frame lorsqu'ils n'étaient pas en mouvement faisait cet boucles (comme si c'était en processus parallèle), desfois plusieurs fois de suite pour un update et donc pour un frame. J'ai mis une cinquantaine d'events sur un écran et le fps = 3 ou 4 (pas plus haut lol).
J'ai donc résolu le problème en triant les events à chaque setup de map (donc ce tri ne se fera qu'une fois par map) et les ait répertorié dans différents tableaux suivant leur nature afin de faire des boucles plus efficaces et plus précises.
Et sur le test ci dessus ça tournait à 19, 20 en fps donc ouf ^^".
En passant j'ai quelques problème avec les plateforme qui bouge car je n'arrive pas à faire bouger en même temps le Game_Player et l'event plateforme "mouvante". Que ce soit l'event plateforme ou le Game_Player chaque update de déplacement ne se fait pas à tous les frame car il faut passer la condition :
"unless moving? or $game_system.map_interpreter.running?" etc.
Du coup le Game_player suit la plateforme mais pas en même temps, soit il est en retard, soit il est en avance. J'ai trouvé un autre manière de gérer ça mais ça fait pas logique : au lieu de faire un move du Game_Player je fait un moveto du coup il se trouvera exactement à l'endroit que je veux à ce moment là, c'est donc un "transfert" de quelques pixels à chaque fois mais on ne voit pas que c'est un transfert car c'est très rapide on voit juste qu'il fait qu'un mouvement continu. Bref, la plateforme qui bougent c'est pas de la tarte ^^!

Si personne ne comprend ce que je dis, sur les problème d'algo que j'ai sur le moment c'est pas grave, je voulais juste l'écrire, ça me fait du bien psychologiquement .

Tu viens de réduire mon boulot sur la plate-forme de KGC à néant ! XD
Je proposerai ma dernière version et je te laisserai désormais le soin de gèrer la plate-forme rmxp pour la communauté.

Tu as déjà 3 fois plus de choses que ce que j'ai réussi à faire, sans compter que tes sauts sont de meilleure qualité.

Enfin bref : bonne chance, ce n'est pas le plus facile mais j'ai adoré bosser ce truc. ^^
Je passe désormais le relais.
( Je retourne à ma 3d ).

Vas-tu gèrer des coupsn comme megaman, castlevania, etc... ?
En gros mettre aussi un moteur A-RPG.

merci siegfried !

En fait les sauts de la dernière démo ne sont plus d'actualité, celles d'aujourd'hui sont bien meilleures d'ailleurs quand je m'autoteste je perds beaucoup de temps car je m'amuse et je fais des sauts de partout et j'oublie que je suis en train de tester le jeu. Les sauts et déplacements sont quasiment comme dans "mario" excepté :
-> graphiquement, il me manque le chara pour montrer les dérapages, le chara pour montrer quand il nage dans l'eau, le chara quand il glisse beaucoup (réglage accélération et décélaration très lente) quand il se retrouve sur la neige par exemple.
-> gestion des sols : les plateformes mouvantes ne sont pas encore vraiment bien programmé, et les sols penchés ou courbes ne seront peut-être pas programmables (enfin pour l'instant je n'ai pas réussi à trouvé d'algorithme efficace). j'ai essayé de faire ça de manière mathématique (représentation des sols courbes ou penché par des fonctions mathématiques) mais pas réussi ^^. Je vais peut-être pas en faire pour le moment.
-> IA des events sont assez simple pour l'instant : juste des déplacements et saut. Comportement de type "patrouilleur" (fait des aller-retour de nb pas) et de type "patrouilleur sauteur" (pareil que patrouilleur mais en sautant. Par contre ces events n'occupe pas un rectangle car faire des tests de passibilité des 4 coins du rectangle (puis d'autres points si la largeur et la hauteur dépassent une certaine valeur "32 pixels") pour chaque events à chaque update move ça fait lagguer à un certains moments. Leur déplacement est donc que du pix par pix simplifié par rapport à celui du Game_Player.

Il y a aussi d'autres choses qui ne sont pas programmés au jour où je tape ce message mais qui sont déjà programmables avec la version actuelle du projet :
tous les armes pour un système A-RPG sont quasiment tous programmable. Il me manque que la partie graphique. d'ailleurs dans la démo précédente j'avais déjà mis un boomerang, le seul défaut c'était la collision entre boomerang et ennemis qui ne prenait pas en compte le gabarit 2D de l'ennemi. La gestion d'une attaque qui se charge comme dans megaman est prévu, elle repose sur le même principe que l'accélération qui repose que sur la durée d'appuie d'un bouton qui fait augmenter une variable qu'il ne manque plus qu'à définir.
Ce qu'il manque : une IA de events qui attaquent. C'est en projet : ce seront des sortes de doubles events sur l'éditeur de map : un event principale + son arme (ou ses armes).

Voilà, j'ai profité de ce messages pour présiser mes objectifs de recherche et dire les différentes limites et possibilités qu'il y a actuellement sur le système actuelle (j'ai surement oublié des choses sur les limites ^^")

edit après relecture : actuellement sur le système actuelle

Je suis content aujourd'hui je viens de trouver la principal cause qui entraine le lag. Voici l'explication,
Je me demandais pourquoi à chaque fois que chaque Game_Event faisait des test de distance avec le Game_Player en processus parallèle, le pc ramait quand on multipliait ces events. En fait à chaque fois qu'il faisait des tests de distance, ils faisaient en même temps des calculs inutiles, ils calculent l'angle entre eux et le Game_Player. En effet j'ai définition une méthode qui fait les deux calculs à chaque fois pour mon projet a-rpg.

Code:

  #--------------------------------------------------------------------------
  # ● Game_Character / dist_angle
  #--------------------------------------------------------------------------
  #--------------------------------------------------------------------------
  # * def dist_angle(x1,y1,x2,y2) : retourne un tableau à trois dimensions
  #                    -> d12 : distance entre les points 1 et 2
  #                    -> rad : angle en radian entre les points 1 et 2
  #                    -> deg : angle en degré entre les points 1 et 2
  #--------------------------------------------------------------------------
  def dist_angle(x1,y1,x2,y2)
    # d12 : distance entre les points M1 et M2
    d12 = Math.sqrt(((x1-x2)*(x1-x2))+((y1-y2)*(y1-y2)))
    r = 9999
    rad = (Math::PI)/2
    if x2 != x1
      r = (y2-y1+0.0)/(x2-x1)
      rad = Math.atan(r)
      deg = rad * 180/(Math::PI)
    end
    if x2 != x1
      a = ( x2 <  x1 )
      b = ( x2 == x1 )
      c = ( x2 >  x1 )
      d = ( y2 <  y1 )
      e = ( y2 == y1 )
      f = ( y2 >  y1 )
     
      if a and d
        rad = rad + (Math::PI)
      end
      if a and e
        rad = (Math::PI)
      end
      if a and f
        rad = rad + (Math::PI)
      end
      if b and d
        rad = (3/2) * (Math::PI)
      end
      if b and e
        r = 0
        rad = nil
      end
      if b and f
        rad = (1/2) * (Math::PI)
      end
      if c and d
        rad = rad + (2 * (Math::PI))
      end
      if c and e
        rad = 0
      end
      if c and f
        rad = rad
      end
      deg = rad * 180/(Math::PI)
    end
    return[d12,rad,deg,r]
  end #fin dist_angle

Connaître l'angle me permettait juste de définir plus facilement des méthodes comme "bouger_vers_g_character" plus facilement comme le pathfinding je crois qu'on appelle. Donc je vais définir deux méthodes séparément pour calculer la distance et calculer l'angle. Car là le pc calculait des tangentes pour rien. Pour mon a-rpg ça m'a juste servit pour programmer le mouvement en chenille de pnj. Mais là pour l'instant je ne l'ai pas encore utiliser mais je compte l'utiliser dans ce projet plateforme donc je le garde.

Je mettrai très prochainement une présentation du projet dans la rubrique des projets.

PS : ah si j'ai déjà utilisé les calculs d'angle dans la démo qui se trouve dans un des posts précédent pour l'ia du boomerang quand il revient vers le héros.

Boulala il y a 2 moyens d'optimiser ta methode

1. Précalculer les tangentes en fonctions de la précision dont tu as besoin. En effet sur un ecran la précision du calcul de tangente (ou n'importe quelle fonction trigo) n'est pas utile.
En général on peut se permettre de précalculé les fonctions trigos et les stocker dans un tableau de 360 ou 180 valeur selon la précision a 1 ou 2 degré.
ce qui veut dire qu'il faut que tu précalcules les valeurs de ton r pour trouver ta tangente inverse

2. Il est fort probable qu'il y a des redondances de calcul, peut etre pas ici, mais souvent on utilise ce genre de fonction avec la passabilité ce qui peut etre gourmand. En effet, on risque de tester tout les events pour quelques events qui se déplace.
Hors en théorie, un seul passage de test doit suffire. Dans ce cas on effectue le test sur tous les events une seul fois et on stocke le résultat dans un tableau[event1,event2,resultat]
Ce qui permet un test rapide pour un event n afin d avoir le resultat voulu.

Bon expliqué comme ca c'est peut etre un peu chaud, mais si tu crois que l'idée peut etre utile, on peut en discuter un peu plus