27 juil. 2013

Premier prototype

Que faut-il tester en premier quand on crée un jeu vidéo ? C'est ce qu'on appelle les 3 "C" : camera, character, controls !

Camera : comment le jeu est-il vu ? Dans un jeu en 3D, voit-on le personnage à l'écran (3rd person) ou voit-on au travers des yeux du personnage (1st person) ? Dans notre jeu à nous, le jeu est-il vu de côté, de dessus ? A-t-on du scrolling quand on s'approche des bords de l'écran, ou tout l'espace de jeu est-il visible d'un seul coup ?


Character (personnage) : quelle est la taille du personnage ? A quelle vitesse se déplace-t-il ? Peut-il aller en diagonale, ou seulement haut-bas-gauche-droite ? Quelle taille font ses projectiles ? Comment les lance-t-il ?
Controls : comment dirige-t-on le personnage ? Est-ce tout à la souris, tout au clavier, un peu des deux ? Le tir est-il automatique ou manuel ? Tire-t-on droit devant soi, dans les quatre directions ou peut-on viser à la souris ?

Bien sûr, le Game Concept original et nos discussions ont déjà apporté bon nombre d'éléments de réponse : nous avons déjà une idée plutôt claire de ce qu'il faudrait faire. Mais le seul moyen de vérifier, c'est de tester !

Alors ouvrez grands vos yeux, car vous allez voir notre jeu se construire petit à petit !

Créer un personnage

Ça fait quelques mois que je n'ai pas touché à Flash... je me sens un peu rouillée !

Après quelques minutes pour paramétrer correctement mon logiciel et choisir la taille du jeu qui me convient, je rentre enfin mes premières lignes de code. Comme je connais bien Flash, j'anticipe la structure que devra avoir le jeu, ce qui va me ralentir au début mais me faire gagner beaucoup de temps vers la fin. Je crée donc un "niveau" vierge (que vous ne verrez pas), qui lui-même contient un petit personnage rectangulaire.

Tout d'abord, mon personnage ne semble pas apparaître à l'écran ! Logique, il s'est placé tout en haut à gauche de l'écran de jeu. Le temps de le positionner en plein milieu et hop... voilà mon jeu avec un personnage statique.



Temps total pour cette étape : 17 minutes.

Déplacement du personnage

Deuxième étape : faire bouger ce personnage !

On ne s'est pas encore vraiment fixés sur les contrôles du jeu, mais l'analyse de la concurrence a permis de repérer plusieurs possibilités :
  • tout à la souris : le personnage suit les déplacements de la souris et tire droit devant lui quand on clique - mais du coup, la visée n'est pas très précise ;
  • tout au clavier : le personnage est contrôlé par les flèches directionnelles et on tire avec la barre ESPACE par exemple - mais là encore la visée n'est pas très précise ;
  • souris + clavier : on déplace le personnage avec les flèches directionnelles et on vise et tire avec la souris - mais ça peut être difficile pour certains joueurs de désynchroniser leurs mouvements ;
  • ou enfin deux fois au clavier, avec ZQSD pour se déplacer et les touches directionnelles pour tirer, comme dans The Binding of Isaac - mais c'est vraiment difficile à manier !

Pour le moment, j'opterais pour le mix souris / clavier, qui me semble offrir un bon compromis entre maniabilité et facilité de prise en main.

Première chose à faire : détecter l'appui sur les touches. Je commence donc par coder un genre de système d'interrupteurs. Imaginez quatre petites diodes qui s'allument quand on appuie sur une touche, et qui s’éteignent quand on relâche. Et comme j'ai créé ces diodes en mode public, je peux les "voir" depuis n'importe où dans mon code.

Je reviens ensuite dans le code de mon personnage et je lui crée un nouveau comportement : le déplacement. Dès qu'il voit qu'une touche est enfoncée d'après les quatre "diodes" du programme principal, il se déplace à une vitesse fixe dans la direction correspondante.

Vous pouvez tester le résultat ci-dessous ! (Cliquez d'abord dans la fenêtre de jeu pour activer la détection des touches.)



Temps total pour cette étape : 10 minutes.

Collisions avec les bords de l'écran

Si on appuie indéfiniment sur une touche, le personnage finit par sortir de l'écran... Plutôt gênant ! Je dois donc rajouter une condition qui dit que, si le personnage s'apprête à se déplacer au-delà du bord de l'écran, il est bloqué.

Et comme je suis toujours en train de tester le déplacement, je me rends compte d'un autre problème : le personnage se déplace plus vite en diagonale que quand il va tout droit. Pourquoi ? Selon le code actuel, le personnage se déplace indépendamment de X pixels horizontalement et de X pixels verticalement. Ce qui signifie que, si je le déplace en diagonale, il combine ces deux vitesses et accélère.

Ça ne va pas du tout, il faut que la vitesse soit constante ! Je replonge donc péniblement dans mes souvenirs de maths de troisième et, grâce à ce bon vieux théorème de Pythagore, je calcule ce qu'il faut pour que la vitesse angulaire reste fixe.

S'il y en a parmi vous qui vont encore au collège ou au lycée, et qui pensent que tous ces exos de maths ne servent à rien, eh bien voilà : ça peut servir à faire des jeux vidéo !

Bref, j'applique le résultat de mes calculs dans mon code et bingo : le personnage se déplace maintenant à une vitesse constante quelle que soit la direction (horizontale, verticale ou diagonale).



Temps total pour cette étape : 20 minutes (mais les maths et Pythagores, c'est loin pour moi !).

Tir de projectiles

Bon, maintenant qu'on a un déplacement correct, voyons le tir. Je suis partie sur du tir à la souris parce que ça me paraît plutôt pratique pour viser !

Première chose : je programme le fait que, quand je clique n'importe où sur l'écran, ça génère un projectile à l'endroit où se trouve mon personnage. Facile.

Deuxième chose : je dois calculer son déplacement horizontal et vertical pour que le projectile se déplace en direction de l'endroit où j'ai cliqué à vitesse constante. Ça sent la trigonométrie à plein nez. Je DÉTESTE la trigonométrie : dans chaque jeu que je programme, il y a forcément un moment où il faut utiliser la trigonométrie et je me trompe tout le temps entre les sinus, les cosinus, les tangentes... et leurs inverses. Résultat, j'ai toujours un projectile qui se barre dans la direction inverse où j'ai cliqué.

Encore une fois, ça ne manque pas. Une demi-heure pour trouver le problème ! Pour ma défense, ce n'étaient pas des erreurs de calcul mais des erreurs liées à Flash, comme oublier de convertir les degrés en radians ou encore me tromper d'une lettre sur le nom d'une fonction. Enfin, à force de me pencher dessus, je finis toujours par y arriver. J'ai pas eu mon bac dans une pochette surprise :-)



Temps total pour cette étape : 30 minutes.

Tir continu et destruction des projectiles

Je ne sais pas si vous avez essayé de laisser la souris appuyée dans le précédent prototype mais, ça ne marche pas du tout. Le projectile ne part qu'au moment où on relâche le clic, ce qui implique que le joueur doit frénétiquement marteler sa souris pour produire une rafale de tirs. Si on ne change pas ça, on va avoir la mort de plusieurs souris sur la conscience !

Je vais donc coder le système nécessaire pour que les projectiles soient tirés à un intervalle minimal de X millisecondes. Si le joueur laisse sa souris appuyée, le tir se fait de façon continue. S'il martèle sa souris, il ne peut pas tirer plus vite que cette cadence.

Hé ! Augmenter cette cadence pourrait être l'un des pouvoirs bonus attribués par nos alliés lubiens dans le jeu ! (A se rappeler pour plus tard.)

Il y avait un autre problème dans la version précédente, mais vous ne vous en êtes sans doute pas rendu compte. Les projectiles partent... à l'infini. Même au-delà des limites de l'écran, ils continuent à avancer. Résultat, ça va finir par faire ramer l'ordinateur du joueur ! Il faut donc penser à supprimer les projectiles quand ils atteignent le bord de l'écran.

J'en ai profité pour accélérer un peu le personnage, que je trouvais un peu lent.



Temps total pour cette étape : 15 minutes.

Rebond et portée du tir

En codant la destruction des projectiles à l'étape précédente, je me suis dit un truc. Ce serait sans doute intéressant si, au lieu de s'éclater sur les murs, les projectiles pouvaient rebondir. De cette façon, on pourrait essayer de toucher ses adversaires par rebonds en restant planqué derrière les nombreux obstacles du décor, ce qui serait cohérent avec le fait qu'il faille placer astucieusement ses alliés et tirer profit de la topographie du terrain. Qu'en pensez-vous ?

Du coup, pour éviter qu'ils ne rebondissent indéfiniment dans l'arène, il faut qu'ils aient une portée limitée, c'est-à-dire qu'ils meurent tout seuls au bout d'un certain temps.



Temps total pour cette étape : 3 minutes (classe non ?).

Apparition des ennemis

D'ailleurs comme on parle d'ennemis, peut-être serait-il temps d'en créer quelques uns pour voir s'il est facile de leur tirer dessus.

On n'a pas encore vraiment décidé comment les ennemis apparaissaient (aléatoirement ? placés sur l'écran ou en-dehors ? par vagues ?) alors pour le moment, je vais juste faire apparaître cinq mecs un peu n'importe où. De même, on n'a pas encore réfléchi en profondeur à leur IA (Intelligence Artificielle) alors on va dire qu'ils se contentent de nous suivre un peu partout.

Et comme je dois mettre le prototype sur le blog de la Petite Fabrique, mais que vous aurez certainement mis un certain temps pour tout lire, il va falloir créer un écran d'accueil où il faut cliquer pour démarrer le jeu. Sinon, les ennemis vont se ruer sur le personnage pendant que vous lisez le reste de la page, et vous n'aurez pas vraiment le temps de tester.



Temps total pour cette étape : 15 minutes.

C'est tout pour le moment !

Alors, que pensez-vous de ce premier prototype ?

Êtes-vous convaincus par les contrôles ? Le personnage va-t-il assez vite ? Est-il trop facile de tuer les ennemis (enfin, de leur tirer dessus, puisque je n'ai pas encore programmé le fait qu'ils puissent mourir) ? Et surtout : vous êtes-vous amusés à y jouer ?

Je vous laisse cogiter tout ça, partager vos impressions dans les commentaires et proposer d'éventuelles améliorations. Car moi ce week-end je suis... en week-end ! Rendez-vous lundi pour démarrer les graphismes !

39 commentaires :

  1. C'est pas mal tout ça !

    mais ça parait super compliqué à faire rien que ce petit prototype

    RépondreSupprimer
  2. Ha! Très convaincu! C'est génial, ça avance vite! (enfin... de notre point de vue, haha)

    En parlant d'amélioration (qui sont plutôt des extensions que des améliorations...), on pourrait générer plusieurs types de projectiles? Je sais pas si tu vois de que je veux dire: projectiles plus gros, ou plus rapide, ou à forme différente, ou à trajet différent (curviligne, aléatoire, "tête chercheuse"), ou à proximité (sorte de mur de défense près du perso), etc...

    Enfin. Comme je l'ai dis, ce sont plus des extensions des bases déjà établies que des améliorations.

    Sinon, j'adore toujours autant tes articles!

    RépondreSupprimer
    Réponses
    1. Tout à fait d'accord sur tout ce que dit le monsieur! :3

      Supprimer
    2. Pour l'instant, concentrons-nous sur les bases !

      Supprimer
  3. Un petit problème, c'est que si les ennemis de base se contente de nous suivre, il faudrait faire en sorte qu'ils ne se chevauchent pas. Soit en leur mettant une hitboxe, soit en leurs donnant une vitesse différente.

    J'ai bien aimé la façon dont les balles se dirigent, elles vont sur la souris mais donne des effets intéressants quand on se déplace en même temps

    Après c'est exactement le type de jeu auquel je m'attendais :)

    Une question, sa sera un petit jeu flash comme on peut trouver sur navigateur ou un gros jeu Flash comme The binding of Isaac ?

    RépondreSupprimer
    Réponses
    1. Pour les ennemis qui se superposent, il faut se rappeler que c'est un prototype.

      Supprimer
    2. Prototype réalisé pour qu'on puisse signaler les problèmes il me semble.

      Supprimer
    3. Oui mais ce problème se serait tout de suite vu.

      Supprimer
    4. Pas forcément vu comme on ne sait pas comment ils vont apparaître.

      Je sais que c'est un prototype. Mais les personnages qui s’emboîtent fait partie des trucs a corriger, comme le personnage trop rapide ou le tir trop court.

      Mais bon après si on s'organise bien, ce n'est pas un grave problème que les ennemis s’emboîtent. Même dans Plants VS Zombis les ennemis s’emboîtent devant une wallnut (protection qui n'attaque pas mais très résistante)

      Supprimer
    5. ADJ a mis en plein dans le mille : la superposition des ennemis et leur pathfinding (recherche de chemin), c'est exactement le prochain point que j'aborderai en programmation !

      Supprimer
  4. j'allais dire la même chose que trystan, en fait il faudrait que chaque lubien ou type de lubien trouvable dans le jeu ait une résistance un mode de tir ou encore un mode de déplacement différents; mais, ça a déja été dit
    En tout cas pour l'instant ça donne carrément envie de voir la suite!

    RépondreSupprimer
  5. Ooooh il manque la partie présentation et lecture du code, c'est dommage, on ne pourra pas apprendre de cette partie du coup :(

    RépondreSupprimer
    Réponses
    1. Sinon je dirai qu'il faudrait peut-être revoir la taille du personnages / ennemis / tour ou de l'écran.

      Du 16*12 me parait un peu petit pour une "arène" sachant qu'il y aura le rajout des tour et d'obstacles qui diminueront le déplacement.

      Supprimer
    2. Assez d'accord avec ça.
      Néanmoins, on pourrait imaginer une évolution de la taille le l'arène au fur et à mesure du jeu. Le joueur commencerai dans une arène assez petite avec un débit d'ennemis peu élevé et peu d'obstacles.

      Supprimer
    3. @David : le but n'est pas de vous apprendre à programmer ^^ Je montrerai peut-être des extraits du code à l'occasion, mais pas dans son intégralité, sinon ça va ennuyer beaucoup de gens. Et si tu veux en savoir plus, je te conseille mon tutoriel pour apprendre à programmer.

      A propos de la taille de l'arène : vous soulevez un point intéressant. Je ne pense pas que la taille de l'arène doive varier : vu que la taille du jeu sera fixe, ce serait inélégant.
      En fait, je suis confrontée à un problème technique très embêtant : le blog fait 640 pixels de large donc, pour pouvoir intégrer le swf au blog, je suis limitée à 640 pixels de large. Peut-être que je devrais le mettre en plein écran ?

      Supprimer
    4. Un petit bouton plein écran en bas à droite du jeu...

      Supprimer
    5. J'aime la précision de "en bas à droite" XD

      Supprimer
    6. C'est pour ca que je demandais si c'était genre un petit jeu Flash du genre ce qu'on trouve sur jeu.fr ou carrément un jeu téléchargeable pour ne pas dépendre d'un navigateur.

      Supprimer
    7. Il n'y a aucune différence entre un jeu Flash sur navigateur et un jeu Flash hors navigateur, hormis la volonté des créateurs.

      Notre jeu existera en version boîte (pour les donateurs Ulule) mais aussi gratuitement sur Internet, et ce serait bien qu'on puisse le mettre sur des sites comme le Forum Dessiné... et peut-être Kongregate et Newgrounds pour qu'il soit jouable par le plus de monde possible. Dans ce cas, on a quand même une taille limite à respecter.

      Supprimer
    8. le but n'est pas de vous apprendre à programmer ^^
      C'est parce que c'est "La Petite Fabrique de Jeu Vidéo", je m'attendais donc à ce que toutes les étapes y passent plus ou moins en détails comme jusqu'à maintenant ! Autant les parties intéressantes que les ennuyeuses (parties totalement subjectives qui dépendent des personnes)

      Et comme beaucoup de Lubiens suivent tes traces, qui sait, en s'inspirant de cet exemple complet tu créerai peut-être quelques vocations en tant que nouveaux créateurs de jeu !

      Supprimer
    9. Faire varier la taille de l'arène me semblait une bonne idée ...Cela ajouterait une difficulté ! Mais ce que tu dis est peut être vrai, j'ai du mal à imaginé le jeu fini.
      Dans le cadre du blog , mettre le jeu en plein écran n'est les une mauvaise idée mais on peu s'en passer non ? Si j'ai bien compris le prototype ne sert qu'à vérifier que les mécanismes du jeu fonctionnent, les détails on les réglera plus tard :)

      Supprimer
    10. Je pensai qu'un jeu téléchargeable en Flash était beaucoup plus lourd et que c'était l’ordinateur qui gérait au lieu de la connexion sur navigateur.

      Supprimer
    11. @David : apprendre à programmer, c'est long et complexe, surtout pour un débutant niveau 0. Je parle donc de programmation, mais sans détailler chaque ligne de code, ce n'est pas le sujet ici... Par contre, tout est expliqué dans mon tutoriel programmation, donc ceux qui veulent "suivre mes traces" ont les moyens de le faire.

      @ADJ : le fichier Flash est le même, qu'il soit sur un navigateur ou qu'on le télécharge. Sauf que :
      - si on veut que le jeu soit jouable en ligne, on essaye de le rendre assez léger pour que le chargement ne soit pas trop long, tandis qu'on peut se permettre un jeu beaucoup plus lourd s'il est destiné au téléchargement ;
      - on peut sortir le jeu au format .exe s'il est en téléchargement, ce qui l'alourdit un peu mais garantit que tout le monde pourra le lire même s'il n'a pas le Flash Player installé.

      Supprimer
  6. Super intéréssant :D
    Bon week-end, repose-toi bien :)

    C'est sidérant la vitesse que tu mets pour faire ce prototype ^^
    C'est bien, ça va nous donner une base pour réfléchir au jeu...

    Les contrôles sont idéaux... Hormis le fait que je pense que ce serait bien de commencer le jeu juste en cliquant à chaque fois pour tirer un projectile... puis dans les améliorations, on pourrait intégrer le tir continu... Je trouve également que le perso va un peu trop vite... sa rapidité pourrait faire aussi partie des améliorations...

    RépondreSupprimer
    Réponses
    1. Je ne suis pas d'accord sur le tir continu. Le "mash de bouton" (appuyer très vite et de façon répétitive) est un truc qu'un joueur débutant a du mal à faire. Le tir continu est donc indispensable.

      Sur la vitesse du perso, vous êtes nombreux à la trouver trop élevée, je la diminuerai un peu... mais il est probable qu'il faille la rééquilibrer une fois les obstacles et les ennemis mis en place.

      Supprimer
  7. Prototype très convaincant.

    Comme cela a été dit plus haut, la taille des personnages est peut être un peu trop importante car cela risque d'être très vite chargé lorsqu'on aura des lubiens, des ennemies et le joueur à l'écran.

    Sinon je suis moyennement convaincu par le système de rebond à l'heure actuelle, je trouve que la portée des balles est trop faible et j'ai peur que la notion de rebond vienne complexifier la lecture à l'écran. Sinon pour la portée maximale des balles on pourrai la calculer après un premier rebond afin de permettre au joueur de garder une certaine distance avec les ennemies tout en ayant un effet de rebond vraisemblable.

    Enfin pour conclure, et même si c'est un peu anticipé, certain lubien pourrait avoir des effets de bonus ou de malus dans une zone autour d'eux, par exemple le joueur tire plus vite ou regagne de la vie alors qu'un ennemi peut être ralenti. Ainsi cela permettrai d'ajouter un aspect stratégique au placement des lubiens.

    RépondreSupprimer
    Réponses
    1. Assez d'accord sur les rebonds . Vu que les personages occupent une place importante dans l'écran -ce qui peut se comprendre, puisque les joueurs doivent s'y retrouver- , les projectiles qui rebondissent pourraient avoir tendance à aveugler le joueur .

      Les bonus et malus pourraient être en effet des caractériques liées à chaque lubien . Si possible, une différente pour chaque (même si ça risque d'être compliqué ).

      Enfin ,pour ce qui concerne la manière dont les ennemis peuvent apparaître, on pourrai reprendre le concept d'une arène romaine : une "grille"/entrée s'ouvre, et un certain nombres d'ennemis apparaissent, qui cocsitituent une première vague . On peut avoir différentes entrées qui ouvre sur différents types d'ennemis (une pour les "faibles", une pour les "forts", et une pour le boss). Il y pourrait y avoir différents rounds . Ou alors, chaque "arène", est juste un décor à thème où le joueur est confiné , et les ennemis arrivent par des portes .

      Supprimer
    2. Pour revenir sur la taille des persos, il pourrait être intéressant qu'elle soit justement variable en fonction du personnage, et cela impacterait ses qualités/défauts. Ex: Elo, que j'imagine assez petite (koala) serait par exemple plus rapide qu'Axel (dragon), beaucoup plus imposant.

      Très beau travail sinon! :D

      Supprimer
  8. un p'tit truc hs :
    est-ce qu'on pourrait faire en sorte qu'on peut modifier les touches ?

    RépondreSupprimer
    Réponses
    1. Ce genre de détails arrive tout à la fin de la production !

      Supprimer
  9. Cool ce premier petit proto. Mes petits retours =)
    - Je ne suis pas hyper convaincu par les contrôles : pas méga pratique les flèches + souris ( de mon point de vue je ne trouve pas la position très naturelle, zqsd + souris là c'est déja plus confortable !)
    - Je trouve l'idée du rebond interressante, ça reste a optimiser par contre :)
    - La taille de l'arène me semble aussi un peu petite, tu as choisis cette taille pour une raison particulière ? (un petit 1024*768 ne devrait pas être trop gourmand ? à voir selon le nombre d'ennemis et "objets qui seront sur la scène...)
    - Le déplacement du perso est un peu saccadé, tu sais déja comment tu vas le rendre un petit peu plus smooth ?

    Voila je réserve mes autres commentaires pour la suite ! hâte de voir ça :)

    RépondreSupprimer
    Réponses
    1. - oui, je devrais mapper tous les contrôles : ZQSD pour les joueurs qui ont un clavier azerty, WASD pour les joueurs qui ont un clavier qwerty et les touches fléchées pour ceux qui n'ont pas l'habitude d'utiliser les touches précédentes. Comme ces touches ne rentrent pas en conflit, on peut tout à fait toutes les mapper et laisser au joueur le choix des contrôles.

      - l'idée du rebond vous divise assez. A tester.

      - la taille de l'arène (voir plus haut) est essentiellement dûe au fait que le blog fait 640 pixels de large, mais ce n'est pas terrible pour jouer !

      - saccadé ? Mmmmh...

      Supprimer
    2. Tu est en combien de fps ? 24 ? Ca me donne une impression "un peu" saccadé mais c'est peut être car ton mouvement est "régulier" le déplacement est donc statitque, pas très fluide... En jouant sur les accélérations / décélération (ease out / ease in) tu devrais pouvoir rendre ça un petit peu plus naturel. Bon après c'est du détail, mais c'est toujours agréable à l'oeil :)

      Supprimer
    3. Je dois être en 24 fps (frames per second).

      Tel que c'est programmé actuellement, le mouvement est forcément linéaire puisque les vitesses horizontales et verticales sont fixes.

      Supprimer
  10. Tu peux peut-être proposer les prototypes en plus grand sur une page du Forum Dessiné comme tu l'avait fait pour les formulaires de Game Concept...

    Sinon petite question: est-ce que le personnage du jeu c'est un lubien? Ou un personnage tout à fait nouveau?

    RépondreSupprimer
    Réponses
    1. Tu peux peut-être proposer les prototypes en plus grand sur une page du Forum Dessiné comme tu l'avait fait pour les formulaires de Game Concept...
      Absolument : )

      est-ce que le personnage du jeu c'est un lubien? Ou un personnage tout à fait nouveau?
      On va le décider maintenant, via les Concept Arts et le scénario (qui devrait commencer mercredi).

      Supprimer
  11. camera check:perfect
    mouvement check:perfect
    taille perso check: perfect
    tir check: le rebond est une idée assez bonne, mais la porté est pour l'instant trop limité pour un jeu de tir
    il faudrait au moins que l'on puisse tirer de n'importe où et atteindre n'importe quel bord de l’écran

    tir + mouvement: la prise en main devrait se faire assez rapidement

    les ennemis qui se superposent au perso donnent un effet intéressant
    les ennemis qui se traversent, fusionnent ... oula idée pour plus tard

    là les ennemis et le perso sont symétrique, seront-ils asymétriques dans le jeu et devront-ils se tourner?

    RépondreSupprimer
    Réponses
    1. Les ennemis vont tuer le perso s'ils le touchent, donc ils ne pourront plus se superposer à lui à ce point.

      Dans le jeu final, les ennemis et le personnage auront sans doute des animations haut-bas-gauche-droite.

      Supprimer
  12. Pour déplacer le personnage à vitesse constante en diagonale, il suffit de multiplier la vitesse radiale par 0,707 :
    5 * 0.707 = 3.53

    C'est parce que :
    vitesse_x = vitesse_r * cos(45°);
    vitesse_y = vitesse_r * sin(45°);

    Or cos(45°) = sin(45°) = sqrt(2)/2 ~ 0.707

    C'est plus sympa que de déranger Pyth' et de résoudre une équation ! :D

    RépondreSupprimer

La participation à la Petite Fabrique de Jeu Vidéo est libre, gratuite et sans inscription. Elle ne vous donne droit à aucune contrepartie financière.

Remarque : Seul un membre de ce blog est autorisé à enregistrer un commentaire.