Note: je parle de Blender Game Tools, c’est devenu un addon AssetGen, il s’agit d’un outil permettant de générer un modèle de jeu vidéo en un seul clic à partir d’un high poly. Plus d’informations ici: https://3dworkshop.org/2017/08/04/decouverte-de-laddon-blender-game-asset-generator-wip/

The Last Symbol

  • Global Game Jam 2016
  • Thème: Ritual
  • Localisation: Paris, école Ican
  • Plateforme(s): Windows uniquement
  • Jouabilité: une manette obligatoire
  • Diversifier(s): Gandhi’s Game: This game must have zero violence in its game play. Conflicts must have resolutions based on logic.
Logo

Page officielle: http://globalgamejam.org/2016/games/last-symbol

Vidéo de gameplay: https://youtu.be/SXz65PYebZQ

Composition de l’équipe

  • Moge Ludovic – Game Designer / Level Designer
  • Bekhoucha Danyl (Linko) – 3D Artist
  • Tubiana Hugo – Sound Design / 2D Artist
  • Bouquin Bastien – Programmer
  • Mock Virginie – Programmer

Logiciels utilisés

  • Moteur de jeu: Unity
  • Assets 3D: Blender
  • Musique: FL Studio

Pourquoi avoir rejoint cette équipe ?

Le côté Portal Like avec des pièces fermées remplies d’énigmes m’a beaucoup attiré, j’ai toujours voulu faire un jeu de ce type, j’ai donc tout de suite après les speeches interpelé le Game Designer avant qu’un autre artiste ne prenne la place. :)

Lore

Scénario imaginée par le Game Designer Moge Ludovic.

Dans ce jeu on incarne Achôris, un jeune prêtre égyptien. Son royaume est rongé par la famine, à cause de la sécheresse il n’est plus possible de cultiver la terre. Pour le sauver, il doit récupérer le « Dernier Symbole » situé dans les profondeurs de la pyramide de Deptahânkh, un ancien Pharaon connu pour sa maitrise d’anciens rituels mystiques. Mais la pyramide est remplie de pièges afin de garder les secrets quelle contient. Archôris ne commence pas son périple les mains vides, les prêtres lui ont confié le Symbole d’Isis lui permettant d’achever le rituel de la Fertilité. Durant sa quête dans les profondeurs, il devra réunir le Symbole de Râ et d’Anubis, qui lui permettront d’atteindre la dernière pièce où le « Dernier Symbole » y est caché.

Captures d’écran

Assets 3D réalisées par Bekhoucha Danyl, Level Design par Moge Ludovic et Bouquin Bastien.

Tous les assets ont été sculptés sur Blender, puis le Blender Game Tools a permis de générer les low poly et toutes leurs textures. Pour les symboles et le HUD ils ont été réalisés par l’artiste 2D (qui était aussi le sound designer), j’ai récupéré ses dessins et ai utilisé le Displacement Modifier de Blender pour les convertir en modèles 3D puis les ai corrigé en les sculptant.

Image utilisateur
Image utilisateur
Image utilisateur
Image utilisateur
Image utilisateur

Musique(s) et bruitages

La musique a été réalisée par Tubiana Hugo, je lui ai suggéré de s’inspirer de « Jak 2 – Mountain Temple » pour ses notes calmes et intrigantes.

Écouter la musique: https://soundcloud.com/hugo-tubiana/symbol-quest-hugo-tubiana

Difficultés rencontrées

En ce qui concerne la modélisation des assets je n’ai pas eu de difficulté particulière, les éléments graphiques étant plutôt simple (des blocs de sable) et les vases réalisés à partir d’image de têtes de dieux égyptiens. Par contre dès le départ j’avais fait une grosse erreur sur le polycount, les blocs du jeu sont composés de beaucoup trop de faces alors qu’ils sont dupliqués des centaines de fois, une erreur bête qui nous a pénalisés puisque le jeu en démonstration ne pouvait tourner que sur un seul PC portable de gamer surtout après avoir activé les ombres et les effets de particules pour le feu (du Unity Package) pour faire les démonstrations, nous avions eu peur pour le framerate nous voulions absolument les effets d’éclairage. Je me suis focalisé sur les éléments importants: blocs, sol, téléporteur et pièges. Pour les pièges j’ai réalisé en priorités le piège du premier niveau afn de pouvoir tester la jouabilité et difficulté et modélisé la lampe torche pour gérer l’éclairage en même temps et avoir un meilleur aperçu du rendu final. Puis j’ai réalisé la boule mobile de piques pour le dernier niveau. J’avais ensuite réalisé des piques aux plafonds et serpents cracheurs de flèches, mais les programmeurs n’ont pas eu le temps de les faire interagir, car nous n’avions qu’un seul programmeur la nuit l’autre rentrait. Les level designers ont donc placé les pièges qui ne fonctionnaient pas pour l’habillage, j’ai modélisé d’autres éléments tels que des vases et des crânes pour habiller un peu plus la scène et ajouter de la diversité ainsi que des escaliers qui descendent en fin de niveau.

La difficulté c’est plutôt posé du côté des programmeurs pour la génération d’un bloc à partir d’un autre avec le sort de Fertilité. Il était possible de viser un edge (arrête) et ainsi de générer deux blocs en même temps, voir de viser un vertex (sommet) et d’en générer trois et c’était courant avec la zone de collision du sort. Cela à poser un gros problème sur la jouabilité, il nous fallait absolument résoudre ce problème, car on pouvait parfois ce retrouver coincé, il a fallu beaucoup de temps pour le résoudre qui aurait pu être consacré à la programmation des autres pièges.

Le sound designer avait passé beaucoup de temps à réaliser la musique, le dernier jour, à quelques heures de la fin, il a souhaité l’encoder en qualité maximale, il ne savait pas que le jeu devait être terminé avant 15h. La musique était trop longue à encoder, nous avions vu que cela dépasser la deadline, nous lui avons demandé de réduire la durée de la musique et de compresser la musique. À partir de samedi soir, le programmeur s’est mis à aider le game designer (aussi level designer) qui bloquait pour la réalisation des niveaux et plusieurs avaient été abandonnés et ne sont plus dans la version finale (mais sont nous les avons inclus dans les sources). On avait des problèmes pour créer des prefabs, on voulait créer différents groupes de blocs que l’on nommait 6×2, 2×2, etc. Nous avions vu aussi que certains blocs n’avait pas de collision il a fallu vérifier tous les blocs. Ensuite je leur ai modélisé un sol, nous avions dû remplacer les blocs au sol par le nouveau sol.

Au moment du rush final 2-3 heures avant de rendre le jeu j’ai aidé les level designers à habiller la scène 3D, il n’était plus question de créer de nouveau niveau ni même de toucher au code. Je voulais ajouter un easter egg « The Cake is a Lie » pour notre inspiration à Portal mais nous n’avions pas eu le temps, la finalisation des niveaux était prioritaire.

Ce que la Game Jam m’a apporté

J’étais dans une très bonne équipe compétente, je ne pensais pas pouvoir atteindre ce niveau de graphisme et gameplay en si peu de temps, surtout que nous étions l’une des seules équipes avec un seul graphiste (moi). Ça m’a permis de m’autoévaluer, de voir et d’entendre les réactions des joueurs, voir si beaucoup s’arrêtaient pour jouer (ce fut le cas), s’il y avait des spectateurs. Et c’était le cas, nous avions réalisé l’un des jeux qui attiraient le plus de monde. C’était un plaisir aussi de voir les enfants faire la queue pour jouer, et apprécier notre travail, les voir essayer de résoudre nos énigmes et parfois découvrir des petits bugs que nous avions manqués. Répondre aux enfants comme aux autres jammers sur des aspects techniques du jeu. Dommage que j’étais trop fatigué et suis rentré pendant que d’autres continuaient à jouer.

J’ai évidemment obtenu de nouveaux contacts et eu le plaisir de travailler avec d’autres passionnés. J’ai pû aussi suivre d’autres créations et vue des idées très intéressantes et plusieurs technologies employées comme le jeu en voxel, des jeux avec des textures toutes peintes à la main et même un jeu avec un effet dessin au crayon à papier. Certains jeux n’étaient pas terminés, nous avons réussi à le finir, j’étais donc plutôt satisfait pour une première Game Jam de réussir à faire tout ce que nous avions voulu ou presque, car il manquait quelques pièges, mais nous avions un point de départ et une arrivée et suffisamment de challenges. J’aurai peut-être aimé un niveau en plus, notre jeu en contient 4.

Je participerais à l’édition 2017 sans hésiter, je regrette de ne pas avoir participé plus tôt.

Until Wave

  • Global Game Jam 2017
  • Thème: Waves
  • Emplacement: Paris, école Isart Digital
  • Plateforme(s): Windows uniquement
  • Jouabilité: deux manettes obligatoires
Logo

Page officielle: globalgamejam.org/2017/games/until-wave

Vidéo de gameplay: https://youtu.be/4sGhNlXqFN8

Composition de l’équipe

  • Alexandre Bovorasmy – 2D Graphist
  • Danyl Bekhoucha – 3D Graphist
  • Umi Guillou – 2D/3D Graphist
  • Julien Geiger – Lead developer
  • Benjamin Ramaugé – Game Designer
  • Fabrizio Santoro – Developper
  • Aloïs Durupt – Sound Designer / Music
  • Yann Roirand – Game Designer
  • Thomas Bailly-Salins – Game Designer / Developer

Remerciements spéciaux:

  • Clara Legentil
  • Quentin Malapel
  • Brian Ravaux
  • Thomas Klein
  • Yohan Donse
  • Marion Chabrol-Supt

Logiciels utilisés

  • Moteur de jeu: Unity
  • Assets 3D: Blender, Maya
  • Sprites: Photshop, Animate, Illustrator
  • Musique: Ableton Live, Reaper, Audacity, Soundly

Pourquoi avoir rejoint cette équipe ?

L’ambiance un peu à la Fat Princess avec un gameplay qui peut se rapprocher d’un mod « Nexus War » avec le placement d’unités sur des lanes (couloirs), la collecte de ressources et les ultimates.

Lore

Concept imaginée par Aloïs Durupt.

Until Wave est un jeu en 1vs1, dans lequel on incarne un des enfants qui s’engage dans une terrible guerre de château de sable. Votre objectif est de détruire le château adverse, pour ce faire vous devez créer des guerriers qui vous coûteront des ressources. Vous pouvez en gagner au fil du temps et en collectant les coquillages en envoyant un guerrier marcher dessus. Attention, des plus grosses vagues endommageront vos châteaux, vous devrez aussi dépenser des ressources pour construire des barricades et vous protéger de la mer. Les grosses vagues remplissent également une fosse, une fois votre barre de furie au maximum qui se rempli en attaquant les unités ou châteaux ennemis vous pourrez utiliser votre abilité ultime. Cette abilité vous permet de nettoyer la moitié droite ou la moitié gauche du terrain en fonction de la concentration d’ennemies et de la gâchette pressée. Votre château est petit à petit endommagé si des unités ennemies s’arrêtent devant, il vous faudra défendre les couloirs en créant des unités ou réparer le château.

Captures d’écran

Assets 3D réalisé par Bekhoucha Danyl, sprites par Umi Guillou et Alexandre Bovorasmy. Animation 3D et logo par Umi Guillou. Slides du tutoriel par Alexandre Bovorasmy.

Les assets ont été réalisés avec le Blender Game Tools.

Image utilisateur
Image utilisateur
Image utilisateur
Image utilisateur

Musique(s) et bruitages

La musique et bruitage ont été réalisé par Aloïs Durupt.

Difficultés rencontrées

Nous étions nombreux, trop nombreux, 9 au total dont 6 en production (3 artistes (moi pour la 3D et deux pour la 2D), 2 programmeurs et 1 sound designer) et 3 game designers. Il y avait pas mal de confusion même pendant le développement sur le gameplay du jeu, sur le système des ressources, les unités des joueurs s’il en fallait plusieurs, mais aussi sur les graphismes. A la base le jeu devait être fait en 2D, puis j’ai dit que j’étais un artiste 3D, mais comme les deux autres artistes était partie pour faire de la 2D, nous ne savions pas comment combiner la 3D à la 2D. Nous avions ensuite décidé de faire les environnements en 3D et les unités en 2D. Nous n’étions pas sûr pour les deux enfants qui s’affrontent.

Il y avait peut-être un peu trop de game designers pour réfléchir au gameplay et avoir trois personnes qui ne produisent pas autour de soi et qui donnent des ordres c’est énervant surtout en étant le seul artiste 3D sur un jeu majoritairement 3D. J’ai géré tout les aspects 3D, non seulement les assets, mais aussi l’éclairage, le shading et une partie du level design. Une jam fatiguante pour moi qui m’a empêché d’être productif le dernier jour.

Nous étions sûrs pour l’environnement et la disposition des assets donc j’ai réalisé le « blockout » (une maquette, une ébauche 3D) du château et lanes (couloirs). Cela nous a permis de voir notre idée de gameplay à l’action en faisant apparaitre des cubes sur les lanes représentant les unités marchant vers le château ennemi, de définir aussi le rythme du jeu. A la base les unités 2D devaient être animés, pour éviter d’avoir à le faire nous les avions réalisées en carton tenu par des tiges, finalement cela a donné un style au jeu.

Pour réaliser la vague, je ne savais pas comment m’y prendre en 3D et exporter une animation, j’avais pensé faire un fluid simulation puis un baking. J’avais tous les assets 3D à réaliser, je n’avais pas le temps pour apprendre. Le petit garçon et la petite fille qu’on a finalement décidé de faire en 3D ont dû me prendre 2h 30 chacun, ça a occupé une grande partie de mon samedi.

Pour les vagues nous nous étions dit, comme nos guerriers étaient en 2D, peut-être que pour conserver ce style nous pourrions les faire en 2D aussi. Un graphiste 2D a donc pris un screenshot du jeu et peint les vagues qui contournent la fosse et château et passent au milieu du terrain.

Cela posait deux problèmes:

  • Avec un modèle 3D animé de l’eau nous aurions eu le même pour le premier, c’est que la scène doit être validé, il ne fallait plus modifier les détails du sable, la largeur de la fosse, le rapprochement des châteaux, car l’eau entre en collision avec.
  • Le problème en plus avec la 2D c’est qu’il ajouter le dessin en tant que texture sur un plan puis l’orienter à plat et utiliser la perspective pour l’aligner avec les assets 3D depuis la vue caméra.

Pour les châteaux je les ai sculptés en trois états, le château intact, endommagé et sur le point de s’effondrer. Il m’a fallu dupliquer le château et utiliser la scrap brush de Blender en Dyntopo pour détruire le modèle, puis dupliquer le château endommagé pour le détruire davantage. Je ne pouvais ensuite plus faire de modifications sur le château, les château endommagé ne devaient pas avoir des détails supplémentaires.

Les programmeurs ont parfois eu des problèmes d’input avec les manettes, la détection des manettes en joueur 1 et 2 était un peu aléatoire au final beaucoup de mécaniques dont certaines importantes n’ont pas pu être intégré comme la réparation et l’amélioration du château, les vagues qui l’endommagent et les bûches pour le protéger. On pouvait poser les bûches, mais elles ne servaient à rien.

Nous avions durant le (long) upload final à 15 heures équilibrées le jeu en modifiant le coût des unités, vitesses de déplacement, vitesse d’accumulation des ressources, ressources données par les coquillages, vies du châteaux car nous n’avions pas eu le temps. Le jeu souffre toujours d’un problème de chance aléatoire qui ne requiert pas du « skill », car des coquillages peuvent spawn plus près d’un des deux joueurs et ainsi lui confier plus de ressources (c’est visible dans la vidéo de gameplay). Nous avions pensé à ce que le joueur en difficulté gagne de la furie pour utiliser son ulti, mais nous avions peur que le jeu soit sans fin. Des modifications peuvent être faites, nous pouvons toujours implémenter l’idée et modifier la vitesse de remplissage de la fosse (nombre de grandes vagues) et de la furie pour que celui qui défend à seulement un petit coup de pouce.

Ce que la Game Jam m’a apporté

J’ai ici pu explorer un style cartoon, j’ai pu aussi me rendre compte de mes lacunes en animation d’assets et en simulation physique > baking de l’animation > export. J’ai aussi passé beaucoup de temps à peaufiner le garçon et la fille, surtout pour les doigts et de donner des poses asymétriques aux sculptures et malgré ça il y a toujours des choses à revoir. Ce sont des points sur lesquels je compte travailler. Je souhaite aussi découvrir le lightmap baking et le post-processing. J’ai pu aussi me rendre compte qu’une grosse équipe de game designer n’ai pas une très bonne idée, beaucoup de confusion sur le travail à faire et une certaine pression donnée au reste de l’équipe qui font de la production à savoir les artistes, programmeurs et sound designer. À force d’être pressé, un des game designer autoproclamés producteurs a pris la grosse tête et souhaitait contrôler toute la production nous donnant un peu la sensation d’être des larbins et en commençant à devenir agressifs le dernier jour. De plus ce qui était assez gênant c’est que ces personnes ne produisent rien, n’ont pas les compétences pour le faire et passent derrière à regarder ce que l’on est en train de faire. Cela m’a personnellement donné davantage l’envie de faire un jeu en tant qu’indépendant et ai pu ressentir et découvrir une autre facette de Game Artist le temps d’un week-end, comprendre ce que subissent les artistes dans des studios avec une direction très stricte où chaque asset et DA (Direction Artistique) est imposé avec des deadlines pendant que d’autres ne font rien et ne savent pas faire. Je comprends un peu mieux pourquoi de plus en plus les quittent pour ce lancer en indépendant: donner vie à ses idées sans pression derrière ni jugement. Finalement, je ne dis pas que le « producteur » avait de mauvaises idées, mais que je n’ai pas apprécié n’avoir aucune autre solution que d’obéir à ses ordres pendant qu’il ne faisait rien pour accélérer la création du jeu, je pense que je n’aurais pas tenu dans une 72 heures game jam. Au final, j’ai eu l’impression dans cette équipe en vidéo avec des game designers qui attendent l’arrivée des assets en se tournant les pouces: https://youtu.be/dcIlMnz90Xs

J’en conclus que la création de jeux vidéo m’intéresse à condition de pouvoir exprimer mes idées, c’est-à-dire garder le contrôle total dessus. Cela veut aussi dire que je ne suis pas fait pour travailler dans un studio de jeu vidéo. C’est le cas de beaucoup devenu indépendant.