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
Pendant ce temps, sur terre

Super Meat Boy est disponible dès aujourd'hui sur le Xbox Live Arcade (800 MS points en offre de lancement, 1200 MS points à partir de novembre) et il envoie du steack !

Le jeu sortira également sur Wii, PC et Mac d'ici la fin de l'année.


Il est fort probable que vous connaissiez déjà Super Meat Boy même si vous ne suivez pas assidûment l'actualité des jeux indépendants. Peut-être avez-vous déjà joué à Meat Boy, un jeu flash créé par Edmund McMillen et Jonathan McEntee qui fait aujourd'hui office de prototype de Super Meat Boy. Ou peut-être avez-vous déjà vu l'excellent trailer du jeu tout droit sorti des années 90 :

En tout cas à Swing Swing Submarine, ça fait un moment qu'on suit le développement de SMB et qu'on attend de pouvoir s'y essayer. Parce qu'on est fan des travaux d'Edmund McMillen (Gish, Aether, Time Fcuk), des musiques de DannyB (Meat Boy, Canabalt, Fathom) et que Tommy Refenes, programmeur du jeu, en plus d'être doué nous fait bien rire.

Pendant 18 mois, Edmund et Tommy ont cravaché dur et pas qu'un peu vu le contenu du jeu. Jugez plutôt :
- 150 niveaux de pur plateforme déclinés en deux versions "normal" et "cauchemar" (150 x 2 = 300 niveaux)
- de bons gros boss
- 15 personnages débloquables aux capacités uniques
- et une section appellée Teh Internets qui permettra de rajouter encore plus de contenu gratuit au jeu dans les semaines à venir. Sans oublier qu'un éditeur de niveaux sera accessible sur la version PC et que les niveaux créés par les joueurs pourront être partagés entre eux.

Mais vous pensez peut-être qu'on le survend, non ?
Dans ce cas, regardez plutôt ce qu'en disent les journalistes spécialisés.

Après, rien ne vous oblige pas à acheter le t-shirt du jeu pour prendre la pose comme Edmund et Tommy.

 

William

EDIT: Super Meat Boy Soundtrack dispo!

Ajouter à mes favoris Commenter (35)

Signaler
Seasons after Fall

Salut tout le monde !

Prêts pour un nouveau "tech post" avec une vidéo bonux intégrée ? Cette fois-ci on va parler des tests de visibilité dans Seasons.

La semaine dernière, j'ai donc tenté d'améliorer le code de rendu pour réduire le temps que nous passons à fabriquer les images.

 

>> Contexte

Jusqu'à présent, je ne m'étais pas trop soucié de l'optimisation du rendu (faut croire que je me soucie de pas grand chose en fait !). Quelques techniques d'optimisation avaient bien été implémentées... Mais comme nous sommes passé d'un affichage style 2D à style 3D (souvenez-vous), le tout est devenu très buggué... jusqu'à la semaine dernière !

 

>> Frustum

La chose principale que l'on essaie de faire lorsque l'on veut optimiser l'affichage, c'est de n'envoyer au rendu que les objets qui seront visibles depuis le point de vue de la caméra. Ça peut sembler logique mais c'est une chose qui n'est pas automatiquement gérée par un quelconque hardware. On doit donc prendre en charge tout cela du côté du moteur de jeu (côté CPU la plupart du temps) afin de d'alléger le rendu. On appelle le procéder le "culling" (l'élimination des parties cachées). 

Pour parvenir à déterminer ce qui est visible de ce qui ne l'est pas, on peut compter sur l'utilisation intensive du frustum. Le frustum est une structure géométrique prenant très souvent la forme d'une pyramide tronquée. Cette forme représente ce que voit la caméra et comment elle projette ce qu'elle voit sur son capteur CCD qu'est l'écran.

Un frustum et sa caméra

Les objets partiellement ou entièrement contenus dans le frustum de la caméra sont potentiellement visible à l'écran. Potentiellement car ces objets peuvent être cachés par d'autres objets plus proches et/ou plus gros également présents à l'intérieur du frustum.

 

L'algorithme

Comme vous l'aurez compris, l'idée est d'empêcher certains objets d'être dessinés en testant leur visibilité avec le frustum de la caméra. Voici le pseudo-code (algorithme).


FONCTION mise à jour/rendu
{
    POUR CHAQUE Objet dans la liste des objets du niveau FAIRE
    {
        SI l'Objet courant est dans le frustum ALORS
        {
            rendre l'objet 
            (ou le mettre à jour,
            ou effectuer une action)
        }
    }
}

Et voici un petit schéma pour illustrer la situation. On y montre une scène composée de 25 objets et d'un frustum, le tout en vue de dessus.

Le frustum et les 25 objets, le dernier film dans vos salles

Seulement 3 des objets de la scène sont à l'intérieur du frustum et seront donc envoyés au rendu.

Avec cette technique, on évite de rendre 22 objets mais on doit quand même parcourir TOUS les objets de la scène afin de savoir au cas par cas qui est potentiellement visible et qui ne le sera définitivement pas. Notre scène d'exemple ne contient que 25 objets, mais dans le cas de scènes plus complexes, on va passer un temps fou à tester beaucoup d'objets... et dans le jeu vidéo plus qu'ailleurs, on évite de passer trop de temps machine à calculer une image sous peine d'avoir un jeu qui perd en fluidité.

Le rêve américain, c'est de mettre moins de 16 millisecondes pour construire une image du jeu.

Pour éviter de parcourir tous les objets de la scène, on peut tenter de faire des groupements d'objets. Ces groupes vont contenir des objets spatialement proches.

>> Élimination par grille

Il existe une multitude de manières de regrouper des objets afin de simplifier le travail d'élimination des parties cachées. On peut citer les BSP, les portails ou encore les Quadtree et autres Octree... mais nous n'utiliserons aucune de ces méthodes. Nous n'allons pas élaborer de zones hiérarchiques ("tree" insinue arborescence) mais nous allons nous contenter d'une grille 3D régulière.

Parce que nous ne sommes pas dans le cas d'un jeu réellement en 3D (dans le sens où les objets affichés ont des épaisseurs infimes et sont toujours face caméra, et que la caméra regarde toujours le long d'un axe donné), alors nous pouvons nous permettre d'opter pour une solution moins "complexe" que celles sus-citées.

Ce que nous voulons, c'est retirer au plus tôt quelques objets supplémentaires de la boucle du pseudo code précédent, aussi vite que nous le pouvons. En ayant un système plus élaboré, on perdrait plus de temps à maintenir ce système que de conserver notre grosse boucle.

Voici un exemple simpliste de grille 3D. La grille est composée de cellules de couleurs différentes.

Mini grille régulière

On remarque que 2 cellules sont visibles car contenues dans le frustum de la caméra. On note aussi que cette grille est vraiment simpliste, mais c'est pour l'exemple !

 

L'algorithme

Le pseudo code mettant en jeu une grille est un peu plus complexe que le précédent car il se compose de 2 étapes.

La première étape consiste à enregistrer un objet nouvellement créé dans une ou des cellules de la grille.


FONCTION ajout d'objet/déplacement d'objet
{
    dé-enregistrer l'Objet de la grille 3D
    (si il était enregistré)

    trouver les cellules de la grille qui contiennent l'Objet
    (facile à faire car la grille est régulière)

    enregistrer l'Objet dans les cellules trouvées
    (dans le meilleur des cas l'Objet se trouve que dans
    une seule cellule)
}

Et voici l'équivalent du pseudo code de mise à jour rendu de tout à l'heure !


FONCTION mise à jour/rendu
{
    déterminer quelles sont les cellules visibles autour de la caméra
    (facile à faire car la grille est régulière)

    POUR CHAQUE Cellule visible par la caméra FAIRE
    {
        POUR CHAQUE Objet enregistré dans la cellule courante FAIRE
        {
            SI l'Objet n'a pas encore été traité ALORS
            {
                SI l'Objet courant est dans le frustum ALORS
                {
                    rendre l'objet
                    (ou le mettre à jour,
                    ou effectuer une action)

                    marquer l'objet comme traité
                    (pour ne pas être traité une 2eme fois
                    durant la même image dans le cas où l'objet
                    était enregistré dans plusieurs cellules)
                }
            }
        }
    }
}

Et voici l'illustration des objets et des cellules sur une même image.

Frustum, cellules, grille et objets : le megamix

Comme vous pouvez le constater, 2 cellules sont visibles, et 7 objets sont testés avec le frustum (au lieu de 25 précédemment).

 

Réglages

Pour avoir une élimination des plus efficaces, il convient d'effectuer des réglages sur le nombre et la taille des cellules. En effet, si la taille des cellules est trop petite, alors on aura beaucoup de cellules et dans le pire des cas on obtiendra 1 objet par cellule, ce qui revient à ne pas utiliser de grille et de cellules du tout, en pire.

Si les cellules sont trop grandes, on se retrouve dans la même situation car dans un cas extrême la scène ne contiendrait une grille composée que d'une seule cellule, ce qui revient à ne pas utiliser de grille.

Il faut donc trouver le juste milieu, et pour cela il convient déjà de créer des niveaux afin d'avoir l'échelle des objets qui y sont positionnés. De là on peut ajuster la taille des cellules.

 

>> C'est dans la boite

Pour pouvoir déterminer si un objet est dans le frustum, on doit connaitre son encombrement. Pour déterminer cet encombrement le plus rapidement possible, nous n'utilisons pas directement le maillage d'un objet ni même sa boite englobante orientée (OOBB, Oriented Object Bounding Box) mais plutôt une enveloppe englobante plus simpliste encore : la boite englobante alignée aux axes du monde (AABB, Aligned Axis Bounding Box).

Voici un exemple de l'évolution d'une AABB en comparaison d'une OOBB sur un maillage de chat qui subit diverses rotations (non, ce n'est pas Buster).

Maintenant vous voyez un chat pivotant, sans prendre de drogue (en haut l'AABB, en bas l'OOBB)

 

En utilisant une AABB plutôt qu'une OOBB, on rend le calcul de visibilité super simple et rapide (ou efficace et pas cher, comme vous préférez). Pour mieux comprendre pourquoi une telle facilité, voici des exemples de situations de positionnement entre 2 AABB.

Quelques unes des configuration possibles entre 2 AABB

 

On ne présente pas toutes les combinaisons possibles, mais l'algorithme utilisé pour savoir si oui ou non 2 AABB se superposent prendra dans tous les cas le même nombre de calculs, quelque soit la configuration. Revoici nos AABB mais cette fois-ci avec des vecteurs tracés entre certains des coins des boites :

AABB et vecteurs reliant les coins bas-gauche et haut-droit

 

Les vecteurs tracés connectent toujours le coin bas-gauche d'une boite avec le coin haut-droit de l'autre boite.

Il devient alors facile de remarquer que 2 AABB se superposent quand les 2 vecteurs ainsi formés pointent une direction Nord-Est. On peut aussi dire que 2 AABB se superposent dans les cas particuliers où les vecteurs pointent une direction Nord (vecteur vertical pointant vers le haut) ou Est (vecteur horizontal pointant vers la droite).

Je ne vous écrirais pas le pseudo code ici, mais on voit bien que le calcul est vite fait, et qu'il fait bien toujours le même nombre d'opérations.

 

>> Résultats dans le jeu

C'est bien joli tous ces trucs théoriques, mais si on matait une petite vidéo maintenant ?

Vous allez y voir plein de boites englobantes, des rouges (pour les objets), une bleue (représentant la coupe du frustum le long du plan vertical autour de Z = 0) des vertes (pour les cellules de la gille).

La boite bleue varie de taille uniquement pour montrer comment les objets sont rejetés ou acceptés. Changer la taille laisse apparaître un phénomène de poping pour bien mettre en évidence le culling.

Du point de vue du framerate, voici quelques chiffres relevés sur ce niveau qui reste toutefois assez petit/simple :

- 48 fps sans aucune optimisation de visibilité
- 55 fps quand les AABB des objets sont testés directement avec le frustum (sans l'usage d'une grille)
- 60+ fps quand on utilise une grille ("+" car le moteur limite le framerate à 60 fps)

Tout ceci sur mon PC pas terriblement récent (P4 C 2.8Ghz et sa copine Geforce 7600Gt, AGP s'il vous plait !).

 

>> Pour conclure

C'était une première passe d'optimisation, il y en aura forcément d'autres. On ne vise pas des configurations de fous, donc il faudra qu'on s'applique à ce que le jeu tourne sur une grande variété de machines.

Dans un prochain article sur l'optimisation, on pourra pleinement parler de choses passées sous silence ici, comme le Batching, ou l'utilisation de buffer dynamiques vs. buffer statiques ou d'autres joyeusetés du genre.

 

Pour le moment, place à vos remarques et expériences vis à vis de la visibilité dans les jeux (en tant que joueur ou développeur) ! 

 

Hop, je ne suis plus visible.

Guillaume

Ajouter à mes favoris Commenter (22)

Signaler
Seasons after Fall

Maintenant que Guillaume a développé les outils nécessaires, je peux m'atteler à l'intégration d'effets sonores avec l'aide de notre sound designer (que nous vous présenterons bientôt).

En parallèle, il me faut également revoir le level design de certains passages de la démo qui ont montré quelques faiblesses pendant le Festival du Jeu Vidéo. Vous allez comprendre pourquoi au travers d'un exemple concret...

> Contexte de la séquence de jeu :

En arrivant dans la grotte, le joueur découvre qu'il est possible de faire pousser des arbres "plateformes" en exposant des arbrisseaux à la lumière du soleil (en passant en été). Les premiers abrisseaux rencontrés sont déjà présents dans le niveau, mais c'est ensuite au joueur de créer lui-même des arbrisseaux. Pour se faire, le joueur doit trouver un fruit et un endroit où il peut l'enterrer.

Comme vous pouvez le voir dans la vidéo, le joueur trouve d'abord un endroit où il peut creuser un trou et doit ensuite se mettre en quête d'un fruit. Il en trouvera plusieurs en continuant son chemin, tombés au pied d'un arbre, au milieu d'une grotte plongée dans l'obscurité.

Malheureusement, plusieurs joueurs ont éprouvé des difficultés à résoudre cette petite énigme...

> Ce qui pose problème :

1 - Le joueur doit trouver un fruit, mais il n'a encore jamais rencontré d'arbres à fruits et ne sait donc pas à quoi ils ressemblent.

2 - Le joueur doit trouver cet arbre dans un niveau "labyrinthe" plongé dans le noir, ce qui peut s'avérer décourageant et rend plus difficile encore la tâche d'identification de l'arbre à fruits.

3 - Et quand bien même le joueur trouverait l'arbre en question, il n'a aucune idée de la saison qui fait apparaître les fruits. Le joueur peut donc tout à fait penser qu'il s'agit d'un arbre lambda s'il n'essaie pas de changer de saison près de l'arbre.

L'apprentissage est une notion extrêmement importante dans un jeu vidéo. Peu de joueurs apprécient les tutoriels qui sont souvent longs et rébarbatifs, c'est pourquoi il est conseillé de faire du jeu lui-même un immense tutoriel. Comprendre par là qu'il est préférable d'apprendre de nouvelles choses tout au long d'un jeu plutôt que de tout apprendre d'un coup au début.
Or dans cette séquence précise, j'ai omis d'apprendre au joueur l'existence des arbres à fruits tout en rendant plus difficile encore leur identification en plongeant le niveau dans le noir ! Ce n'est vraiment pas très malin de ma part, mais heureusement les tests sont faits sont pour trouver et corriger ce genre d'erreur, et il existe des solutions.

> Quelques améliorations possibles :

1 - "Le joueur ne sait pas à quoi ressemble un arbre à fruit" : pour corriger ça, il suffit de poser des arbres à fruits dans les niveaux précédents. De cette façon, le joueur pourra se familiariser avec leur forme et leur fonction avant même d'être confronté à une énigme faisant intervenir les fruits.

2 - "Le joueur ne sait pas en quelle saison les fruits apparaissent" : dans la démo, les fruits apparaissent au printemps. Il faut faire en sorte que, dans les niveaux précédents, les arbres à fruits soient visibles (mais pas forcément accessibles) à des endroits où le joueur est obligé de passer au printemps. Ainsi, le joueur en observant le décor remarque que des fruits apparaissent sur certains arbres au printemps. L'association arbre / saison / fruit l'aidera plus tard à résoudre des énigmes.

3 - "Le joueur peut se perdre dans le noir" : quand le renard n'est pas éclairé par une luciole, le joueur ne voit pas où se trouve son personnage ni ce qui l'entoure et peut donc se perdre facilement. Au lieu de l'obliger à suivre les lucioles, on donne au renard la possibilité de tenir dans sa gueule un objet qui éclaire tout autour de lui, ce qui facilite grandement la navigation au sein du niveau et la reconstitution mentale du labyrinthe.

> Avant / Après :

Il existe dans la grotte un endroit où le passage au printemps est obligatoire : la cuve d'eau. Le mur au centre de la cuve ne servait pas forcément à grand-chose, je l'ai donc supprimé et remplaçé par une plateforme en hauteur (inaccessible) sur laquelle est posé un arbre à fruits. Quand le joueur passe au printemps pour faire monter l'eau dans la cuve, il voit les fruits apparaitre sur l'arbre.

Dans le niveau plongé dans le noir, le renard était obligé de rester dans la lumière des lucioles pour être vu par le joueur. J'ai laissé quelques lucioles et j'ai rajouté une lanterne au début du niveau sans laquelle on ne peut pas accéder à l'arbre à fruits. Les quelques lucioles laissées en place servent à baliser le chemin retour du renard lorsqu'il aura lâcher la lanterne pour prendre un fruit dans sa gueule.

William

Ajouter à mes favoris Commenter (16)

Signaler
Seasons after Fall

Salut tout le monde,

Quoi ? On n'a pas fait de post cette semaine encore ? Laissez-moi corriger ce rythme pas très sérieux !

Cette semaine, on va parler son. Je préviens, je ne suis pas expert en programmation sonore, alors certains risquent d'avoir le poil qui se hérisse !

Le son jusqu'alors

Depuis le début du développement de Seasons, nous nous sommes très peu préoccupé de la partie sonore. La seule passe de sons a été faite par William lors de la conception du 1er prototype. Elle consistait en la fabrication de bruitages sonore style 8bits avec l'excellent logiciel sfxr !

Pour poursuivre l'aventure, nous avons besoin de sons (bruitages et fonds sonores) plus réalistes, moins 8 bits style ! Et la manière de jouer ces sons doit aussi être plus "réaliste".

 

Nouveaux types de sons

Nous avons deux types de sons : les sons spatiaux et les sons ambiants.

Les sons spatiaux sont des sons dont le volume varient en fonction de la distance entre l'émetteur sonore et le récepteur sonore (micro).

Les sons ambiants sont des sons que l'on entend de partout, quelque soit la position du récepteur sonore.

Voici un petit schéma récapitulatif qui montre 2 niveaux de jeu. L'un des niveaux possède un son spatial et l'autre un son ambiant. Les deux niveaux de jeu sont reliés par un système de portes.

Spécificités du son spatial

On remarque que le son spatial possède 3 caractéristiques :

- une position : c'est de là que le son est émis

- un périmètre intérieur (ici en jaune). Si le récepteur sonore (micro) se trouve à l'intérieur de ce périmètre, alors le son est joué à 100% de son volume maximal.

- un périmètre extérieur (ici en orange). Quand le récepteur sonore entre dans ce périmètre, le son devient audible. Plus le récepteur sonore s'approche de la frontière avec le périmètre intérieur, plus le son devient fort. Bien entendu, lorsque le récepteur sonore est positionné au delà du périmètre extérieur, le son n'est plus audible du tout.

Certaines librairies sonores permettent de gérer ce que l'on appelle des "sons 3D". La librairie que nous utilisons actuellement (irrklang) permet sur le papier de gérer automatiquement des sons 3D.
Malheureusement, on n'a pas la maîtrise totale sur la manière dont les sonorités sont atténuées. Ceci car on ne peut indiquer à cette librairie qu'un périmètre externe au delà duquel un son 3D n'est plus atténué. La fonction d'atténuation n'est pas réglable et on se retrouvait avec des sons audibles depuis bien trop loin... on a donc décidé de gérer nous même l'atténuation et le "pan" (répartition gauche-droite du son).
On se retrouve donc avec des sons 2D classiques qui ne gèrent pas d'eux-mêmes l'atténuation sonore et le "pan", c'est notre moteur qui va modifier le volume sonore et le pan de chaque son 2D que l'on veut gérer comme s'il s'agissait d'un son 3D.

Spécificité du son ambiant

Le son ambiant est un bête son 2D que l'on entend de partout. Nous avons cependant limité son écoute à l'intérieur du niveau où il a été créé.

Un son 2D dit "ambiant" joué en boucle peut aisément faire office de fond sonore à l'intérieur d'un niveau.

Mise en pratique

C'est bien beau tout ce texte et ce baratin technique, mais ça donne quoi pour le moment l'intégration des sons dans Seasons ?

Et bien ça donne ce que l'on trouve dans la vidéo suivante. Attention toutefois : les sons présents ne sont pas les sons définitifs mais des sons pour tester. Les niveaux sonores n'ont pas été affinés non plus.

Alors qu'est-ce que l'on voit dans cette vidéo ?

- un son ambiant de pluie qui tombe pour le printemps (bon certes on est dans une map de test donc y'a pas les effets de pluie... mais laissez libre cours à votre imagination)

- un "crossfade" lors du changement de saison de printemps à automne

- le "crossfade" laisse place à un son ambiant d'automne (qui serait plutôt un son ambiant pour l'été mais bon... faut pas trop en demander à un programmeur, en général ça connait pas les saisons parce que ça sort pas très souvent).

- le moulin se met à tourner en automne, on vous laisse deviner pourquoi (y'a un indice sonore avec un son spatial). Le moulin émet également un son spatial de couinement.

- le son spatial de couinement du moulin s'atténue lorsque le renard s'en éloigne, et redevient plus audible lorsque le renard est à proximité. Ne cherchez pas l'effet stéréo, la vidéo est encodée en mono !

- lorsque le renard marche, on entend un bruit de pas générique synchronisé sur son animation.

- le renard passe à travers une porte pour atteindre un autre niveau. C'est l'occasion d'un nouveau "crossfade" sonore. Ce nouveau niveau possède un son d'ambiance caverneux. 

Les backstages : Blender !

Les plus curieux peuvent se demander comment sont joués les sons. Est-ce un script spécial qui lance les sons au cas par cas ? Ou est-ce un procédé plus ou moins automatisé.

Nous avons choisi d'automatiser au maximum la gestion des sons. Pour se faire, regardons comment le son de couinement du moulin est paramétré dans l'outil favoris de William : Blender !

 

Cas du moulin

Dans le cadrant haut-gauche de l'image se trouve la scène visuelle où a été placé une enceinte rouge qui est un objet invisible au final mais qui nous permet de positionner le son.

Blender ne gérant pas les sons, nous avons créé un composant permettant d'indiquer que l'enceinte rouge doit être considérée comme la source émettrice d'un son. Ce composant se nomme "SSSSound" et est visible dans la partie bas de l'écran.
On retrouve dans ce composant des paramètres qui indiquent entre autres que le son est spatial, que sa portée maximale est de 8 mètres et qu'il est parfaitement audible quand on est à 4 mètres ou moins de l'émetteur.

Le son ne doit pas être joué directement, car le moulin n'est pas obligatoirement en mouvement. Il nous fallait donc rajouter dans Blender un élément permettant de déclencher/arrêter des sons. Cet ajout a pris la forme d'un nouveau bloc de séquence visible sur la partie droite de l'image (rectangle vert).
Ce "Trigger Area" va démarrer un son si une animation est jouée dans un intervalle donné (ici l'intervalle fait la largeur de toute l'animation).
A l'inverse, le "Trigger Area" va stopper un son alors en lecture si l'animation vient à s'arrêter.

Le son déclenché par un "Trigger Area" est forcément un son joué en boucle. Pour les sons joués une seul fois de temps en temps, nous avons intégré un autre bloc de séquence...

 

Cas du renard

Le renard, lorsqu'il marche, émet des petits sons de pas. Ces sons non bouclés vont être joués par le bloc de séquence "Trigger Start".

On retrouve la même configuration de fenêtre Blender que dans le cas du moulin. Mais cette fois-ci, le séquenceur de la partie droite possède 2 séquences dites de "Trigger Start" qui sont là pour lancer des sons non bouclés (en l'occurrence des bruits de pas).

Pour bruiter la marche du renard, il suffit de faire avancer l'animation aux endroits voulus (en général quand un pied prend appuie sur le sol). De là on rajoute une séquence "Trigger Start". L'important dans ce type de séquence, c'est l'endroit où elle démarre. En effet, dès que l'animation "rentre" dans le trigger, alors le son non bouclé est joué. Contrairement au type de séquence précédant, on se moque de la longueur visuelle de la séquence, le son étant déclenché à chaque fois que le temps de l'animation (représenté par un trait transversal et vertical vert foncé dans la partie droite de l'image) rencontre un bloc de séquence "Trigger Start".
Dans le cas présent, à chaque boucle d'animation, 2 sons sont joués.

 

Conclusion

Le système embryonnaire actuel va bientôt pouvoir être utilisé par William (qui trépigne d'impatience à l'idée, je le sens !).

Il reste cependant pas mal d'améliorations à apporter, comme une intégration plus correcte du "pan" (répartition gauche/droite) pour les sons spatiaux. Les sons spatiaux auront certainement aussi besoin de zones d'atténuations non circulaires. Par exemple une forme de capsules comme suit :

 

Avec une forme de capsule pour la zone d'action des sons spatiaux, on pourrait donner plus de verticalité ou d'horizontalité aux sons. Nous allons voir si les cercles actuels suffisent en testant les sons sur de vraies niveaux et en s'appliquant sur le paramétrage des sons.

Voilà, c'est à peu près tout pour ce post un peu technique (et potentiellement chiant). N'hésitez pas à réagir dans les commentaires si vous voulez plus de précisions sur certains points ou que vous voulez partager votre expérience sur la question avec nous.

Pour ma part, n'ayant jamais touché à de la programmation sonore auparavant, je pense que certains ici auront beaucoup à m'apprendre, donc n'hésitez pas !

Guillaume

Ajouter à mes favoris Commenter (24)

Signaler
Seasons after Fall

Salut tout le monde,

Ca y est, le Festival du Jeu Vidéo est terminé et nos yeux piquent de moins en moins, il est donc grand temps de faire un récapitulatif de notre expérience FJV avec vous.

Mercredi : grand départ

Tout commence par une nuit blanche pour régler grossièrement les derniers trucs qui ne fonctionnaient pas encore dans la démo. Lorsque le soleil se lève, on se dit qu'il est temps de faire des backups et autres transferts sur ce qui nous servira de PC de fortune : mon Mac mini.

Buster, lui, pète la forme et veut prendre ma place (comme à chaque fois que je me lève de ma chaise d'ailleurs)

On décide de laisser nos tapis verts achetés à Ikea car ils ne sont pas ignifugés (donc interdits sur le salon). On part donc avec le strict minimum, c'est-à-dire des cartes souvenir, un écran, quelques cadres photos et des imprimés du logo SSS.

Le reste de la journée n'est que comatage dans le TGV, acclimatation aux températures parisiennes (je suis parti en short, ahah), une intéressante discussion jeux vidéo chez l'hôte de William qui bosse chez QuanticDream, et une reconnaissance des lieux Porte de Versailles en fin de journée.

Jeudi : installation du stand

Lors de notre arrivée le jeudi matin, voilà à quoi ressemble notre stand :

On regrette un peu nos tapis vert Ikea, il faudra se contenter du bleu imposé ! On rencontre par la même occasion nos voisins de salon : les moddeurs de C&C Stargate Universe qui ont l'air d'avoir pas mal d'expérience avec les stands. Ils nous filent pleins de tuyaux avant qu'on aille faire nos emplettes.

Après avoir fait du shopping tout le jeudi matin, on s'active tel des MacGyver et on trouve le scotch double face vraiment très pratique. Quelques minutes plus tard, voilà à quoi ressemble le stand : 

Le reste de l'après midi, on le passe à finir la démo... parce que la scène finale n'est pas encore faite ! On le savait en partant et on se disait "c'est bon, on aura tout le jeudi pour le faire"... sauf que la journée touche à sa fin et le bruit ambiant du montage des plus gros stands voisins n'aide pas beaucoup. Finalement, on simplifie la scène pour pouvoir la boucler avant 19h00, heure à laquelle nous devons quitter les lieux. 

Vendredi/Samedi/Dimanche : rencontres

> Vendredi

Le vendredi matin, c'est le ventre noué que nous nous retrouvons à Porte de Versailles. Va-t-il y avoir du monde ? Les gens ne vont-ils pas trouver notre stand trop désuet ? Le jeu trop pourri ? Le doute nous envahit quelque peu (en fait le doute s'est installé depuis notre aller en train du mercredi).

10h00 sonne le glas,  une voix suave annonce l'ouverture du salon aux visiteurs. Les premières minutes se font longues : personne. Heureusement quelques minutes plus tard William accueille nos premiers visiteurs.

La journée se passe sans difficultés, on enchaine tranquillement les visites. Les gens paraissent intéressés. Je profite d'un moment d'accalmie pour immortaliser l'instant. J'en avais oublié que j'avais amené un appareil photo !

Cette journée du vendredi fut l'occasion de discuter longuement avec nos amis (jusque là virtuels) développeurs : Alain et Mickaël du studio Alkemi, Brice de One Life Remains. On discute aussi avec des visiteurs aussi bien intéressés de parler de nos jeux que du monde du jeu vidéo et de l'industrie en générale. Bref, nous voilà rassurés.

Pix'n Love est juste à côté alors on en profite pour compléter notre collection et leur passer le bonjour.

On profite également de cette première journée pour faire plus ample connaissance avec les autres stands tenus par des personnes virtuellement rencontrées sur le forum Dijiko : MarcMayto (Curious Planet) ou encore Alex, Benjamin et Colin de chez Galhmac (des nîmois !).

Le soir, je rejoins Brice (One Life Remains) pour la cérémonie des Milthon et on assiste aux triomphes d'Heavy Rain et de Limbo. Je suis agréablement surpris par la présence de tous les primés !

 

> Samedi : le climax

Au sortir du vendredi, on s'était dit que ça resterait sûrement la meilleure journée du salon... c'était sans compter sur le samedi !

En effet, les allées étaient bien plus chargées que la veille, notre stand aussi, mais les gens qui s'arrêtaient étaient toujours aussi posés et intéressants. 

Nous avons reçu pas mal de Gamebloggers qui se reconnaitront. Parmi eux, on peut citer Enimal, Oxydam, Eldaryze, ACR, Jimmy de Punchers, Krystalwarrior, Videogameur, Garett, TinyToonyCanisquare, hairaz, Morphine, et j'en passe. Je me rends compte durant cette journée que je dispose d'une mémoire de poisson rouge, j'ai l'impression de ne pas retenir les noms, je n'ai pourtant pris aucune drogue. Bref, c'était vraiment bien de pouvoir enfin mettre des visages sur des avatars !

J'en profite pour capturer une brochette de GBloggers :

 

Même JulienC nous fait l'honneur de sa présence et pose entre deux développeurs à forte pilosité (Jimmy et moi) :

On n'oubliera pas de mentionner le passage de membres d'autres communautés : NoFrag, CanardPC, Factornews... impossible de tous les citer individuellement !

Divide nous fait même la gentillesse d'un petit montage vidéo mettant en avant Seasons ainsi que d'autres jeux du salon.

 

Des étudiants viennent nous voir et entonnent "We all live in a yellow submarine", d'autres connaissances passent aussi à leur tour (Lina, la coloc de William : une investisseur de SSS !, Marc, Channie, Marla, Stanislas d'AGO Games... comment tous les citer encore une fois ?). Sans oublier nos amis Frédéric et Johan du studio Le Cortex, mais aussi Alexis. La devanture du stand devient un petit endroit où l'on discute entre passionnés... et il n'y a pas forcément quelqu'un pour jouer à la démo pendant ce temps :

Plus tard, Enimal, certainement notre lecteur le plus furieux, nous offre à chacun ce que qu'on pourrait appeler un Gameboy & Watch porte clé estampillé Donkey Kong Junior (merci encore !). 

 

Le soir venu, une visite qui nous touche particulièrement William et moi : celle de Fabien Delpiano, du studio Pastagames. Un studio auquel on voudrait bien ressembler un jour, un studio dont la créativité nous inspire. Ses encouragements après avoir joué à la démo nous font oublier la fatigue et nous motivent plus que jamais. 

 

> Dimanche : on fait rien, comme des gros manches

Enfin si, mais dimanche s'avère plus calme que Samedi. Pas mal d'enfants viennent jouer sous le regard de leurs parents.

Le stand est plus calme donc j'en profite pour aller tirer le portrait d'un autre blog Vip de GB, les Pix'n Lovers :

Alexis Blanchet (auteur des Pixels à Hollywood), viendra clôturer les sessions de jeu sur Seasons (sous l'oeil aguerri de Benjamin de Galhmac) et nous faire part de son avis. Grand merci à lui !

 

Comment conclure ?

Ces quelques jours au FJV resteront à coup sûr dans les mémoires de SSS. On ne s'attendait pas à ça, vraiment. On était à milles lieux de s'imaginer qu'on parlerait avec autant de gens tous plus intéressants les uns que les autres !

On a pu playtester le jeu, voir ce qui n'allait pas. Confronter les joueurs avec l'aspect graphique du jeu et son gameplay.

Au niveau humain, on a établit des liens avec pas mal de personnes avec lesquelles on espère bien rester en contact.

Et pour ceux qu'on a oublié (il y en a), faites nous donc le plaisir de nous bitcher dans les commentaires !

Bref, vous étiez ENORMES !!!

 

Guillaume

Retrouvez l'intégralité des photos prises lors de cet événement sur notre picasa

Ajouter à mes favoris Commenter (41)

Signaler
Seasons after Fall

Soyez les bienvenus dans cet article, humains.

Je suis Buster, directeur marketing de Swing Swing Submarine, mais vous pouvez m'appeller "Patron".
Ne vous inquiétez pas, Guillaume et William ne sont pas morts (pas encore) mais ils sont cependant très occupés. Tellement occupés qu'ils n'ont pas pris le temps de rédiger leur rapport hedbomadaire sur le développement de la démo de Seasons qui, je le rappelle, sera jouable la semaine prochaine lors du Festival du Jeu Vidéo.

(Tiens, je me mangerai bien une croquette moi...)

Euh, qu'est-ce que je disais déjà ? Ah oui !
Etant un grand professionel (contrairement aux deux autres),je vais le faire moi-même le rapport. Mais je vous préviens : je mets plein d'images mais pas beaucoup de texte. Pas envie de ruiner mes griffes sur cet espèce de truc que vous appelez "un clavier".

Pour commencer, la partie de Guillaume.
PROGRAMMATION

> Refonte de la caméra (comportement et fonctionnalité comme projection/dé-projection)

Guillaume a fait mumuse avec la caméra en y ajoutant un système de contraintes sur le ciblage. Vous pouvez voir deux cercles verts sur l'image. Un cercle représente la contrainte, et l'autre c'est le ciblage de la caméra. Le ciblage essaie de rejoindre la contrainte. Ça semble amusant comme jeu, mais je préfère jouer avec mes balles de tissu.

Guillaume dit que "c'est trop la merde" d'obtenir un comportement de caméra décent...

... Surtout quand le machin orange tombe de haut. Là, il doit y'avoir une douceur de déplacement alliée à une rapidité pour que vos yeux d'humains puissent voir où la chute a lieu.

 

> Effet de fondu entre les niveaux

Maintenant on peut aller d'un niveau à l'autre (en l'occurrence ici du niveau "rose" vers le niveau "orange") sans se payer un méchant "cut" comme transition. A la place, on a un fondu au noir. Guillaume est content parce qu'il peut faire plein de trucs pendant cet écran noir, comme charger des objets ou initialiser des scripts. 

Ça me sauve les yeux parce qu'ils avaient tendance à saigner à chaque fois que je les regardais changer de niveau.

 

> Intégration de la librairie "vectormathlibrary" de Sony

Maintenant Guillaume peut écrire des choses comme ci-dessus grâce à la librairie OpenSource de Sony. Avant, il faisait tout lui même avec sa "librairie tambouille". Comme c'est un piètre programmeur, sa "librairie tambouille" était si peu cool qu'il ne pouvait pas utiliser les extensions SIMD (SSE par exemple) pour faire des calculs mathématiques. Maintenant il peut.

 

> Gameplay

- trous génériques

- scripts génériques de déverrouillage, pour débloquer divers éléments de gameplay

- quelques modifications de scripts pour qu'ils soient dans un état cohérent lorsque la saison a changé hors du niveau où se trouve les dits scripts

 

> Autres trucs

- synchronisation des niveaux et transfert d'objets lorsqu'on passe d'un niveau à l'autre (pendant la fameuse transition noire)

- mise à l'échelle (autre que 1/1) disponible pour les objets créés par l'intermédiaire d'un script

- quelques fuites mémoires réparées

 

Et la partie de William.
GD / LD / ART

La moitié des écrans sont finis autant du point de vue gameplay que du point de vue de l'habillage graphique ! Enfin, William a encore pas mal de boulot à faire sur l'autre moitié, sans compter qu'il doit terminer les animations des personnages (oui, DES personnages).

L'écran #1 et la neige qui tombe. Logique, c'est l'hiver.

 

L'écran #5 sous la pluie.

Un arbre dans une grotte ? Oh, ne me remerciez pas : remerciez plutôt le soleil.

William, est-ce que tu te rends compte qu'il ne reste que 5 jours pour habiller l'écran #10 ?

Bon, maintenant que j'ai fait le rapport je file en vitesse : j'entends les croquettes qui m'appellent.

A pluche, mectons !

Ajouter à mes favoris Commenter (11)

Signaler
Seasons after Fall

Quoi ? Un jour de retard dans le post de l'article hebdomadaire !? Ça doit être pour marquer le fait qu'on est *légèrement* à la bourre !

Quoiqu'il en soit, il nous reste une grosse semaine pour finir ce qu'on voulait apporter à Paris pour le Festival du Jeu Vidéo. 

En plus de ça, on aimerait bien avoir fini d'assembler les éléments (éléments finaux ou "placeholders") pour la fin de semaine, afin de pouvoir faire "playtester" quelques gens (oui j'aime bien les anglicisme ou plus exactement j'ai du mal à les traduire).

Bref, je vous laisse avec le récapitulatif et je retourne programmer !

 

Côté programmation

Cette semaine, j'ai principalement écrit des scripts pour intégrer les objets conçus par William. William vous parle plus en détail des objets en question dans sa section, donc je fais l'impasse ! Mais il reste quand même quelques trucs dont je peux parler.

 

Modifications sur le système de particules

J'ai ajouté quelques effets 'à l'arrache' : la pluie (qui n'avait pas été implémentée avec la neige) et une sorte de fumée noirâtre.

Fumée, 1ère version

Pluie, 1ère version (0ème version ?)

 

Ces effets sont particulièrement non travaillés (et un peu moche, on peut le dire), mais ils feront l'affaire pour la démo.

J'ai aussi modifié l'effet de vent. Maintenant l'effet peut produire plusieurs trainées pour accentuer l'effet et le rendre plus visible.

Amélioration vent

 

Intégration gameplay

J'ai implémenté des scripts durant la majeure partie de la semaine. Le fichier où j'écris toutes les implémentations des scripts commence à être gros puisqu'il a passé les 4000 lignes cette semaine. J'aurais du faire un fichier par implémentation de script, mais j'ai eu trop la flemme pour ça. Le fichier est bien aéré quand même et les quelques 20 classes implémentées ne sont pas trop illisibles.

Sinon, à part ces anecdotes pourries, la chose la plus amusante que j'ai codé cette semaine est un script pour les lumières. Je ne révèlerai pas les tenants et aboutissants de l'utilisation des lumières dans le jeu (je laisse votre imagination travailler). A la place, voici juste une séquence d'images pour illustrer.

Lumière scriptée

 

Bug marrant

Le bug le plus marrant que nous ayons rencontré cette semaine est un bug de filtrage de texture. Voici le problème visuellement parlant présenté dans l'image suivante (à gauche c'est une fois corrigé, à droite c'est quand c'est cassé) :

Filtrage OK (gauche) / filtrage KO (droite)

On utilise le format Png pour les textures. C'est peut être une erreur, peut être aurions nous du choisir autre chose, mais le Png supporte la transparence et fait des fichiers plutôt petit sur le disque.

Le problème de traces blanches sur l'arbre à droite de l'image précédente provient du fait que l'exporteur Png de Photoshop ne prend pas en compte les canaux alpha personnalisés et modifie également les couleurs des pixels qui sont censés être transparent s(alpha = 0).

Voici l'exemple par l'image avec la texture de notre arbre. De gauche à droite : le canal alpha personnalisé que l'on veut, les canaux de couleurs RGB que l'on souhaite voir exporté dans le Png, les canaux de couleurs RGB réellement exportés par Photoshop Png Exporter, et le résultat final dans les deux cas.

Masque alpha / canaux RGB voulus / canaux RGB exporté / résultat du masque

Alors, pourquoi ces trainées blanches apparaissent ?

Et bien car les canaux de couleurs RGB ne sont pas conservés lors de l'export, et Photoshop les réécrit comme il lui semble avec des assemblages de rectangles. Dès lors, dans le moteur de jeu, lorsque l'on affiche une texture, celle-ci est filtrée. Qui dit filtrage dit que l'on prend plusieurs pixels de l'image et qu'on en fait une moyenne. Or les pixel visibles en bordure du masque alpha vont aller se mélanger (se filtrer) avec des pixels blancs non visibles car contenus sous le masque alpha (où l'alpha indique une transparence totale). D'où la présence des trainées blanches. Alors que si nos canaux RGB étaient pris en compte, les pixels en bordure seraient filtrés avec des pixels non visibles ayant une couleur similaire à eux.

Pour résoudre le problème, on aurait pu changer de format de fichier pour un format incluant un canal alpha customisé, avec les formats TGA ou DDS, mais on a comme qui dirait pas le temps pour ça tout de suite.

Dès lors notre ami google nous donne une solution sur les forums de Torque, avec un plugin d'export SuperPng qui écrit bien les canaux RBG que nous voulons dans le fichier Png. (lien direct pour les intéressés).

-----

Côté GD / LD / ART

> Art

Et une nouvelle semaine dédiée à l'animation ! Avec cette fois-ci un programme plutôt varié : champignons, moulins à vent, geysers et sapins. J'ai également posé le sol et une ébauche de background dans les écrans de type "grotte".

Chacun de ces objets est intéractif et possède un comportement unique lié aux saisons. Il est facile d'imaginer le fonctionnement du moulin à vent, mais qu'en est-il des champignons et des sapins ? Pour l'instant, je vous laisse deviner.


Concept animé du champignon et son comportement

Trouver un design satisfaisant pour les champignons s'est avéré relativement difficile. Je n'avais en fait aucune idée de la forme que je voulais leur donner.
Au départ, l'idée a été de faire un seul champignon, suffisamment gros pour permettre au renard de sauter dessus, mais il me semblait que ça lui donnait un aspect un peu trop fantasy / conte de fée. D'autant qu'avec son chapeau rond et  ses points colorés le champignon était vraiment trop caricatural.


Premier design

En consultant mes bouquins de référence sur les champignons, je trouvais qu'un chapeau plus plat serait déjà plus joli, mais ça ne changeait pas le fait qu'on aurait eu un seul et unique champignon là où au contraire je souhaitais plus de vie !

Donc j'ai pris un crayon et j'ai gribouillé, encore et encore, pour finalement obtenir...plein de champignons. Un bouquet de champignons !


Design pour la démo

Ca m'a bien plu, alors je suis passé à Blender (encore et toujours) pour animer tout ça. Les gros champignons au centre m'ont pris 2 heures à animer, mais c'est complètement ma faute. J'ai pinaillé et voulu mettre trop de détails dans l'animation (détails qui finalement sont imperceptibles). Quand j'ai commencé à réalisé que  ce n'était pas très efficace, j'ai décidé de procéder de manière plus simple pour les petits, et ça a marché ! C'est bon à savoir pour la suite, quand je devrais refaire les champignons pour la version finale du jeu.


Animé dans Blender

Car oui, tous les objets que nous créons aujourd'hui sont d'abord destinés à la démo. En les créant dans un temps aussi réduit, nous apprenons énormément et nous serons donc plus efficaces à l'avenir. Comme on dit chez nous : c'est en forgeant qu'on devient forgeron.

> Level Design

Pas grand-chose à dire sur le LD cette semaine, si ce n'est que j'ai du faire quelques ajustements dans les écrans 05, 10 et 11 de sorte qu'on ait suffisamment de place pour poser les moulins dans le monde. L'écran 11 est toujours un peu bancal : il faudra que je le repense une nouvelle fois afin de le rendre plus intéressant. Et si je n'y arrive pas, il finira par être écarté de la démo.

Ajouter à mes favoris Commenter (15)

Signaler
Seasons after Fall

Il nous reste moins d'un mois pour finir la démo donc pas de temps à perdre : voici la troisième semaine de notre compte-rendu sur le développement de la démo Seasons pour le Festival du Jeu Vidéo !

Côté programmation

Vibrations

Comme nous n'aurons pas de partie sonore dans la démo présentée à Paris en Septembre (c'était prévu comme ça, mais oui ça craint), on s'est dit qu'il fallait trouver un autre moyen de donner des feedbacks au joueur.
J'ai donc pensé qu'intégrer le support des vibrations de la manette (XBox) ne serait pas un mal.

Nous avons 2 types de vibrations possible :

- Les vibrations générées grâce à du code moteur. Le tout relié à la machine à états du renard pour savoir quand les déclencher. Par exemple, si le renard fait une chute plus ou moins haute, on déclenche une vibration plus ou moins longue de la manette.

On trouve ci-dessous un schéma partiel de la machine à états finie (FMS/Finite State Machine) qui gère les mouvements et animations du renard. Le point noir indique l'état initial du renard (en l'occurrence ici "Standing", soit immobile). Les divers états sont représentés par des rectangles aux coins arrondis. Les flèches entre les états sont des transitions et elles ne sont valides que si la condition textuelle attachée est valide.
Le commentaire en forme de post-it indique l'endroit où nous intercallons la gestion des vibrations dans le cas d'une chute.



Machine à états finie partielle


- Les vibrations animées

Quand nous animons des objets, on aimerait parfois associer des vibrations à certains moments de l'animation. Au lieu de gérer ces vibrations avec du code côté moteur, j'ai décidé de réutiliser les bons vieux Path intégrés la semaine dernière pour y raccorder les vibrations.
Un exemple valant mieux qu'un long discours, on trouve ci-dessous une scène mettant en avant l'animation d'un objet rouge qui tombe sur le côté (oui, j'aime bien faire des scènes abstraites de programmeur), illustrant l'utilisation des "vibrations animées" :


Vibration et animation

Les vibrations ne sont cependant pas jouées automatiquement avec l'animation. C'est un script qui autorise ou non les vibrations de se jouer. Car si d'autres vibrations plus importantes sont en cours de diffusion par d'autres objets (objets qui peuvent être plus proches du renard, par exemple), alors on doit annuler ou atténuer les potentielles nouvelles vibrations.

Secousses caméra

Pour accompagner les vibrations, j'ai implémenté un système de secousses très simple se résumant à secouer la caméra en X et Y selon une amplitude, une atténuation et une durée. Ces secousses sont accessibles depuis les scripts et peuvent être déclenchées, par exemple, lorsque la manette se met à vibrer au delà d'une limite, ou lors d'un évènement tout autre.
Pour l'instant, je n'ai pas relié les fameux Paths aux secousses caméra, mais peut-être en aurons nous besoin plus tard.

Script gameplay

J'ai passé la majeure partie de la semaine à implémenter des scripts pour donner vie aux objets (animés pour la plupart) conçus par William. J'ai aussi fait quelques scripts génériques pour d'autres objets qui seront créés sous peu (j'ai donc pu exprimer ma créativité en terme de conception de niveau à base d'objets carrés et rouges).

Je ne voudrais pas spoiler trop le contenu de la démo, alors je vais me contenter de 4 captures d'écrans non commentées issues de quelques scripts implémentés cette semaine. A vous de deviner de quoi il s'agit.


Divers scripts gameplay

Côté LD/GD/ART

Cette semaine a été dédié au travail d'animation.
Je me répète, mais comme je ne suis pas très bon dessinateur il est parfois frustrant pour moi de ne dessiner que ce que je peux et non ce que je veux. En animation, pourtant, j'ai l'impression de pouvoir créer ce qui me plait (avec du temps) et du coup j'aime beaucoup animer des trucs et des machins. L'avantage de notre "direction artistique" à base d'aplats de couleur, c'est qu'en cas de difficultés je peux un peu m'arranger comme je veux et tricher sur les formes que j'anime.

J'ai principalement travaillé sur 4 éléments de décors intéractifs : un arbre qui tombe, un arbre penché, un arbre qui pousse et une structure plus humaine dont je ne peux vous expliquer le fonctionnement exact sans vous spoiler une partie de la démo. Ceci dit, ce n'est pas trop difficile de deviner quelle est cet élément de décor, n'est-ce pas ?


Que de mystère !

L'arbre qui pousse étant le plus intéressant des 3 arbres cités plus haut, c'est de lui que je vais vous parler plus en détails.

Peut-être avez-vous déjà vu un arbre qui pousse dans une de nos vidéos précédemment postées : le bac à sable du programmeur.
A l'origine, cet arbre a été conçu pour notre renard précédent qui était plus grand et surtout qui sauter plus haut que le petit renard actuel. La branche de cet arbre était à 3 mètres du sol, et notre petit renard ne saute qu'àune hauteur d'1,5 mètre.

Ma pemière idée était de prendre l'arbre déjà existant, avec une seule branche, et de placer un rocher en dessous de sorte que le renard puisse sauter sur le rocher et atteindre ensuite la branche. Le soucis, c'est que le joueur peut planter et faire pousser ce type d'arbre, et placer un rocher près de chaque zone où le joueur peut faire pousser un arbre ne serait franchement pas subtil...

La deuxième idée aurait pu être, toujours avec le même arbre, de deplacer la branche vers le bas, mais alors le résultat esthétique ne serait pas naturel. De plus, je commence à détester de plus en plus l'aspect de cet arbre, bien trop simple et trop carré.

Au final, donc, la meilleur chose à faire était de créer un nouvel arbre, avec deux branches et des lignes plus organiques. La démo ne possédera qu'un type d'arbre à faire pousser mais il y en aura plusieurs dans le jeu final, bien entendu.


Tailles d'arbres et hauteurs de branches

Nous n'avons pas le temps de vous faire une vidéo des éléments animés, désolé.
Il reste encore plein de travail donc on s'arrête là pour l'instant et on retourne à Blender.
A la semaine prochaine !

Ajouter à mes favoris Commenter (14)

Signaler
Seasons after Fall

Salut,

Nous revoilà pour la 2ème semaine de récapitulatifs des travaux effectués sur la démo de Seasons qui sera jouable sur notre stand lors du prochain Festival du Jeu Vidéo.

Côté Programmation

Path (chemin)

La semaine a commencé par l'implémentation du support des "Path" de Blender dans le moteur du jeu.

Un Path est une courbe positionnée dans un espace 3D que l'on peut parcourir grâce à l'utilisation d'une autre courbe dite paramétrique (en l'occurrence on l'appellera courbe de vitesse).

Exemple depuis Blender :


Path (gauche) et courbe paramétrique de parcours (droite)


Sur la gauche, dans la vue 3D, un Path est positionné, ainsi qu'un cube suivant ce Path.

A droite, on aperçoit une autre courbe, la fameuse courbe paramétrique "speed" pour parcourir le Path. Cette courbe est modifiable par nos soins (tout comme celle du Path), et dans le cas présent elle nous indique que tout objet suivant le Path va le parcourir entièrement entre les images 1 et 100 de l'animation, puis revenir sur ses pas jusqu'au milieu du Path entre les images 100 et 150 de l'animation, pour finir par repartir vers la fin du Path entre les images 150 et 250 de l'animation.

Cette courbe de "speed" permet aussi de gérer l'accélération des objets en fonction de la courbure qu'on lui donne.

Les Paths vont nous être très utiles dans le jeu car on va pouvoir accrocher toute sorte de chose dessus : des objets visuels, des effets ou encore la caméra (pour faire des cinématiques).

Émetteurs de particules

Jusqu'à présent, nous n'avions pas d'effet de particules dans le moteur. Cette semaine fut l'occasion d'implémenter un système embryonnaire. On a donc 2 types d'émetteur de particules à l'heure actuelle :

- Trail (trainée)


Les trainées vont utiliser les Paths présentés au paragraphe précédent pour faire apparaitre des effets longiligne. Petit exemple d'une map de test (désolé pas le temps de faire des vidéos pour le moment) :


Une particule de type trainée au cours du temps


- Spawn (soit l'émetteur de particules classique)


L'émetteur de particules le plus courant est un émetteur qui va créer des particules de tailles, de vitesses, de durées de vie, et de positions de départ diverses (et un peu aléatoires) pour générer des effets comme de la pluie ou de la neige.

Chaque effet demande un réglage des paramètres (avec un peu d'aléatoires dedans). Avec la neige, la taille des particules est plutôt grande et la vitesse lente, alors que pour de la pluie ce serait plutôt l'inverse : une taille étroite et une vitesse élevée.

Voici quelques tests préliminaires avec un seul plan de particules :



Divers tests de particules (de gauche à droite : statique, forte vitesse vers le sud-ouest, vitesse lente vers le nord et fade avant la mort de la particule)

Pour qu'un effet de pluie ou de neige reste toujours à l'écran, il faut que l'émetteur de particules bouge avec la caméra et qu'il émette des particules sur une largeur assez importante pour couvrir tout l'écran. On a donc deux types d'émetteurs : 'local' ou 'full screen'.

Si on se contente de bouger un émetteur 'local', on va rencontrer quelques problèmes de "trous", des endroits où il n'y aura pas de particule à l'écran. Ceci car les particules nouvellement créées le seront dans un rectangle de la taille de l'écran mais rien ne garantit que les particules apparaitront sur le bord de l'écran (dans la direction où nous allons) ou en plein milieu.

Pour palier à ce problème, on déplace les particules vivantes qui viennent de sortir d'un côté de l'écran pour les remettre de l'autre côté. On effectue alors du "Wrapping" de particules, uniquement pour les émetteurs 'full screen'.

Exemple en image :


Wrap de particules pour couvrir l'écran en permanence

Les particules sont colorées en fonction de la position où elles sont nées pour mettre en évidence le phénomène. Ainsi on voit que les bords gauche/droit de l'écran ont des particules de même couleurs car certaines particules ont été déplacées de la droite de l'écran vers la gauche. Elles poursuivront leur périple jusqu'à ce qu'elles meurent.

Voici ce que donne la neige dans le décor neigeux de la semaine dernière :


It's snowing men!

Il reste encore des réglages à faire, mais l'effet est pas trop mal pour un premier jet. On reviendra dessus plus tard quand tous les éléments de gameplay seront implémentés.

Les restes

D'autres choses en vrac :

Écriture d'un script générique pour effectuer des déplacements de caméra lorsque le renard entre dans certaines zones (en utilisant les Paths fraichement disponibles :)).

Correction de quelques bugs (vitesses de déroulements des timelines d'animation qui ne concordaient pas entre le moteur et Blender, rotation en Z des instances de prefabs ne marchait pas).


Côté LD/GD/Art

Graphisme :

Après avoir travaillé à la première passe d'habillage des premiers écrans de jeu, mon cerveau de non-graphiste n'arrivant pas parfaitement à imaginer chaque ambiance, couleur et élément de décor, j'ai senti qu'il était préférable de revenir à un travail papier. C'est pourquoi j'ai imprimé l'ensemble des maps de collisions afin de pouvoir gribouiller dessus.

Certains dessins ont été scannés puis colorisés afin de mieux me rendre compte du travail à accomplir ensuite, et puis aussi un peu pour me rassurer.
Une fois mes doutes dissipés, je suis revenu à la création d'assets, dont une cascade qui ondule magnifiquement ses vertex à l'écran.


Du gribouillis à la colorisation


Intégration de la cascade animée in game


Level Design :

En imprimant les maps de collision, je me suis aperçu que certaines sections de jeux devaient être ajoutées et (beaucoup) d'autres déplacées. Les écrans 10 et 11 (les plus bancals) ont été totalement réagencés de sorte que la succession d'obstacles proposée soit plus naturelle, force le changement des saisons et surtout aide au bon apprentissage des différents éléments de jeu.


Modification LD après tests

Ajouter à mes favoris Commenter (9)

Signaler
Seasons after Fall

Salut tout le monde,

Comme vous le savez, nous participerons au Festival du Jeu Vidéo qui se tiendra les 10, 11 et 12 Septembre à Paris pour y présenter une démo jouable de Seasons.

Aucun moyen de repousser la deadline : le compte à rebours est à présent enclenché !
Semaine après semaine, nous vous proposons de suivre nos préparatifs et l'avancée des travaux effectués (sans trop vous spoiler non plus).

 

Côté Programmation

Nouvelles fonctionnalités :

Un nouvel element de gameplay codé faisant intervenir un élément naturel que l'on trouve dans une certaine saison. Je suis pas sympa donc je ne dévoilerai pas cet élément :)  

Première intégrations des lumières, on peut maintenant avoir des niveaux plus ou moins sombres, et on peut donner une couleur ambiante à une partie de l'environement. Pour le moment on éclaire tout ce qui se positionne derrière la lumière mais j'ai les informations d'atténuation dans un buffer, prêtes à l'emploi.  

La lumière posée dans Blender (haut) et rendue dans le moteur (bas)

Un nouveau type de materiau pour donner une couleur différente à un objet en fonction de la saison. Ca permet d'éviter de faire des textures multiples avec pour seule différence la couleur. On utilise donc des textures en niveau de gris et une couleur vient se multiplier au niveau de gris de la texture.

La superbe interface Blender pour configurer le materiau (haut) et le résultat ingame


     Correction de bug :

      Plus William utilise Blender et le moteur, plus il trouve de bugs, parmi les plus gênants:
      - mauvais tri des surfaces avec de la transparence
      - nouvelle fonctionnalité == nouveaux bugs... les "multi color material" ne dérogent pas à la règle... en buguant les anciens matériaux

    La nouvelle discipline olympique : le combiné de bugs (mauvais tri + un matériau qui ne devait pas utiliser le multi coleur + un problème de filtrage de texture)


Côté LD/GD/Art

Level design :

On estime la durée moyenne de la démo à 15 minutes environ, le temps nécessaire pour que vous puissiez voir un maximum de choses de Seasons sans pour autant passer votre après-midi sur le stand Swing Swing Submarine.
La démo comprend donc 4 environnements différents pour 12 écrans de jeu au total.

Mais où est donc passé le 12° écran de jeu ?

Une fois le level design couché sur le papier et les collisions posées dans Blender, il ne reste que la partie graphique à faire (c'est tout ? oh c'est rien alors).

 

Graphisme :

Je pose d'abord le sol dans Blender avant de m'attaquer aux éléments de décor les plus importants et de créer un background. A l'étape "gribouillis", on rêve encore de ce que ça va bien pouvoir donner. Mais le premier essai achevé, les étoiles dans les yeux disparaissent : c'est moche, tout blanc, on voit rien, au-secours donnez-moi un graphiste ! On déprime quelques minutes, puis on se retrousse les manches et on repart sur le champ de bataille. Au deuxième essai, ça va déjà un peu mieux. Suffisamment pour passer à un autre écran de jeu et recommencer (on fera les finitions plus tard) .

Gribouillage >> Premier essai (catastrophique) >> Deuxième essai (y'a de l'espoir)

Ajouter à mes favoris Commenter (18)

É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