Après les envolées lyriques et poétiques de William, voici venu le temps de parler un peu de technique. Ça va être chiant je sais, mais je vais essayer de m'attarder sur 3 points visuellement quantifiables (oui ça veut rien dire).


Passage de l'orthogonalité à la perspectivité

Le plus gros changement opéré niveau moteur est la possibilité de construire des niveaux en "vraie 3D".

Jusqu'alors les niveaux étaient constitués de calques (layers) et chaque layer possédait une vitesse de scrolling (pour obtenir un effet de parallax).

Voilà ce que cela donne si l'on visionne une map de test en vue isométrique : 

Scène organisée en layers 2D


On remarque que la distance entre les layers n'a pas d'importance du fait que le jeu utilise une caméra à projection orthogonale pour afficher la scène (caméra qui ne retransmet pas la notion de perspective).

On note aussi que les arbres des différents layers ont des tailles différentes (ajustées à la main) pour justement compenser le fait que la caméra ne retranscrit pas la notion de perspective et donc d'éloignement. Les troncs des arbres n'appartiennent pas au même layer que le feuillage pour pouvoir se chevaucher dans le bon ordre (le feuillage devant le tronc).

La rivière est un objet spécial qui est un quad texturé (4 vertices) qui se déforme selon la position de la caméra.

La nouvelle approche consiste à créer la map en "vraie 3D". C'est-à-dire que le positionnement des objets a une importance car la caméra utilisée va prendre en compte la perspective. Dès lors deux objets de même taille physique auront une taille différente à l'écran si leur positionnement dans l'espace est différent.

Voilà à quoi ressemble la même map de test avec une réorganisation des objets pour être compatible avec cette approche "3D" :  

Scène organisée avec une spatialisation 3D

On n'a plus vraiment de disposition en layer, de vrais objets 3D font leur apparition (l'espèce de grotte ainsi que la rivière qui est maintenant un ensemble de polygones)

Les arbres sont disposés de manière cohérente et le couple tronc/feuillage est maintenant sur un même plan.

Voici ce que donne une vue depuis la caméra du jeu, pour chacune des approches :

Scène 2D style (caméra à projection orthogonale)


Scène 3D style (caméra à projection perspective)

 

Chacune des approches a ses avantages et inconvénients :

  • Avec l'approche "2D", on peut facilement construire une scène à partir d'un artwork. On peut également aisément tricher sur le positionnement en profondeur des objets car il n'y a pas de répercutions du point de vue de la caméra.
  • L'approche "3D" quant à elle permet de ne pas avoir à gérer le dimensionnement manuel des objets (car la taille des objets est gérée automatiquement par la perspective), mais demande plus de travail de positionnement et de modélisation des objets. L'avantage ici est que l'on peut insérer des objets 3D dans le décor, comme le tunnel rocheux (programmeur modélisation style inside).

Au final, notre moteur reste compatible avec les 2 méthodes, et nous pouvons utiliser l'une ou l'autre des solutions selon la complexité du décord dans lequel nous nous trouvons.  

 

Seasons n'est pas un physics game

On a rien contre les physics games, bien au contraire, on adore les jeux de Petri Purho et autres World Of Goo. Mais dans le cas de Seasons, on ne voulait pas se retrouver a laisser le moteur physique gérer des mécaniques de gameplay.

On utilise un moteur physique (Box2D jusqu'à présent), mais on ne l'utilise que pour détecter les collisions.

Les objets que l'on place dans le moteur physique sont des objets dits "kinetics" (à ne pas confondre avec Kinect, même si l'étymologie est bien la même). Les objets "kinetics" ne sont pas animés automatiquement par le moteur physique, pour les faire bouger, notre code doit leur appliquer des forces et autres vitesses lui même. Avec une telle approche, les objets n'ont pas de gravité par défaut, c'est à notre code de lui soumettre des forces pour simuler cette gravité (il en va de même avec les frottements, rebonds, etc...).  

Dans ce contexte, j'ai donc réalisé un système qui nous permet de scripter des liaisons physiques. Le meilleur exemple qu'on peut donner est celui d'un objet pivotant :

 

Une vidéo d'une map de programmeur (avec un Level Design qui veut rien dire)

 

Dans cette vidéo, un semblant de tronc d'arbre coupé voit son équilibre perturbé par un rocher de programmeur et notre renard. Cependant la puissance/vitesse de basculement  est scriptée, maitrisée par notre code et non le moteur physique. On remarque aussi que si le renard saute de l'autre côté de la "balance", le rocher n'est pas propulsé dans les airs par un effet de catapultage.

On peut imaginer que le renard doive accumuler un certain nombre d'objets pour faire basculer totalement le tronc d'un côté ou d'un autre. Laisser faire cela par le moteur physique aurait été horriblement dur à paramétrer. Ne serait-ce que pour donner un poid cohérent aux objets afin qu'ils puissent inculquer assez de force dans la liaison de pivot du tronc pour que celui-ci basule plus ou moins.

On aurait aussi pu imaginer que le rocher en lui-même n'ait aucune influence sur le basculement et que seul le renard possédait cette faculté :  

 

Une autre vidéo d'une map de programmeur (avec un Level Design qui veut toujours rien dire et un exemple très illogique aussi)

 

Dès lors c'est notre script qui détermine comment réagissent les éléments physiques entre eux, et non un paramétrage fastidieux (et parfois imprécis ou bancal) du moteur physique et des objets physiques qu'il manipule.  

 

Le Post Process

Vous le savez, nous n'avons pas trop le temps ni les moyens de produire un nombre de textures incalculable pour Seasons. William a donc déniché une technique de sioux pour donner un aspect "cool" au jeu : un filtre photoshop avec une texture de bruit qui va bien.

Illustrons la construction de l'image de la news précédente :  

Photoshop et sa magie interne (avec une texture de bruit de programmeur)

 

Le filtre Photoshop utilisé doit être reproduit in-game. Pour se faire on en vient à utiliser des effets de post-process que l'on retranscrit grâce à l'usage de shaders. Il restait à définir la formule magique utilisée par Photoshop. Pour se faire on sort google (outil de recherche de formule éprouvé :)) et RenderMonkey (un logiciel permettant d'écrire des shaders peinard dans son coin). Après quelques heures, la petite formule magique est découverte :  

Un shader qui au final tient sur une ligne et une 100aine de caractères

 

On peut alors utiliser cet effet in-game. Youpi.

 

Les restes

Pour le reste, j'ai poursuivi l'élaboration de maps de test pour illustrer des mécaniques de gameplay qui seront intégrées dans les vrais niveaux conçus par William, avec son outil favori : Blender.

Outil auquel j'ai apporté quelques améliorations et corrections pour que William craque le moins possible lorsqu'il l'utilise pour mettre en oeuvre son Level Design :)

Ainsi nous avons maintenant un "file checker" qui va lister correctement toutes les erreurs de la map et parfois tenter de les corriger lui-même (manque d'une caméra, matériaux avec des textures qui ne pointent  pas dans le bon répertoire... etc). 

Le T-shirt qu'il faut que j'achète pour bien conditionner William

 

J'espère que je ne vous ai pas trop saoulé avec ces quelques considérations techniques, et à bientôt pour de nouvelles neuves du monde de Seasons !

 

Guillaume

 

EDIT: N'hésitez pas à nous faire part de vos questions/remarques dans les commentaires si certains points de ce billet restent obscurs :)