Être humble
Lors du dernier devblog, j’ai pu évoquer mon envie de développer un jeu et mes débuts balbutiants dans cet exercice. Lesdits débuts oscillaient entre le choix du moteur de jeu, celui du style de jeu en lui-même ainsi que mes premiers pas pour créer un personnage qui donnerait un peu le La en ce qui concerne l’allure générale du jeu (un sujet que j’aborderai très probablement dans un troisième devblog… Oui, ça tease comme un sagouin !)
Aujourd’hui, le jeu a relativement peu, mais - malgré tout - bien avancé. C’est-à-dire que les principaux systèmes de jeux sont en place. Dans l’absolu, j’ai un jeu fonctionnel, si vous préférez.
Par contre, je n’ai pas encore de niveaux dans lesquels s’amuser avec les systèmes de jeu en question.
C’est ballot, vous me direz, et vous n’aurez pas tort, mais il était important d’avoir un gameplay relativement fonctionnel avant d’essayer de mettre en place le reste.
Dans ce genre d’entreprise, surtout lorsqu’on débute, il est important de prendre son temps afin de ne pas griller les étapes. Chaque chose en son temps : tel pourrait être mon crédo.
Celles et ceux qui ont répondu « c’est Pumbaa le vieux crado ! » gagnent 1 point Disney.
Just Push Play
La première chose à mettre en place était le système de déplacement de mon personnage. Eh oui, avant de courir, il faut savoir marcher !
Le gros avantage de GDevelop, c’est sa simplicité : ici, il vous suffit de dire que le petit sprite que vous venez de créer est un personnage de jeu de plateforme et… Voilà ! Automatiquement, le programme vous permet de contrôler votre création avec les flèches de direction et même de sauter grâce à la barre d’espace. C’est simple, facile et, il faut bien le dire, immédiatement satisfaisant (même si, pour le moment, votre personnage ne possède aucune animation pour ces actions).
Bien évidemment, vous pouvez programmer tout ça vous-même, je dirai même qu’il est conseillé de le faire (pour certaines raisons que j’évoquerai un peu plus loin), mais, pour le moment, c’est très bien comme ça et ça permet de démarrer concrètement.
D’un point de vue plus technique, voilà comment GDevelop présente sa programmation : c’est un peu la même méthode que pour du code, mais avec des phrases simples à base de « Si…, Alors... ».
Par exemple :
Non, je ne vais pas vous montrer tout mon code, bande de curieux !
À gauche, on entre deux actions :
- Si l’objet appelé « Archer » ne bouge pas (le symbole avec les flèches qui ressemble à la carte Inversion du Uno signifie que c’est l’inverse de l’action décrite qui est prise en compte).
et
- Si l’objet appelé « Archer » ne saute pas.
Alors, la conséquence à droite est la suivante :
- L’animation de « Archer » est « Idle » (c’est vous qui nommez vos animations comme vous le désirez. Ici, je l’ai nommée « Idle » simplement parce que l’anglais est plus utilisé dans la programmation, mais vous pouvez très bien écrire en français. Notez également que GDevelop est traduit à 98 % en français)
Ndr : une idle animation est l’animation de votre personnage lorsque vous restez sur place, sans bouger. Certaines idle animations sont devenues iconiques comme celle de Sonic, par exemple.
Avec un langage simple et intuitif comme celui-ci, on est évidemment tenté d’expérimenter. Très tenté.
Non mais je ne vais pas le faire…
À cause des portes...
*bruit de grincement sinistre*
Behind Closed Doors
Sur son site, Liz England a publié en 2014 un post très intéressant intitulé The Door Problem. Ce post est fait pour éclairer les néophytes sur ce qu’est le travail de game designer. Et pour l’expliquer simplement, Liz prend l’exemple totalement trivial des portes dans les jeux vidéo.
Je ne vais pas paraphraser, je vous invite tout simplement à aller lire son texte, mais, pour résumer, derrière chaque mécanique de jeu, même celles qui semblent les plus basiques (comme… une porte ! Bravo, vous suivez !) se cache en fait une quantité de facteurs à prendre en compte.
Et ça, moi-même, à mon petit niveau, j’ai pu m’en rendre compte très rapidement, ne serait-ce que pour les déplacements de notre personnage.
Par exemple, si j’appuie sur la flèche gauche, mon personnage va vers la gauche. Eh ben super ! Oui, d’accord, mais si je vais vers la gauche et que j’appuie sur le bouton de saut ? Il saute ! Certes, mais est-ce que son saut est contrôlable par le joueur ou la joueuse, ou bien est-il prédéfini ? Et si mon personnage est déjà en train de sauter et que j’appuie à nouveau sur la flèche gauche ? Et si, au lieu de sauter, je suis en train de tomber (ce n’est pas la même chose), qu’est-ce qu’il se passe avec cette flèche gauche ? Et, imaginons que j’ai appuyé sur le bouton d’attaque et que j’appuie sur la flèche gauche juste après ? Et si je veux naviguer entre mes différents items avec la flèche gauche, je fais comment ? Est-ce que je veux vraiment aller vers la gauche en appuyant sur la flèche gauche ?
Alors, effectivement, certaines de ces questions semblent assez futiles et d’autres amènent des réponses qui nous semblent évidentes. Oui, mais n’oubliez pas que le logiciel avec lequel vous développez votre jeu est dépourvu de logique. Il ne va pas prendre d’initiative, il ne va pas se dire « ah, bah du coup il faut que je fasse comme ça ! », et, surtout, il ne va pas se poser ni vous poser de question. Il exécute. Vous devez donc répondre à toutes ces questions (ou, en tout cas, le plus possible).
Je ne sais pas ce qu’il en est pour les personnes très expérimentées mais, en tant que débutant, on n’imagine pas du tout à quel point la moindre feature vient bouleverser l’équilibre déjà précaire de ce qu’on essaie de construire.
Représentation artistique
Et, s’il est déjà compliqué de mettre en place de simples mouvements pour son personnage, imaginez ce qu’il faut faire lorsqu’on essaie de faire réfléchir tout ce petit monde.
Check My Brain
S’il y a bien un terme que je trouve particulièrement bien choisi lorsqu’on parle de la conception d’un jeu, c’est celui-ci : intelligence artificielle. Parce que, qu’on se le dise, c’est littéralement de ça dont il s’agit. Vous allez devoir créer de toute pièce un être (virtuel) pensant.
Au-delà de l’aspect résolument très intéressant de l’exercice (en tout cas, en ce qui me concerne), la chose qu’il faut absolument prendre en compte dès le début, c’est… euh, bah… comment qu’on fait et par où je commence, en fait ?
Comme le dit l’adage, c’est en forgeant qu’on devient forgeron et c’est bel et bien en mettant le nez dans la conception d’un jeu vidéo qu’on comprend mieux pourquoi certains (beaucoup) de jeux sont comme ils sont, avec leurs qualités et leurs défauts. L’intelligence artificielle est souvent pointée du doigt, mais il faut bien se rendre compte que tout part de rien.
Il faut donc tout créer, tout prévoir, il faut que ça fonctionne techniquement (tout bêtement), bref, c’est un travail colossal qui explique pourquoi, bien souvent, les IA sont relativement « simples ».
En ce qui me concerne, j’ai décidé de faire très simple mais je souhaitais malgré tout aller un peu plus loin que simplement « l’adversaire fonce sur le personnage et tape ».
Ce qui m’intéressait, c’était d’avoir des ennemis qui réagissent lorsqu’ils voient mon personnage, qu’ils aient un comportement à distance puis, à mesure qu’on s’approche, qu’ils changent ce comportement. Un truc assez simple, en somme : je te vois, j’agis / tu t’approches, j’agis autrement / je ne te vois plus, je m’arrête.
Rassurez-vous, je ne vais pas m’étendre dans des explications techniques, d’une part parce que je ne suis pas assez calé sur ce point (il est évident que mon code est bourré d’erreurs) et, d’autre part, parce que ce n’est pas le sujet ici (les rageux disent que c’est parce que ce serait trop chiant). Malgré tout, je vais quand même expliquer un peu ce que j’ai dû faire pour plus ou moins réussir mon coup. En gros, j’ai utilisé des sprites rectangulaires afin de déterminer la vision des ennemis, mais aussi les zones qui leur permettent de détecter le personnage (par exemple, si je me faufile derrière eux), j’ai essayé de rendre leur comportement à peu près fluide et, après pas mal de réglages approximatifs, ça ressemble à ça :
Alors, oui, on peut se faufiler et tuer discrètement un ennemi et, oui, on peut parer les ennemis et leur asséner une attaque fatale, je vous remercie de l’avoir remarqué.
Vu comme ça, ça semble bien fonctionner mais, en réalité, il y a plein de petites choses qui ne vont pas, des petits bugs, des anicroches.
Et, pour tout dire, je ne suis pas certain de savoir comment régler tous ces problèmes.
Nothing Else Matters
Je pense que c’est la première leçon à retenir lorsqu’on développe un jeu : savoir reconnaître ses limites.
Il est extrêmement tentant, surtout lorsqu’on voit tout ce qui se fait autour, de vouloir inclure telle ou telle mécanique de gameplay. Il est très facile de se dire « et si je mettais ça ? ». Et je pense qu’il est important de savoir se réfréner, de dire parfois non.
Dans mon cas, il y a plusieurs mécaniques que je souhaitais vraiment essayer (dont un grappin… oui, c’est so 2015, mais, que voulez-vous, je suis un boomer). J’ai passé un petit bout de temps à réfléchir à comment les inclure, à faire des essais pas du tout peu concluants et, après avoir tourné autour du pot assez longtemps, j’ai dû me rendre à l’évidence : ces mécaniques n’avaient pas leur place ici.
Pourtant, il y en a certaines, dont une en particulier, que j’aimais vraiment, que je trouvais plutôt originale et qui aurait pu amener une bonne dynamique entre risque et récompense… mais pas pour ce jeu (je la garde pour plus tard, du coup).
Pour faire un parallèle avec mon métier (je travaille dans la post-production audiovisuelle), j’ai souvent été confronté à ce genre de situation, que ce soit sur de la fiction, du documentaire, du clip ou autre : il est très courant de vouloir inclure toutes les scènes tournées lors du montage, de mettre tel ou tel plan parce qu’il est très beau ou parce qu’il était compliqué à tourner et qu’il a demandé beaucoup de temps et d’efforts, ou d’utiliser cette prise, mais aussi celle-ci, etc.
La réalité est qu’il ne faut pas, en tout cas pas toujours. Parfois, ça ne marche pas. Parfois, c’est hors de propos. Parfois, ça n’apporte rien. Le plus difficile est de le reconnaître.
Toutes les idées, aussi bonnes soient-elles, ne correspondent pas forcément à votre projet et vous ne pouvez pas les inclure de force dans votre jeu.
Il est également important de connaître ses propres limites.
Même si on apprend à chaque erreur, même si on progresse, on se retrouve parfois face à une impasse. Parce que notre outil est limité, parce qu’on est parti dans une mauvaise direction, parce que, tout simplement, on n’a pas le courage de tout refaire pour parfaitement arranger les choses.
Alors on bricole, on fait au mieux, on s’arrange pour que les défauts soient le moins gênants possible.
Chaque personne ayant travaillé sur ce type de projet (que ce soit un jeu, un film, ou autre) a parfaitement conscience des problèmes qui le peuplent. Ce sont les premières personnes au courant, à dire vrai. Et si elles pouvaient arranger les choses, elles le feraient.
Mais parfois, ce n’est pas possible. Parce qu’on n’a pas le temps, on n’a pas les compétences (ce qui n’est pas grave, on apprend tous les jours), on n’a pas l’outil pour… ou parce qu’on a fait de mauvais choix dès le départ et qu’on ne peut plus revenir en arrière.
Il faut apprendre à vivre avec et à se dire qu’on fera mieux la prochaine fois.
Après tout, cet état d’esprit peut être un puissant moteur d’inspiration.
Non mais… voilà qu’il philosophe !
In The Future When All’s Well
Et pour la suite ?
Eh bien, je ne vais pas m’arrêter en si bon chemin ! Maintenant que le jeu fonctionne à peu près mécaniquement, je vais pouvoir commencer à habiller tout ça, à créer des décors, des niveaux… tout un monde qui devra être suffisamment intéressant pour qu’on ait envie de s’y plonger, ne serait-ce que pour une paire d’heures.
Évidemment, s’il est aussi passionnant que ma prose, on n’est pas sorti des ronces...
