LGdir: Orientation, Vecteurs, Déplacements
Vous êtes Mapmaker et vous désirez faire des jeux implémentant une mécanique de tirs ? Voici un système bien pratique qui va vous permettre non seulement de tirer, mais aussi de contrôler la trajectoire d’un projectile !
Une gestion complète des projectiles
Le LGdir, abréviation de « LeiRoF & GamerGuppy direction », en référence au CPdirection (« Crushed Pixel direction ») est un système permettant aux joueurs (ou à n’importe quelle entité !) de lancer des projectiles à la manière d’une boule de neige. L’avantage est que vous pourrez gérer:
- La trajectoire: celle ci vous permet de modifier l’endroit vers lequel se dirige le projectile. Vous pouvez alors définir une trajectoire « droite » ou bien créer des trajectoires obliques. Vous pourrez ainsi simuler la gravité, le vent etc., la seule limite est celle de votre imagination !
- Les collisions: le projectile sera apte à traverser toutes les surfaces ou bien rebondir/se coller/glisser sur certaines d’entre elles !
- La vitesse: augmentez, diminuez ou même stoppez la vitesse d’un projectile pendant sa course ! Vous pourrez même la faire repartir dans le sens inverse à tout moment !
- Les identités/propriétés: il vous sera facilement possible de distinguer tous les projectiles ainsi que les personne les ayant lancés. Ainsi, vous pourrez savoir qui à marqué le but en ayant lancé la balle ou bien savoir qui à tiré sur qui etc.
Modulable et ajustable
Le LGdir saura s’adapter à chacune de vos map, du fait de ses objectifs de scoreboard commençant par « Dir », évitant tout problème de compatibilité.
De plus, il s’avère être extrêmement modulable du à sa conception « ouverte » et organisée. Vous pourrez ainsi créer vos projectiles personnalisés (en mettant un mouton comme projectile, la réalisation d’une map comme SheepWars sera alors un jeu d’enfant) et modifier le comportement de chacun indépendamment des autres.
Ce système à été initialement pensé pour une map des plus complexes et à donc implémenté la possibilité de gérer un nombre de projectiles illimités au même moment et par autant de joueurs que désiré !
La map initiale (connu sous le nom de Hierarchy) lui a aussi imposé une contrainte d’optimisation à laquelle il a su répondre. Ainsi, les parties du systèmes sont indépendantes et ne s’activeront qu’au besoin grâce à l’implémentation d’un système d’activation intelligente. La partie calcul de trajectoire ne s’allumera alors que durant 0.05 seconde au moment ou un joueur tir !
Enfin et pour couronner le tout, le LGdir à reçu des améliorations le rendant ultra réactif. Les tirs seront alors quasiment instantané ainsi que les changements de directions !
Comment ça fonctionne ?
Pour comprendre ce système, nous allons faire de la rétro-ingénierie (commencer par constater le résultat et décomposer petit à petit le système en partant de la fin pour en arriver à son fondement). Pour ceux qui sont assez courageux, j’ai mis à disposition des explications très détaillées dans les spoilers. Ce système n’aura alors plus aucun secret pour vous ????
Ah ! Là, on rentre dans le cœur du sujet ! Pour rappel, afin de faire un système de projectile, le CPdirection reposait sur les tags « Motion » définis selon l’orientation du joueur en testant chaque possibilité. 360 degrés horizontal multiplié par 180 degrés vertical, ça fait beaucoup de possibilité (64 800 pour être exact) et autant de blocs de commande activés en boucle (surtout quand on devait mettre plusieurs exemplaires du système pour disposer de plusieurs vitesses) !
Ici, il n’est plus question de motions car ceux-ci posaient trop de problèmes. Ce système là utilise les téléportations comme moyen de déplacement.
Mais alors, les projectiles ne bougent pas de façon fluide et linéaire mais sont téléportés de façon saccadés ?
En théorie oui, en pratique, c’est plus compliqué que ça car il s’agit d’une combinaisons de micro-téléportations, cumulé à l’animation de téléportation des entités de Minecraft. Bref, rassurez vous, les mouvements sont parfaitement fluides !
Ces téléportations sont faites à partir de 3 vecteurs (en X, Y et Z), permettant de savoir à quelle vitesse le projectile se déplace sur chacun des axes. Ainsi, la somme des 3 vecteurs formera le vecteur (la direction, le sens et l’intensité) du projectile. La mise en mouvement du projectile est alors optimisé par un procédé mathématique afin que sa trajectoire soit la plus précise possible sans pour autant avoir autant de blocs de commandes que de possibilités.
Les 3 vecteurs sont quant à eux directement calculés grâce à l’orientation du joueur (elles même déduites via un procédé mathématiques d’optimisation) grâce à des formules trigonométriques ramenées à des opérations simples (addition, soustraction, division et multiplication. Encore et toujours des maths !)
Principe de la dichotomie
Le projectile ne peut excéder une vitesse de 4 blocs par tick sur chacun des axes (1 tick Minecraft = 0,05 seconde, cela correspond à l’intervalle entre 2 actualisations du jeu) pour des raisons techniques (les collisions, dont nous allons parler plus tard, sont l’une des raisons majeures de cette limitation). Ces 4 blocs sont décomposés en une série dichotomique de téléportation.
Pour expliquer simplement, prenons l’exemple du jeu « Juste Prix » dans lequel l’objectif est de trouver une valeurs entre 0 et 1000 et à chaque coup, il est renseigné si la valeur cherché est supérieure ou inférieure à la valeur choisie. Chacun ira de sa stratégie mais une seule parait être la plus efficace: celle de la dichotomie. Cette pratique consiste à prendre l’élément « milieu » (appelé élément médian) de l’intervalle dans lequel se trouve le nombre que l’on cherche. Pour le Juste Prix, vous allez alors choisir 500. Si le nombre se trouve au dessus, vous prendrez alors 750 (valeur médiane pour l’intervalle 500 à 1000). Sinon, vous choisirez 250 (valeur médiane pour l’intervalle 0 à 500) et ainsi de suite. Ainsi, au premier coup, votre chance de tomber sur le bon nombre est de 1/1000. Au deuxième coup, elle chute à 1/500, puis 1/250, puis 1/125 etc … Vous avez alors trouvé une valeur secrète comprise entre 0 et 1000 en un maximum de 10 coups !
Sur ce système, c’est exactement la même chose. La vitesse est décomposé sur 3 scores représentant l’intensité des 3 vecteurs primordiaux (X, Y et Z). Ces scores sont variables entre -1000 et 1000 (la partie négative signifie que le projectile ira dans le sens opposé à celui de l’axe). Vous commencez donc à voir le rapport avec le Juste Prix.
Premièrement, on regarde si le projectile « avance » ou bien « recule » (je met ces deux termes entre guillemet car ils dépendent d’un repère en l’occurrence, celui des axes donnés par Minecraft. Sans repère, il est impossible de dire ci le projectile avance ou recule). Pour cela, on regarde si son score sur l’axe qu’on étudie est supérieur ou inférieur à 0 (si il est égal à 0, le projectile n’a alors aucun déplacement sur cet axe, il n’est pas nécessaire de faire quoi que ce soit). Considérons que le score est positif, il faut alors chercher une valeur entre 1 et 1000 (1000 représente la vitesse maximum soit 4 blocs par tick) puis téléporter le projectile. On va alors tester s’il est supérieur ou inférieur à 500. Si il est supérieur, il faut téléporter le projectile de 2 blocs (moitié de la vitesse maximum). S’il est inférieure, on ne fait rien. On retire alors 500 à son score (vu que nous modifions le score, il faut donc avoir fait au préalable une copie de ce score afin de le rétablir avant le prochain tick pour que le projectile continue de se déplacer) Ensuite, on fait de même avec 250 (cette fois-ci, le /tp sera de 1 bloc), puis avec 125 (avec un tp de 0,5 bloc) et ainsi de suite. Au final, le projectile ce sera alors déplacé exactement à la vitesse voulue, sans que nous ayons eu réellement connaissance de cette vitesse.
Approximation de Bhaskara
Pour obtenir l’intensité des 3 vecteurs, on dispose de formules trigonométriques permettant de les calculer à partir de 3 valeurs: r, phi et theta. Ces trois valeurs correspondent respectivement à la vitesse finale du projectile et à la direction du regard du joueur sur le plan horizontal et vertical (plus de détails dans le spoiler « Orientation »). Ces formules sont les suivantes:
x = r * sin(theta) * cos(phi)
y = r * cos(theta)
z = r * sin(theta) * sin(phi)
x, y et z représentent la vitesse du projectile sur chacun des axes. Ici, on n’utilise pas la valeur r (ce qui revient à la laisser à 1). La vitesse finale sera modifiée plus tard en multipliant ou divisant les 3 vecteurs par un même coefficient (diviser tous les vecteurs par 2 revient à diviser la vitesse totale du projectile par 2 sans modifier sa trajectoire).
Mais, ça demande de faire appel à des sinus et cosinus, choses que nous ne pouvons pas faire dans Minecraft !!!
Ces formules font appel en effet à des sinus et cosinus, et il nous est en effet impossible d’utiliser ces fonctions dans Minecraft. Cependant, il y a une subtilité: les fonctions sinus et cosinus sont connus ! Et depuis le temps qu’on les connait, on a pu développer des fonctions « simples » qui donnent un résultat similaire. Ces fonctions « simples » son appelées les Approximation de Bhaskara que voici:
sin(p) ~= (4 * p * (180 – p)) / (40500 – p * (180 – p))
cos(p) ~= (32400 – 4 * p^2) / (32400 + p^2)
Ça à l’air compliqué tout ça, je ne vois pas comment intégrer de tels fonctions à un système Minecraft. Surtout que les p^2 c’est toujours pas possible à faire
Une solution toute simple: respecter les règles de priorité de calcul ! Vous pouvez stocker des résultats d’opérations simples dans des scores, il ne vous reste qu’a faire des bons calculs dans le bon sens pour faire ce genre d’opérations. Ca va prendre autant de commandes blocs que ce qu’il y a d’opérateurs (+, -, *, /, ^) mais vous y arriverez. Quant au p^2, cela revient à faire p * p ????
Orientation du joueur
On a vu dans le spoiler précédent que pour calculer l’intensité des 3 vecteurs primordiaux, il nous fallait les valeurs r, phi et theta. La valeur r représente le « module ». Celui ci correspond à la vitesse finale du projectile. La valeur Phi représente la valeur (en degrés) de l’angle du regard du joueur sur la plan horizontal (comprise entre 0 et 360). Theta correspond quant à lui à la valeur de l’angle sur le plan vertical (comprise entre 0 et 180 car il n’est pas possible de lever ou baisser la tête du joueur plus haut que le ciel ou plus bas que la terre). Ces deux dernière valeurs sont données par le jeu dans le menu f3.
Il suffit alors de les récupérer et les sauvegarder dans des scores. Pour cela, pas question de tester toutes les possibilités, on va appliquer le même principe que pour le déplacement du projectile à savoir: la dichotomie. Pour le déplacement de l’entité, on avait un score qu’on transformait en position (la nouvelle position de l’entité après son déplacement). Maintenant, c’est l’inverse, nous avons une position (ou plutôt, une orientation) et nous cherchons à l’enregistrer sur une score.
Reprenez donc la méthode de dichotomie précédente et remplacez les TP par des ajout de score (au lieu de téléporter l’entité de 2 blocs, vous lui ajoutez 500 à son score) et remplacez des anciennes modifications de scores par des tp relatifs modifiant l’orientation du joueur (en divisant celle-ci par 2 en permanence). Vous aurez alors votre orientation stocké dans 2 scores distincts (je vous en dit pas plus là dessus, à vous de faire fonctionner votre matière grise :p)
Vous aurez compris que vu que nous modifions l’orientation de l’entité, cette entité ne peut pas être celle qui tire (autrement, le tireur verra son orientation partir en cacahuète à chaque tire, chose pas très agréable …). Ces modifications devront alors être faites sur le projectile lui même. Il faut donc avant de faire cela, téléporter le projectile sur le tireur afin que le projectile prenne l’orientation du tireur. A la fin du calcul, il faut ensuite téléporter à nouveau le projectile sur le tireur afin qu’il regarde dans le bon sens (si le projectile est une flèche, il faudrait que sa tête point là où la flèche se dirige)
Comment l’utiliser ?
Ce système à été maintes fois modifié afin de le rendre le plus simple possible d’utilisation. Voici la liste des éléments utiles à connaitre afin de maîtriser complètement le système !
- (tag) DirShoot: permet de faire tirer un projectile à l’entité possédant le tag. Ce tag se supprime automatiquement dès que l’entité à tiré
- (tag) DirHaveShoot: ce tag permet de savoir quand l’entité vient de tirer (utile pour modifier le projectile en fonction du tireur sans modifier le LGdir). Ce tag se place et se supprime automatiquement
- (tag) DirMoving: permet de savoir quand un projectile est en mouvement. Retirer ce tag aura pour effet de stopper net le projectile. Pour lui faire reprendre sa course, il suffit de lui remettre ce tag.
- (score) DirCollision: permet de gérer les collisions du projectile. Chaque score correspond à un comportement (le projectile rebondira partout quand il aura le score 1 par exemple). Il est possible de créer son propre comportement.
- (scores) DirX, Dir Y et DirZ: permet de gérer la vitesse sur l’axe X, Y et/ou Z. Modifier sa valeur aura pour effet de modifier la trajectoire du projectile. Incrémenter en boucle cette valeur aura pour effet de donner une trajectoire oblique au projectile.
- (score) DirSpeed: permet de gérer la vitesse globale du projectile. Modifier sa valeur à 200 aura pour effet de multiplier sa vitesse par 2, 300 pour multiplier par 3 et ainsi de suite. Cette valeur ne doit pas être inférieur à 0 ni supérieur à 400 sinon quoi, le projectile prendra une trajectoire imprécise (par défaut le projectile aura un DirSpeed à 200 correspondant à une vitesse de 2 blocs par tick)
C’est tout ! Vous savez désormais tout ce qu’il y a à savoir à propos de ce système !
Crédits
- LeiRoF: Concept & développement
- GamerGuppy: Aide Développement
La création du LGdir à été grandement facilité grâce à GamerGuppy, ayant réalisé un système se rapprochant du LGdir (qui a d’ailleurs servit de base de travail).
Téléchargement
Si vous utilisez ce système dans une création publique, merci de renseigner LeiRoF dans les crédits de cette dernière. Ce système étant gratuit, c’est un moindre remerciement ????
Le LGdir est un système en commande-bloc qui à donné naissance à la Gunivers-Lib, proposant plus d’outils de mapmaking. Il n’y a donc aucune version plus récente de ce système car il a été incorporé au sein de la Gunivers-Lib.
Comment l’installer ?
Pour installer ce système, vous pouvez:
- Importer la schematic via le logiciel MCedit
- Installer World Edit (plugin sous CraftBukkit ou Spigot pour les serveurs, mod « SinglePlayerCommands » pour les clients) et accéder au répertoire « schematics » présent dans le dossier du mod/plugin. Faites y glisser le fichier puis allez sur votre Minecraft et entrez les commandes « //schem load LGdirByLeiRoF » puis « //paste » à l’endroit où vous souhaitez l’installer.
Une fois installé, vous devrez appuyer sur les boutons présents en bas des systèmes nommés « Constant » et « Objectives ». Par précaution, cassez et reposez les blocs de redstone afin d’actualiser les blocs adjacents.
Comments (1)
Leave a Comment
Vous devez vous connecter pour publier un commentaire.
Pingback: Glibs | Gunivers