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 !
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.
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 !
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
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 :
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)
Les 10, 11 et 12 Septembre prochain se tiendra, Portes de Versailles à Paris, le Festival du Jeu Vidéo 2010.
L'an dernier, nous y étions passé en coup de vent simplement pour visiter, mais cette année nous serons présents sur le festival au travers d'un stand habillé aux couleurs de Seasons. En dehors du fait que vous pourrez admirer nos barbes et discuter avec nous, vous aurez, pour la première et peut-être la dernière fois avant sa sortie, la possibilité de tester Seasons, manette en main.
Et si par hasard vous passez nous faire un petit coucou, on aimerait que vous repartiez avec un petit souvenir.
Mais quoi exactement ? On vous pose la question :
Quel souvenir de votre passage sur le stand Seasons aimeriez-vous pouvoir ramener chez vous ?
On imagine bien des badges, des cartes, des stickers, mais vous avez sûrement d'autres idées et on aimerait bien savoir lesquelles.
Si la question vous inspire, laissez-nous donc un petit commentaire. :)
PS : 14 Juillet oblige, on souhaite une bonne fête à toutes les "France" et à tous les "Fetnat" !
Après les envolées lyriques et poétiques de William, voici venu le temps de parler un peu de technique. Ça va être chiant je sais, mais je vais essayer de m'attarder sur 3 points visuellement quantifiables (oui ça veut rien dire).
Passage de l'orthogonalité à la perspectivité
Le plus gros changement opéré niveau moteur est la possibilité de construire des niveaux en "vraie 3D".
Jusqu'alors les niveaux étaient constitués de calques (layers) et chaque layer possédait une vitesse de scrolling (pour obtenir un effet de parallax).
Voilà ce que cela donne si l'on visionne une map de test en vue isométrique :
Scène organisée en layers 2D
On remarque que la distance entre les layers n'a pas d'importance du fait que le jeu utilise une caméra à projection orthogonale pour afficher la scène (caméra qui ne retransmet pas la notion de perspective).
On note aussi que les arbres des différents layers ont des tailles différentes (ajustées à la main) pour justement compenser le fait que la caméra ne retranscrit pas la notion de perspective et donc d'éloignement. Les troncs des arbres n'appartiennent pas au même layer que le feuillage pour pouvoir se chevaucher dans le bon ordre (le feuillage devant le tronc).
La rivière est un objet spécial qui est un quad texturé (4 vertices) qui se déforme selon la position de la caméra.
La nouvelle approche consiste à créer la map en "vraie 3D". C'est-à-dire que le positionnement des objets a une importance car la caméra utilisée va prendre en compte la perspective. Dès lors deux objets de même taille physique auront une taille différente à l'écran si leur positionnement dans l'espace est différent.
Voilà à quoi ressemble la même map de test avec une réorganisation des objets pour être compatible avec cette approche "3D" :
Scène organisée avec une spatialisation 3D
On n'a plus vraiment de disposition en layer, de vrais objets 3D font leur apparition (l'espèce de grotte ainsi que la rivière qui est maintenant un ensemble de polygones)
Les arbres sont disposés de manière cohérente et le couple tronc/feuillage est maintenant sur un même plan.
Voici ce que donne une vue depuis la caméra du jeu, pour chacune des approches :
Scène 2D style (caméra à projection orthogonale)
Scène 3D style (caméra à projection perspective)
Chacune des approches a ses avantages et inconvénients :
Au final, notre moteur reste compatible avec les 2 méthodes, et nous pouvons utiliser l'une ou l'autre des solutions selon la complexité du décord dans lequel nous nous trouvons.
Seasons n'est pas un physics game
On a rien contre les physics games, bien au contraire, on adore les jeux de Petri Purho et autres World Of Goo. Mais dans le cas de Seasons, on ne voulait pas se retrouver a laisser le moteur physique gérer des mécaniques de gameplay.
On utilise un moteur physique (Box2D jusqu'à présent), mais on ne l'utilise que pour détecter les collisions.
Les objets que l'on place dans le moteur physique sont des objets dits "kinetics" (à ne pas confondre avec Kinect, même si l'étymologie est bien la même). Les objets "kinetics" ne sont pas animés automatiquement par le moteur physique, pour les faire bouger, notre code doit leur appliquer des forces et autres vitesses lui même. Avec une telle approche, les objets n'ont pas de gravité par défaut, c'est à notre code de lui soumettre des forces pour simuler cette gravité (il en va de même avec les frottements, rebonds, etc...).
Dans ce contexte, j'ai donc réalisé un système qui nous permet de scripter des liaisons physiques. Le meilleur exemple qu'on peut donner est celui d'un objet pivotant :
Une vidéo d'une map de programmeur (avec un Level Design qui veut rien dire)
Dans cette vidéo, un semblant de tronc d'arbre coupé voit son équilibre perturbé par un rocher de programmeur et notre renard. Cependant la puissance/vitesse de basculement est scriptée, maitrisée par notre code et non le moteur physique. On remarque aussi que si le renard saute de l'autre côté de la "balance", le rocher n'est pas propulsé dans les airs par un effet de catapultage.
On peut imaginer que le renard doive accumuler un certain nombre d'objets pour faire basculer totalement le tronc d'un côté ou d'un autre. Laisser faire cela par le moteur physique aurait été horriblement dur à paramétrer. Ne serait-ce que pour donner un poid cohérent aux objets afin qu'ils puissent inculquer assez de force dans la liaison de pivot du tronc pour que celui-ci basule plus ou moins.
On aurait aussi pu imaginer que le rocher en lui-même n'ait aucune influence sur le basculement et que seul le renard possédait cette faculté :
Une autre vidéo d'une map de programmeur (avec un Level Design qui veut toujours rien dire et un exemple très illogique aussi)
Dès lors c'est notre script qui détermine comment réagissent les éléments physiques entre eux, et non un paramétrage fastidieux (et parfois imprécis ou bancal) du moteur physique et des objets physiques qu'il manipule.
Le Post Process
Vous le savez, nous n'avons pas trop le temps ni les moyens de produire un nombre de textures incalculable pour Seasons. William a donc déniché une technique de sioux pour donner un aspect "cool" au jeu : un filtre photoshop avec une texture de bruit qui va bien.
Illustrons la construction de l'image de la news précédente :
Photoshop et sa magie interne (avec une texture de bruit de programmeur)
Le filtre Photoshop utilisé doit être reproduit in-game. Pour se faire on en vient à utiliser des effets de post-process que l'on retranscrit grâce à l'usage de shaders. Il restait à définir la formule magique utilisée par Photoshop. Pour se faire on sort google (outil de recherche de formule éprouvé :)) et RenderMonkey (un logiciel permettant d'écrire des shaders peinard dans son coin). Après quelques heures, la petite formule magique est découverte :
Un shader qui au final tient sur une ligne et une 100aine de caractères
On peut alors utiliser cet effet in-game. Youpi.
Les restes
Pour le reste, j'ai poursuivi l'élaboration de maps de test pour illustrer des mécaniques de gameplay qui seront intégrées dans les vrais niveaux conçus par William, avec son outil favori : Blender.
Outil auquel j'ai apporté quelques améliorations et corrections pour que William craque le moins possible lorsqu'il l'utilise pour mettre en oeuvre son Level Design :)
Ainsi nous avons maintenant un "file checker" qui va lister correctement toutes les erreurs de la map et parfois tenter de les corriger lui-même (manque d'une caméra, matériaux avec des textures qui ne pointent pas dans le bon répertoire... etc).
Le T-shirt qu'il faut que j'achète pour bien conditionner William
J'espère que je ne vous ai pas trop saoulé avec ces quelques considérations techniques, et à bientôt pour de nouvelles neuves du monde de Seasons !
Guillaume
EDIT: N'hésitez pas à nous faire part de vos questions/remarques dans les commentaires si certains points de ce billet restent obscurs :)
Seasons prend forme au fil des saisons. L'été et ses températures presque caniculaires sont d'ailleurs déjà bien installés dans le sous-marin, et le premier à en faire les frais c'est Buster, notre chat "responsable marketing".
On profite donc d'un petit matin un peu plus frais que les autres pour écrire cet article à 4 mains et faire un point sur le travail accompli pendant le mois de Juin. Et c'est William qui commence :
> STRUCTURE DE JEU
J'ai créé de petites cartes d'environnement afin de pouvoir jouer avec et imaginer l'enchainement des niveaux. Structure linéaire, semi-linéaire, ouverte : toutes les pistes ont été envisagées, le but étant de créer un monde un peu vivant sans pour autant que le joueur s'y perde.
En recoupant les thèmes des différents environnements et gameplays possibles, on pense que le jeu devrait compter 7 environnements principaux.
> LEVEL DESIGN
Une première passe théorique a été faite en listant les différents éléments de jeu et en les répartissant par environnement. Il s'agit de tracer les grandes lignes pour caractériser chaque "niveau de jeu", on ne fait pas encore dans le détail. Après quelques ébauches sur papier, je suis passé à la pratique (de retour sur Blender, ouais !).
> GRAPHISME
Dans ce domaine, peu de progrès ont été fait. On sait cependant de plus en plus vers quoi on se dirige, notamment concernant notre renard qui a encore évolué. D'ailleurs on aimerait bien avoir votre avis là-dessus.
Est-ce qu'un design plus "jeune" et proche des designs de Gaël vous intéresse, ou pas ? (cliquez sur l'image pour la voir en grand)
La semaine prochaine, Guilaume fera le point sur les avancées en Programmation :)
Bon week-end à tous !
Salut tout le monde,
Tiens, un nouveau billet ? Mais oui vous ne rêvez pas !
Juste pour vous dire que nous travaillons toujours sur Seasons (on stoppe les "Deep Water Experiments" en cours pour le moment).
William planche sur le LD (Level Design) et moi je code les fonctionnalités qui découlent du GD (Game Design) établi jusque là.
Du coup notre petit renard se trouve dans une sorte d'antre du programmeur. Fini les beaux décors parallaxés de William, bonjour les formes "placeholder" de Guillaume.
La vidéo illustre le sort du renard enfermé dans un niveau de programmeur et qui doit apprendre des features comme planter des arbres, voir pousser des fleurs (géantes), manipuler des éléments au sol ou encore faire la connaissance d'un autre animal et tenter de communiquer.
Rassurez-vous, la vidéo montre des maps de tests et non le jeu lui-même. Par ailleurs on vous montre ici que les features et mécaniques "basiques" qu'effectue l'animal... on ne voudrait pas vous gâcher la découverte et les surprises du jeu final.
Guillaume
| 1 2 3 4 |
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 :
Le Blog de Pix'n Love
Dans l'Arena avec Tiris
Le Blog de l'association MO5.COM
Ajouter aux favoris
Enlever des favoris