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 !