Juste une petite vidéo pour vous montrer ou nous en sommes avec les balles de fusils promises.

Me semble que le potentiel de jouabilité est déjà démultiplié!

Mathieu = content 🙂

 

 

Un petit vidéo pour montrer la balle trop grosse qui suit enfin une trajectoire qui a du sens!

La variable  »angle » de la balle ne sert plus à rien.

Il fallait plutôt normaliser le vecteur donné par la différence entre la position du joueur, et la position du méchant.  J’avais travaillé sur une approche du genre la semaine dernière, mais sans le bout  »normalisé ».  La balle partait de tous les côtés!

Merci à Google de m’avoir :

a) expliqué que ça existait  »normalisé » un vecteur (!)

b) expliqué comment le calculé 🙂

Ah, vive les maths…

 

Hé, vous avez même droit à un screenshot final d’un bout de code.

En passant, GeForce Experience, c’est totalement génial pour capturer du vidéo!  Merci pour le cue Guillaume.

Le projet  »projectiles objets » est bien entamé, mais j’ai dû ralentir le pas un peu la semaine dernière.  L’angle des mes *(big) bullets n’était n’est jamais bon.  Et là, je me gratte la tête, et me gratte la tête, pour finalement me dire que ça me fait chier de ne pas pouvoir suivre mes variables en temps réel.  Il me semble que ça m’aiderait à voir là ou ça cloche, non?  Et puis VisualStudio ne me permet pas de suivre des variables de cette façon.  Un breakpoint, ça n’aide pas dans un code de jeu vidéo…

Donc là, pas mal en retard vous me direz, je me suis dit que je n’avais qu’à m’en écrire un, debugeur!  Des fois j’oublie qu’un programmeur est supposé de programmer des trucs.

Voici donc le résultat, mais avec les *(big) bullets qui partent encore dans de drôles de sens.  Hey, je ne pouvais pas régler le problème, je créais des outils pour m’aider à potentiellement, un jour, régler le problème… ou non…

 

*Non, big bullets n’est pas une marque déposée.  Je voulais simplement spécifier que la balle du fusil ne sera pas grosse comme ça dans le produit fini.  Elle sera plutôt (normal) bullet 😉