Journal de bord

Journal de bord

Par Swing Swing Submarine Blog créé le 08/01/10 Mis à jour le 05/04/15 à 22h03

Ajouter aux favoris
Signaler
Seasons after Fall

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 :) 

Ajouter à mes favoris Commenter (8)

Commentaires

Swing Swing Submarine
Signaler
Swing Swing Submarine
Mais pas de quoi funduk. Tout le plaisir est pour nous. Et en plus vous nous le rendez bien en venant nous rendre visite!
Bon, certes, parfois on laisse trainer 1 mois sans poster ne serait-ce qu'un truc (sans compter mes fautes d'orthographe :)), mais on essaie de laisser des news, c'est plus conviviale.

Guillaume
funduk
Signaler
funduk
Je sais que je ne devrais pas faire ca, parce que c'est dramatiquement classique et inutile, mais face au sérieux et à l'énergie que vous mettez pour nous tenir au courant de l'avancement du projet, et pour répondre à nous interrogations, je voulais juste vous dire merci.
Swing Swing Submarine
Signaler
Swing Swing Submarine
Salut funduk,
merci de ton message super constructif (comme tous les autres d'ailleurs, vous êtes trop classes)

Pour les éléments 3D, on va faire très attention à ce qu'ils respectent le rendu 2D, donc ils ne devront pas faire tâche mais juste facilité le construction du niveau.
Ma grotte de programmeur est un assez bon exemple : si on veut le faire a la manière des vieux jeux 2D d'antan, il nous faudrait 2 sprites : un pour l'arrière de la grotte et l'autre pour l'avant, de sorte à pouvoir faire rentrer le renard dans la grotte.
De plus, on aurait vraiment l'impression que la grotte est une juxtaposition de 2 plans fixes car -par exemple- l'ouverture de celle-ci serait toujours de la même taille. Avec une approche 3D, la taille de l'ouverture varie car lorsque la caméra est plus ou moins proche de l'entrée.
Pour faire simple et pour illustrer le phénomène, tu peux prendre un livre et le mettre en face de toi, en le regardant sur la tranche. Imagines que l'entrée de la grotte est dessinée sur la couverture... normalement avec une telle configuration tu ne vois pas l'entrée de la grotte... mais si tu décales ta tête (la caméra) sur un côté, alors que vois de mieux en mieux l'entrée.
Cet effet donne plus de profondeur à la scène, sans pour autant qu'on est l'impression qu'un objet 3D c'est tapé l'incruste.

De même, on construit plus facilement une forêt, car les objets que l'on place de plus en plus loin dans la map seront de plus en plus petits et sembleront défiler moins vite que les objets du premier plan. Ça évite donc toute sorte de bidouilles que l'on a lorsque l'on est en 2D.

Pour le moteur physique, on l'utilise comme détecteur de collision uniquement car ça aurait pu être gérable de laisser faire le moteur physique mais il aurait constamment fallu penser "quel poids fait ce truc", "quel rugosité doit avoir ce machin". Et parfois dans un moteur physique, le coefficient que tu mets... tu sais pas trop quoi mettre parfois, et ça revient à chercher des "magic numbers", des coefficients qui vont bien pour que la simulation ne fasse pas n'importe quoi.
Et puis il y avait, entre autres, l'interrogation suivante : "qu'est ce qu'on fait si le joueur empile pleins de petits éléments qu'il trouve dans le niveau et les mets sur un élément comme le tronc en équilibre mais qu'il n'en trouve pas assez pour le faire basculer, ne va-t-il pas pensé qu'il faille trouver d'autres petits éléments plutôt que de ramener un rocher qu'il n'aura pas forcément vu car la solution d'empiler de petits trucs lui semblait évidente" ou encore "si le joueur voit un rouage et qu'en grimpant sur ce rouage celui-ci se mette à tourner un petit peu, ne va-t-on pas faire penser que seul le renard peu entrainer correctement le rouage ? Alors que la solution se trouve peut être dans un élément se trouvant dans une saison donnée...".

Bref, dans les 2 cas y'a quand même des choses à faire :
- régler les coefficients des liaisons physiques et des matériaux physique pour que cela fasse ce que l'on veut (dans le cas où on laisse le moteur physique gérer)
- scripter les comportements des liaisons et des contacts avec certaines matières (dans le cas où on utilise le moteur physique uniquement pour détecter les collisions, ce qui est notre cas)

On a choisit de scripter car on a essayé de laisser gérer le moteur physique et on avait plus l'impression de bidouiller qu'autre chose (ça doit venir du fait que mon expérience avec les moteurs physique mélangé a du gameplay est assez faible, donc j'ai utilisée la manière qui me mettait plus à l'aise).

Je vais arrêté là, parce que pour le coup ce post va devenir vraiment imbuvable :)

Merci à toi de nous avoir fait part de ton avis et tes interrogations.

Guillaume
funduk
Signaler
funduk
Peut-être pas dans des posts de blog, mais j'ai déjà vu beaucoup plus gros et indigeste, et surtout pas aussi sympa et facile à lire et à comprendre.
En revanche, Seasons ayant une esthétique très 2D, y ajouter des éléments en 3D ne va pas casser cette ambiance ? Quoique, bien utilisé, ça peut rendre des parties du background beaucoup plus remarquables, et on vous fait confiance pour bien gérer ça.
Alors, 2ème partie ...
"Seasons is not a physics game"
Wine is not an emulator ...
De toute façon, sur un jeu en 2D, dans une dev team de deux, un vrai moteur physique deviendrait vite ingérable, surtout si le jeu l'utilise pour des méchaniques de gameplay. Pourtant, c'est exactement le type d'énigme que l'on trouve dans HL² : l'équilibrage demande-t-il vraiment tant de boulot ? Est-ce que c'est ca qui a retardé le jeu ?
En tout cas, bravo pour votre boulot. Le jeu commence à prendre forme, hâte de voir le résultat final !
Swing Swing Submarine
Signaler
Swing Swing Submarine
Merci Druss,

Nous aussi on aime bien la 2D, mais quitte à simplifier la tâche, on passe en 3D toujours avec un esprit et un rendu 2D, comme cela fini les galères de réglages de layers et de layers de parallax.

Et puis la direction prise pas la Team Ancel (de la 3D vu de profil, c'est ce qu'ils utilisent aussi dans le Ubi-Art Framework) nous a pas mal rassuré aussi. Donc on c'est dit qu'on pouvait aller dans ce sens aussi ^^

Guillaume
Druss
Signaler
Druss
Ce post était super intéressant (ni trop gros, ni indigeste). Et parfaitement compréhensible parce que bien expliqué. La preuve en est que j'ai réussi à comprendre. lol

Perso, la 2d j'ai ça dans la peau (old school power). Ceci dit il est vrai que la 3d semble pratique. Pareil pour pour la physique, un moteur parfaitement calibré par vos soins sera mieux à même de vous servir.

Vraiment marrant, le t-shirt. :)
Swing Swing Submarine
Signaler
Swing Swing Submarine
Merci de ton feedback Mosieur Enimal :)

C'est vrai que le post est un peu gros, et peut être indigeste. Mais je vois que tu as saisi tous les sujets de ce post, donc je suis rassuré ^^

Bonne soirée !

Guillaume
Enimal
Signaler
Enimal
Ouah, ça c'est un post de blog complet.
Merci pour le topo sur l'orthogonalité et la perspective
Personnellement, je préfère la map en vraie 3d, car si on visualise la scène avec un autre angle, elle reste cohérente, ce qui n'est pas le cas lorsque l'on crée une map style 2d.

En ce qui concerne la physique, étant donné que Seasons ne nous permettra pas de contrôler une balle rebondissante qui se cognera contre tout les éléments du décors, je trouve votre choix totalement justifié.
Il vaux mieux avoir un bon script, plutôt qu'un moteur physique hasardeux.

Ce post était très instructif, merci :)

Édito

Grâce à ce mini-devblog en français, vous pourrez suivre l'activité de notre minuscule studio de développement indépendant Swing Swing Submarine.

Nous sommes une petite équipe d'hommes et de chats passionnés qui souhaitent partager de nouvelles expériences interactives avec les joueurs du monde entier, et ceux de Gameblog en font bien évidemment partie !

--------------------------------------------------------

Quelques liens utiles :

> Site officiel <

> Twitter <

> Facebook <

Archives

Favoris