Aucun commentaire nécessaire…

 

Oh yeah!
Encore une fois, rien de visuellement spectaculaire, mais on touche à quelque chose là!

 

 

Bon, ce n’est peut-être pas très clair, mais quand le héros devient rouge, c’est parce qu’il vient de se faire descendre.
Et non, je ne triche pas. L’algorithme n’est pas  »if(méchant tire) {héros devient rouge;} 

Croyez-moi, il ne voulait pas devenir rouge au début 😉

J’utilise une technique qui se nomme  »hitscan » et qui est surtout utiliser dans les shooters 3D.  L’idée est de tracer une ligne partant de la mire du tireur et de considérer ce qu’elle rencontre comme cible atteinte.  Et évidement, dans mon cas présent, la ligne ne vérifie pas tout ce qu’elle croise. Elle ne vérifie qu’une chose : si elle croise un cercle de détection entourant le héros, une  »Bounding Sphere ». Comme le calcul à faire est très léger, il n’y a pas de hiérarchie de spères de détection ici. Si un jour je veux savoir si la balle atteind la tête du héros, ou son  »bas du corps » comme dirait les gars de hockey, j’aurai besoin de différentes sphères de différentes tailles, mais bon.

Pourquoi, me direz-vous, ne pas plutôt projeter une balle virtuelle du fusil et vérifier si elle entre en collision avec sa cible?

Parce que:

• Faire des calculs de ballistique sur un objet supplémentaire (multiplié par les dizaines de projectiles que la mitraillette projète) dans le monde du jeu, c’est compliqué.  Le vent? Le spin du projectile? Sa vitesse? La gravité? Est-ce qu’il disparait une fois au sol? Le CPU moderne sont capables d’en prendre, mais pourquoi les taxer inutilement. Et je ne parle pas de la quantité de code nécessaire pour accomplir cette tâche.

• Tout ces paramètres réalistes font que ce n’est pas du tout cool de jouer au jeu!  Le niveau de difficulté vient de quadruplé lorsque vient le temps d’abattre un ennemi. S’il faut calculer la vitesse de déplacement de l’ennemi en fonction de sa distance en plus du taux d’humidité relatif pour faire un  »kill », le fun factor tombe à une vitesse folle. Et oui, on se trouve pas mal bon à Call of Duty et Left For Dead parce que la physique des projectiles est complètement fausse!   Oh, et les chars dans la réalité ne se comportent pas comme dans Need For Speed sur la route non plus 😉

•  À cause du tunneling (j’en reparlerai une autre fois si ça vous tente).

Bon, mon problème du moment est d’ajuster mon méchant pour qu’il ne soit pas trop bon, et ce n’est pas si facile.  Dans cette première itération, si le bouclier du héros n’est pas en fonction, il fait mouche à tous coups.  L’autre point est que, comme l’utilisation du bouclier sera un point important du gameplay, il faut que le joueur recoive un indice du moment à lequel l’ennemi va tirer. Il va donc falloir un truc visuel ou sonore pour avertir le joueur – mais il ne faut pas que ce soit trop évident non plus!
Avec l’engin qui commence à prendre forme, le gamedesign va prendre de plus en plus de place.

Bon, maintenant que le code fonctionne, je n’ai plus le choix.
À mes pinceaux!
La prochaine vidéo devrait montrer les mêmes trucs, mais visuellement intéressant.
Ça devrait…

 

Pour ceux d’entre vous qui sont familiers avec les Design Patterns en science informatique, le concept de  »State Machine » vous sonne probablement un son de cloche.

Il s’agit probablement de la façon la plus basique de générer de l’intelligence artificielle dans un jeu vidéo, mais généralement efficace dans le contexte d’un Hack ‘n Slash en 2D.

L’idée est de donner à un NPC (à mon ennemi / boche dans ce contexte) un arbre d’états possibles et de gérer ces états en fonction des événements se déroulant dans le monde du jeu.  Le terme  »finite » dans Finite State Machine signifie que le nombre d’états de l’intelligence est fini, et qu’il ne pourra y avoir qu’un état présenté à la fois.

Mon ennemi peut donc avoir faim, ou avoir soif, mais pas les deux en même temps 🙂

Dans l’exemple suivant, qui est mon premier prototype qui aura à être peaufiné (mais l’idée est pas mal là), le méchant présente différents états :

il peut patrouiller, pourchasser le héros, s’en éloigner pour avoir un bon angle de tir sans recevoir un coup de tomahawk sur la gueule, il peut aussi tirer et, comme il n’a que quatre balles dans son magasin, il doit aussi recharger parfois.

Oh, et je disais plus haut que l’algorithme ne permettait qu’un seul état à la fois, et bien j’ai un peu menti.  Ici, mon boche utilise deux arbres d’états superposés pour gérer son niveau de conscience du danger.  Pour le moment, il peut savoir que le joueur approche, ou non.  Plus tard, d’autres niveaux de conscience viendront d’ajouter.

Et comme j’ai judicieusement décidé de faire mes tests de code d’abord et de dessiner lorsque le tout serait concluant, il va falloir se servir de son imagination pour aujourd’hui 🙂

Couleur normal = non-conscient de la présence du héros

Bleu = conscient et pourchasse le héros

Vert = tente de garder une distance de tir raisonnable

rouge = prêt à tirer

clignote = il tir!

mauve = recharge après avoir écoulé ses quatre balles

 

Le tout aura à être ajusté bien sûr (vitesse variable, pause à certain moment, donner une impression d’un méchant un peu plus vivant), mais le résultat final sera assis sur cet arbre d’états.

Et comme il se fait tard, je vous raconterai une prochaine fois de quelle façon je m’y prends pour modifier l’état du bonhomme!

 

Le vrai travail commence maintenant.

Il faut convaincre ce gars-là de tirer sur notre héros…

Souhaitez-moi bonne chance!