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

Catégorie : Seasons after Fall

  
Signaler
Seasons after Fall (Jeu vidéo)

Salut tout le monde !

La Gamescom 2014 est terminée depuis maintenant une semaine ! Ce fut l'occasion pour nous d'aller en Allemagne avec une build de Seasons after Fall à montrer à la presse et à certains éditeurs et consoliers.

Nous montrions pour la première fois le jeu avec une scène spécialement conçue pour l'occasion, scène que l'on peut apercevoir dans ce tout premier trailer :

Cette présentation n'était pas publique, nous sommes restez dans la zone "business area" de la Gamescom. Nous avons ainsi pu pitcher le jeu et commencer à voir les réactions de nos interlocuteurs, Julo y compris !

Seasons after Fall est donc un jeu d'exploration où l'on incarne un renard sauvage évoluant dans une nature quelque peu étrange. Le renard a la faculté de changer les saisons à volonté et l'exploration se voit matinée de petites énigmes à résoudre en utilisant son pouvoir et en comprenant l'écosystème dans lequel on évolue.

Nous ne pouvons pour le moment pas annoncer officiellement de plateforme, mais notre envie est clairement d'apporter ce jeu sur une ou plusieurs console, en plus des traditionnelles versions PC.

Les premiers retours étaient plutôt encourageants, nous avons pu nous créer quelques contacts... nous verrons bien où ceux-ci nous mènent !

Le développement suit son petit bonhomme de chemin, et nous allons tenter de vous donner des nouvelles plus fréquemment sur ce blog, comme nous l'avons promis à Julo !

A tout vite !

 

Guillaume

Voir aussi

Jeux : 
Seasons After Fall
Sociétés : 
Swing Swing Submarine
Ajouter à mes favoris Commenter (2)

Signaler
Seasons after Fall

Il y a tout juste un an, nous avons été contraint de mettre entre parenthèses le développement de Seasons after Fall à cause de problèmes financiers. Certains d'entre vous commencent d'ailleurs à s'impatienter et souhaitent, tout comme nous, voir à nouveau notre renard gambader dans la campagne.

2011 a été l'année de Blocks That Matter, et une année plutôt sympa. Nous reviendrons d'ailleurs, plus tard, sur le jeu et l'accueil que lui ont réservé les joueurs et les critiques, mais il faut que vous sachiez que grâce à vous, qui avez acheté, joué et parlé de Blocks That Matter, nous pourrons continuer de créer des jeux cette année, en 2012.


Aviez-vous remarqué la présence du renard dans l'intro de Blocks That Matter ?

Et pour la première fois depuis la création de Swing Swing Submarine, il y a de cela 2 ans, nous allons pouvoir nous payer un petit quelque chose à la fin du mois de Janvier. Pas un salaire comme celui que nous avions lorsque nous travaillions dans une grosse boite, mais suffisamment pour payer le loyer, les factures et manger, ce qui est déjà énorme.

Cela signifie-t-il que nous sommes en mesure de reprendre le développement de Seasons after Fall ? Malheureusement, non. Pas encore. Nous sommes sur la bonne voie et on peut dire que la moitié du chemin a déjà été parcouru. Maintenant que nous sommes (presque) indépendants financièrement, il faut continuer sur la lancée et travailler encore un peu plus pour préparer la reprise, créer les outils nécessaires et embaucher un artiste / animateur à temps plein.

Pour arriver à ce résultat, nous estimons qu'il nous faut créer au moins un autre jeu de la taille de Blocks That Matter, en espérant bien évidemment qu'il soit aussi bien (voir mieux) accueilli par les joueurs. Ensuite, seulement, nous pourrons reprendre Seasons after Fall.

Il est donc fort probable que Seasons after Fall ne sorte pas en 2012.
Malgré cela, nous espérons que vous serez encore nombreux à nous soutenir cette année, comme vous l'avez fait la précédente, et surtout nous espérons que vous aimerez notre prochain projet. On va en tout cas essayer de faire les choses bien.

N'écoutez pas les gens qui veulent vous vendre la fin du monde.
Nous vous souhaitons à tous une vraie bonne et heureuse année, moussaillons!

Ajouter à mes favoris Commenter (13)

Signaler
Seasons after Fall

En Septembre 2009, Guillaume et moi sommes devenus développeurs indépendants à plein temps et avons commencé à travailler sur Seasons after Fall.

En Septembre 2010, le jeu était jouable dans une version très "work-in-progress" par les visiteurs du Festival du Jeu Vidéo. Deux mois plus tard, Seasons after Fall recevait le titre de "Meilleur Projet de Jeu 2011" à la Game Connection de Lyon.

Septembre 2011 verra-t-il la sortie de Seasons after Fall ?
C'est ce que nous pensions, mais quand nous avons repris le travail après les vacances de Noël, une mauvaise surprise nous attendait dans la boîte aux lettres.

Deux enveloppes : une pour Guillaume, une pour moi.
Dans ces courriers, nous apprenons que nous devrons payer des charges sociales en 2011, et pas qu'un peu (heureusement, Buster n'est pas concerné).

Payer des taxes ce n'est pas un problème quand on gagne de l'argent, c'est même "normal".
Le soucis, c'est que nous n'avons pas d'argent et que nous ne gagnons rien aujourd'hui du travail que nous faisons à Swing Swing Submarine.


Dans "Le Renard et l'Enfant", une petite fille apprend la différence entre l'amitié et l'emprisonnement.

Comme vous pouvez l'imaginer, le matin où nous avons reçu ces lettres a été assez "difficile", mais rapidement nous avons décidé que la dépression n'était pas une option envisageable.

"Tout problème a une solution, il ne sert à rien de s'inquiéter... et quand il n'y en a pas, s'inquiéter ne sert à rien."
C'est ce que le Dalai Lama aurait dit ce matin-là s'il avait fait partie de l'équipe.

Bref, le meilleur moyen de gérer cette situation était d'être aussi flexible que peut l'être un développeur indépendant et de prendre des décisions réfléchies.

Notre but est et a toujours été de faire Seasons after Fall, bien sûr, mais ce n'est pas tout à fait exact.
Notre vrai but est de faire de Seasons after Fall un bon jeu.
Malheureusement, ce "problème de charges sociales" peut nous empêcher d'atteindre ce but. Si nous ne pouvons payer ces charges aujourd'hui, nous serons rapidement contraints d'abandonner le développement indépendant à plein temps.

Plusieurs personnes nous ont conseillé de lancer un appel aux dons, mais ça n'a pour nous, aujourd'hui, pas de sens. Nous avons faits des dons à Daniel Benmergui et Terry Cavanagh quand ils avaient besoin de l'aide de la communauté indépendante, donc le principe de dons ne nous posent aucun problème. Seulement nous ne sommes pas Daniel ou Terry : nous n'avons à ce jour sorti que deux jeux flash qui se rapprochent plus de l'expérimentation que de réels jeux et nous ne ne pouvons décemment pas demander aux joueurs de nous donner de l'argent parce qu'ils ont aimé jouer à Tuper Tario Tros. ou Greek & Wicked.

Non, nous devons prendre une vraie décision, et cette décision c'est de continuer de faire des jeux.

Le développement de Seasons after Fall doit être mis entre parenthèses pendant plusieurs mois jusqu'à ce que nous ayons déposé le projet auprès du CNC (afin d'espérer pouvoir recevoir une subvention) et que nous puissions engager un animateur 2D. D'ici là, nous ne prendrons pas de vacances (comme vous pouvez le voir, la dernière fois ça ne nous a pas vraiment réussi).


" - Tu deviens responsable pour toujours de ce que tu as apprivoisé."

Depuis un mois, nous travaillons "secrètement" sur un nouveau jeu dont le développement sera bientôt achevé et sortira d'ici fin Mars. Cela signifique que dans moins de deux mois, vous pourrez jouer à un jeu Swing Swing Submarine sur votre télé et un peu plus tard sur PC.

Quel est donc ce nouveau jeu ?
Hé bien je préfère arrêter là cet article (qui commence à être long) et en ouvrir un nouveau.

Nous ne voulions pas partager ces détails avec vous avant d'avoir quelque chose de tangible à vous présenter. J'espère que vous nous pardonnerez le fait d'avoir été réticent à partager nos problèmes avec vous pendant ces dernières semaines.

Revenez donc ici demain pour en savoir plus.

Merci encore pour votre soutien et passez une excellente journée, matelots !

William

Ajouter à mes favoris Commenter (21)

Signaler
Seasons after Fall

Hein ? Quoi ? Comment ?!  Plus d'un mois sans article autour de Seasons after Fall ?

Mais que fait-on ? Que fait Buster ?

Nous avons été quelque peu occupés durant ce mois de novembre, vous découvrirez le pourquoi du comment dans de futurs posts.

Pour l'heure, laissez moi tenter de réparer ce manquement avec un article légèrement technique décrivant une fonctionnalité que nous avons fraichement ajouté à notre moteur maison : l'animation par spritesheet.

Avant de déployer mon plus beau Prout (le penchant maléfique et chiant de Proust), passons au crible quelques termes qui pourraient être utiles à la compréhension. Les gens bien au fait ou pressés peuvent directement passer la section suivante (sans passer par la case "roh mais l'autre il me prend pour qui") !

 

>> Vocabulaire

Vertex

Un vertex est un point dans l'espace tri-dimensionel. A ne pas confondre avec un Game Object (cf. le tutoriel Unity). Non, un vertex c'est l'élément de base qui sert à modéliser des objets (2D ou 3D).

Généralement, un vertex possède une position (x, y, z) ainsi qu'une couleur (rouge, vert, bleu, transparence) mais aussi des coordonnées de texture (u, v). Je passe sur les propriétés qui ne nous intéressent pas (comme la normale nx, ny, nz).

Autant d'information dans un si petit corps : le vertex !

 

Quadrilatère (Quad de son petit nom)

Un quad est un assemblage de deux triangles (je ne vous fais pas l'affront de décrire un triangle). Le tout constituant une forme parallélépipèdique. Vous l'aurez compris, un quad est composé de 4 vertices (pluriel de vertex), les 2 triangles le composant ayant un côté en commun. 

Deux triangles siamois forment un quad

 

Texture

Une texture est une image que l'on vient plaquer sur des triangles (ou des quads) pour leur donner un peu de gaieté et éviter qu'ils n'arborent une bien triste robe de couleur uniforme.

Revoici notre quad, cette fois-ci vêtu d'une texture de sous-marin (et oui, on est corporate ou on ne l'est pas !)

C'est pas la plus belle texture que vous ayez jamais vu ? Hein ? Hein ?

 

Coordonnées de texture (UV)

Les coordonnées de texture (souvent décrites comme "UV", rien à voir avec le soleil et le bronzage) sont une des propriétés des vertices. On trouve 2 coordonées : U et V (haha, je vous avais dis que ça avait rien à voir avec le bronzage).

Ces deux coordonnées indiquent un emplacement dans une texture (une sorte de coordonnée GPS dans une image), elles vont permettre à un vertex d'obtenir une couleur issue d'une texture.

La texture est alors appliquée à un triangle grâce à l'interpolation des coordonnées de textures des 3 vertices composant le triangle.

Revoici notre quad habillé pour l'hiver, mais cette fois-ci les coordonnées de textures sont différentes des précédentes et le quad arbore une sous-partie de la texture du sous-marin.

Les UV sont bien utiles pour habiller des quads comme vous le voulez

 

>> Construire une spritesheet

Préparation

Disons que nous voulons animer le personnage de Braid (Tim). Si vous voulez réaliser ça chez vous, vous trouverez les images de Tim sur le site du graphiste.

Pour obtenir un personnage animé, vous prenez un artiste 2D talentueux et vous le laissez dessiner une séquence d'images représentant le personnage en pleine action.

Voici quelques étapes issues de la course de Tim :

Uno, dos, très

Tel un animateur 2D ancestral, l'artiste dessine une étape donnée en la superposant avec une étape précédente, grâce à l'usage de calques. C'est une technique d'animation largement utilisée dans les dessins animés traditionnels impliquant une planche à dessin, un crayon, du papier calque, du scotch, une gomme et pas mal de patience :

La Chose est très à l'aise quand il s'agit d'animer

Cette technique devrait vous remémorer vos cours, pendant lesquels vous gribouilliez sur un coin de cahier de brouillon pendant de longues minutes avant de découvrir votre superbe animation 3 images par seconde à la sonnerie retentissante !

Imaginez le en mouvement, et ça éblouira votre esprit

 

Construction

Maintenant que nous avons les dessins des différentes étapes de notre animation, il est temps de construire cette fameuse "spritesheet".

Une spritesheet est simplement le rassemblement de toutes nos petites images dans une image plus grosse. Voici l'exemple de la course de Tim :

Une image pour les contenir toutes !

 

 

Vous remarquerez qu'il y a un gros espace vide en bas de l'image. C'est pas moi qui ait forcé sur le retour chariot tel un forcené, c'est juste un espace laissé vaquant dans la spritesheet. On peut facilement imaginer y insérer des images de Tim en train de bondir ou de chuter.

Dans cette spritesheet, j'ai décidé de laisser un espace régulier entre les images. On se retrouve donc avec une grille régulière d'images. 

Une grille régulière, et un espace vide (et non pas une armée de retours chariot)

 

Vous n'êtes pas forcés d'utiliser une répartition régulière, mais c'est plus facile pour gérer automatiquement la construction d'une animation. La vraie texture du jeu Braid n'utilise pas de grille régulière pour répartir les éléments. Regardez par vous-même !

C'est un peu l'anarchie

 

>> Pourquoi utiliser une spritesheet ?

Vous vous demandez surement pourquoi on s'embête à vouloir absolument rassembler toutes les petites images dans une plus grande (la spritesheet), alors que les animations de nos enfances dans les cahiers de brouillon fonctionnaient très bien avec des images séparées !

Il y a beaucoup d'avantages :

* Eviter le changement de texture :

Comme on utilise une grosse texture en contenant plusieurs petites, on réduit la nécessité de changer de textures lors du dessins 3D (ou 2D). Changer de texture lors du rendu a un coût non négligeable en terme de temps perdu. Eviter de changer de texture évite donc de perdre du temps (pour le perdre ailleurs).

* Chargement plus rapide :

C'est plus rapide de charger une grosse texture que plein de petites. On passe moins de temps à lire plein de choses différentes en utilisant des spritesheets... et on réduit par la même les temps de chargement.

* Les sprites peuvent être dimensionnées comme bon nous semble :

S'il est une chose difficile pour un graphiste, c'est bien d'avoir à redimensionner ses textures de sorte qu'elles soient d'une hauteur/largeur en puissance de 2 (32/64/128/256, etc...). Ceci pour maximiser le stockage, l'accès et la compatibilité sur un maximum de carte graphique (et vous savez comme moi qu'il y en a un paquet de différentes).

En utilisant une spritesheet, seule cette dernière nécessite d'être taillée en dimensions puissances de 2. Dès lors les sprites qui y sont inclus peuvent avoir des dimensions complètement loufoques, et tant pis si on ne remplit pas toute la spritesheet.

 

>> Animation avec une spritesheet

Pour animer un quad texturé avec une spritesheet, on opère simplement des glissements d'UV (coordonnées de texture) au cours du temps :

Elles sont pas belles et claires mes flèches moches ?

Au lieu d'aller de texture en texture (comme on irait en coin de cahier de brouillon en coin de cahier de brouillon), on habille simplement le quad avec une sous-partie de la spritesheet et on déplace cette sous-partie.

 

>> Atlas de texture/Tilemap

Un atlas de texture ou une tilemap sont des termes qui vous sont peut être déjà familiers. Ce sont des sortes de spritesheets, à la différence que ces textures ne servent pas à animer des choses, mais plutôt à bénéficier de quelques avantages des spritesheets comme la réduction du nombre de changements de textures et la rapidité de chargement.

Exemple d'une tilemap qui peut suffire à texturer un niveau entier ! (dans Pyramide, on dirait "en un !')

 

>> Notre implémentation dans Blender

Comme à notre habitude, on use et abuse des courbes Blender pour faire tout et n'importe quoi. L'animation par spritesheet ne déroge pas à la règle !

Voici Tim dans notre Blender custom :

Ah il sait plus où il est le Tim là !

 

Comme vous pouvez le constater, les courbes (une rouge, une verte) sur la partie droite de l'image sont très simples puisqu'elles prennent la forme d'un signal "carré". Elles indiquent simplement le nombre de décalages de cases que l'on doit opérer en U (rouge, horizontalement) et en V (vert, verticalement) dans la spritesheet.

Dans l'exemple, la posture prise par Tim est due au fait que la courbe rouge indique un offset de 4 et la courbe verte un offset de 1, ce qui nous renvoie à la sous-image entourée en blanc dans la mini spritesheet reportée à l'écran.

Bien entendu, on dispose d'un wizard pour construire les courbes rouge et verte automatiquement. Le wizard demande juste des informations comme le nombre d'images de l'animation, la vitesse de défilement des images ou encore le point de départ de l'animation.

 

>> Utilisation dans le jeu

Pour le moment, Seasons after Fall utilise grandement l'animation par morphing de polygones. Mais ceci peut être coûteux si trop d'éléments à l'écran sont animés de la sorte.

Si nous devons animer un champ de petits brins d'herbe, alors l'utilisation d'une spritesheet sera bien plus efficace en terme de performances que notre classique morphing de mesh.

On pense aussi à utiliser les spritesheet pour réaliser de petits tutoriels animés. Notre modèle absolu pour en la matière est l'excellentissime Machinarium. Le but étant de limiter, voire d'anéantir, toute trace de textes à l'écran et ainsi rendre le tout plus universel (non, pas Vivendi, l'autre).

 

>> Résultat in-game

Voici un petit aperçu de ce que donne notre cher Tim dans le moteur de Seasons.

J'ai rajouté dans cette scène un blob animé lui aussi grâce à une spritesheet trouvée dans un tutoriel du blog de Retro Affect (les gars derrière le très prometteur Snapshot). J'ai aussi ajouté ma touche personnelle de programmeur avec des choses de toute beauté qui vous rendront épileptique (ne me remerciez pas).

 

Comme vous pouvez le voir, ça fait un paquet de Tim en même temps. Pour éviter que ces Tim n'aient l'air de faire une marche synchronisée disgracieuse, on inculque des petits temps de décalages dans les timelines d'animation de chaque Tim.

Pour finir, on note que les éléments animés en spritesheet peuvent très bien subir des rotations et autres déplacements ou changement d'échelles (cf. les trucs qui rendent épileptique sur la droite de la scène).

Et si vous voulez voir d'autres utilisations de spritesheets, je ne saurai que trop vous conseiller d'aller faire un tour sur le très bon blog GB de krys64 (Unity inside) !

 

A la prochaine, pour de nouvelles aventures pixelisées !

Guillaume

Ajouter à mes favoris Commenter (21)

Signaler
Seasons after Fall

Parmi les quelques 391 projets soumis cette année à l'Independent Games Festival (dont on vous reparlera bientôt), vous trouverez un certain Seasons after Fall qui, pour l'occasion, s'illustre au travers d'un premier trailer :

 


Hé oui, Seasons change de nom et devient officiellement Seasons after Fall.
Un titre qui, vous le comprendrez plus tard, reflète mieux l'esprit du jeu aussi bien en terme de gameplay que d'univers.

Allez, petit rattrapage pour ceux qui découvrent le jeu aujourd'hui :

Seasons after Fall est un jeu de plateforme / puzzle 2D dans lesquel le joueur, sous les traits d'un renard sauvage, explore fôrets, rivières et campagnes en s'aidant des saisons.
A tout moment et en tout lieu, le joueur peut changer de saison et ainsi modifier son environnement : geler un lac en hiver, faire pousser des arbres en été ou encore disperser des spores et du pollen grâce au vent en automne.
Il peut également intéragir avec d'autres animaux afin qu'ils l'aident à accéder à de nouveaux lieux grâce à leurs capacités uniques.

Seasons after Fall (ah bah oui, va falloir s'habituer) sera disponible sur PC / Mac / Linux courant 2011.
Concernant un possible portage sur consoles, tout dépendra de l'intérêt des joueurs et des constructeurs.

William
Guillaume
Buster

Ajouter à mes favoris Commenter (37)

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)

É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