Ce week-end il y avait une Gamejam organisée chez Mozilla. Je n'avais jamais fait de gamejam avant, vu que la plupart du temps il faut savoir coder sous Unity. Cette fois-ci, c'était différent et tout tournait autour d'un framework en javascript nommé redwire. En plus, les co-organisateurs sont des amis.
Toutes les conditions étaient donc réunies pour que je participe enfin à ma première gamejam.
Redwire est un système de programmation qui réplique le principe d'un circuit électronique, et qui fonctionne en mode drag'n'drop. On y manipule des if, des loops et un ensemble d'inputs et d'outputs. Pour être honnete, je n'ai pas réussi à rentrer dans le framework. J'avais envie d'écrire mon propre JS et CSS, pas de passer par les cases pré-établies du système.
Le créateur était là, et était d'une grande aide pour sauver les équipes qui étaient bloquées. Il était plus ou moins le seul à connaitre le système, sa logique, ses tweaks et ses bugs.
Redwire est quand même fondé sur un principe de modularité très intéressant. Idéalement il est possible de récupérer des briques de gameplay d'un jeu pour les incorporer dans un autre. On a donc divisé notre week-end en une phase d'apprentissage du framework, la construction de briques individuelles, et l'assemblage de ces briques pour en faire des jeux complets.
Afin d'éviter de partir dans trop de directions, on a limité le nombre de types de jeux à trois : text-based, shooter et puzzle game.
Les jeux finaux qui en sont sortis étaient bourrés de bonnes idées, malheureusement leur réalisation était assez pauvre. Même si j'ai passé plus de temps à coder le site que vous êtes actuellement en train de lire plutot que d'essayer Redwire, j'ai quand même passé un bon moment.
Ci-dessous, mes notes sur les différentes briques et les jeux en résultant que j'ai prises à l'issue de la première journée.
SHOOTER
Ennemi téléporteur, à intervalle peut disparaitre et revenir à un autre endroit.
Ennemi cloneur. A intervalle régulier, va se dédoubler.
Ennemi Kamikazer. Fonce vers le personnage principal directement.
Sortir d'un coté, rentre d'un autre.
Mur d'obstacle qui fait tout l'écran, avec 3 couleurs et 3 sons. Son qui indique la couleur à passer.
Clic, tir vers la direction de la souris.
Bouclier de protection, protège autour de la souris.
Power Down, fait doubler la taille du joueur.
Touche appuyée, attire les ennemis, relache pour projeter.
Labyrinthe circulaire et pivotant dont les murs sont mortels.
Bonus qui multiplie par trois le personnage (3x plus fort)
Ennemi aléatoire qui droppe un loot aléatoire.
Ennemi au comportement évolutif (zigzag, spirale)
Deux vaisseaux, touche et souris
Boites bonus aléatoires
TEXT-BASED
Boite de dialogue. Portrait, texte, trois réponses.
Mot apparait, temps limite pour le taper sur le clavier.
Suite de mots dans le désordre, à remettre dans l'ordre.
Mots qui disparaissent dans un bloc de texte, 1 toutes les 2 secondes.
Dans un bloc de texte, certains mots, si on les tape, on gagne des points.
Choix multiples
Mémorisation des choix dans le passé du jeu
Affiche la touche de controle qu'on appuie. Si mur, bloque, si ennemi, appuyer sur touche attaque.
Pierre-Feuille-Ciseau
Tooltip sonore
Twister au clavier
Spam d'une touche pour monter une entitée, si arrete de spammer, redescends
Background qui réagit aux pressions du clavier
BLOCK PUZZLE GAME
Blocs avec lettre, tape sur lettre, le fait disparaitre.
Grille 5x5, clic dessus, disparait et ceux au-dessus descendent.
Grille dont les carrés changent de couleur quand on passe en hold dessus.
Blocks à l'écran, touches de clavier dédoublent dans la direction indiquée.
3x3 avec un bloc de libre, faire glisser dans la case vide pour former l'image
Deux joueurs Tetris, l'un modifie les blocs avant que l'autre ne le recoive.
TECHNIQUE
Tileset + matrix = image canvas finale
Entrée texte avec choix multiple, retour un integer du choix
X joueurs, pour que l'équipe gagne il faut que chaque joueur se soit spécialisé dans une compétence et en soit expert
MES FAVORIS EN FIN DE PREMIERE JOURNEE
Mur d'obstacle qui fait tout l'écran, avec 3 couleurs et 3 sons. Son qui indique la couleur à passer.
Touche appuyée, attire les ennemis, relache pour projeter.
Labyrinthe circulaire et pivotant dont les murs sont mortels.
Deux vaisseaux, touche et souris
Boite de dialogue. Portrait, texte, trois réponses.
Mot apparait, temps limite pour le taper sur le clavier.
Suite de mots dans le désordre, à remettre dans l'ordre.
Mots qui disparaissent dans un bloc de texte, 1 toutes les 2 secondes.
Dans un bloc de texte, certains mots, si on les tape, on gagne des points.
Affiche la touche de controle qu'on appuie. Si mur, bloque, si ennemi, appuyer sur touche attaque.
Spam d'une touche pour monter une entitée, si arrete de spammer, redescends
Blocs avec lettre, tape sur lettre, le fait disparaitre.
Grille 5x5, clic dessus, disparait et ceux au-dessus descendent.
Grille dont les carrés changent de couleur quand on passe en hold dessus.
Ce nouveau meetup angular avait lieu chez Sfeir, à Neuilly. Et Sfeir avait mis le paquet. En plus de la bouteille d'eau ou de la canette de SfeirBull brandée, on a eu le droit à un carton pour coopter un Sfeir. Même sans faire partie de Sfeir, si on leur propose un dev et qu'ils l'embauchent, on gagne un MacBook Pro. C'est sans doute moins cher qu'un cabinet de recrutement, mais c'est une drole de technique.
Avant les talks, on a eu aussi droit à une petite présentation de Sfeir. 270 employés, 27 millions de CA. Basé à Paris, Strasbourg et Lille (et une 4e ville que j'ai oublié). Les Sfeiriens sont découpés en groupe en fonction de leurs compétences : Front, Back (Java, C#), Agile (Coach, PO), TMA, Infra. Leur crédo est essentiellement le Front, l'Agile et le Cloud (et aussi, mais moins primordial les technos Google et le Big Data).
Sfeir est pas mal impliqué dans les meetups parisiens, et ils sont aussi partenaires de Google, Microsoft, Atlassian et Cloudbees (et j'ai appris que Cloudbees était à l'origine de Jenkins).
Vu que le meetup était sur Angular, ils nous ont aussi particulièrement parlé de leur équipe Front, qui recrute. Ils font tous les mois des genres de BBL, une présentations suivie d'une bonne bouffe. Ils font venir des intervenants externes pour faire monter l'équipe en compétence (Raphael Goetter est venu présenter CSS3, et Nicolas Perriault pour CasperJS). Ils incitent à participer aux conférences, pour y assister ou pour y parler. Ils ont deux speakers à ParisWeb cette année, et un à ngEurope.
Mais le truc le plus intéressant sont les formations Angular qu'ils donnent, gratuitement, à des groupes d'une douzaine d'élèves. Leur idée est qu'Angular est une bonne techno, mais qu'il y a plein de projets Angular qui naissent, et donc plein de projets qui vont mal se passer, parce que les développeurs n'auront peut-être pas compris la techno et lui feront donc une mauvaise réputation. Eux, ils souhaitent former les gens sur la techno, pour que de plus en plus de personnes la maitrise et puissent aller comme ça polleniser les bonnes pratiques dans les équipes et qu'ainsi le milieu du développement Angular en France soit d'un meilleur niveau.
On sentait qu'ils cherchaient à recruter de bons devs et ils ont mis le paquet sur les avantages à être chez Sfeir. Vu que sur les deux talks de la soirée, le premier a été choisi par hasard deux semaines avant et le second la veille, heureusement qu'il y a eu ce speech au départ.
Le seul bémol est le bruit incessant de singe qu'on égorge qui se faisait entendre à chaque fois qu'une porte s'ouvrait ou se fermait.
Nephorider : Moving a MacOS app to angular.
La première présentation était sur NephoRider, une application de visualization d'infra cloud. J'avais déjà vu un lightning cloud à dotScale sur le sujet. Il avait parlé des différentes API des providers clouds qui lui permettaient de tracer cette visualization et lesquelles étaient les plus pratiques (spoiler: celles qui permettent de faire un minimum de requetes en les aggrégeant).
Ce soir on a eu le droit à une démo rapide de l'appli, qui permet de voir sous forme d'arbre les différentes machines du parc et leurs liaisons, si elles sont up ou non, combien elles coutent, leurs ips, etc. L'appli de base est une appli desktop Mac. Comme la cible sont les ingénieurs de la Silicon Valley et que tout le monde a un MacBook là bas, c'était la solution de facilité. Ca permettait aussi d'exporter facilement en PDF, et les machines étant standard, on n'est pas obligé de tester trop de paramètres différents pour s'assurer la compatibilité.
Passer en web a été un peu plus dur. Déjà au niveau du front, les services sur lesquels ils se branchent sont peu nombreux à proposer un SDK. Et ceux qui le font le font généralement pour des applis mobiles et pas pour du web. Par contre, passer en web leur a permis de considérablement diminuer leur Time To Market, en pouvant déployer une nouvelle version chaque jour sans avoir besoin d'attendre la validation du store Apple.
On change par contre complétement d'univers. On est désormais à l'intérieur d'un browser, on n'a plus le controle sur tous les raccourcis clavier, le browser ayant les sien par défaut qu'on ne peut pas changer. De la même façon, on doit se plier aux comportement attendus du browser (back, forward, refresh).
Viennent ensuite les problèmes de redimensionnement des images. Sur une appli native Mac, c'est un faux problème car l'OS offre plein de possibilités pour faire ça et a optimisé sa carte graphique pour ça. Dans le web, la solution la plus proche d'un rendu desktop qu'ils ont trouvés est d'utiliser du SVG, et une pointe de D3JS.
Tous les calculs sont relégués au back-end, le front ne s'occupant que de l'affichage. Certains fonctionnalités sont même complétement executées en backend (comme l'export en pdf par exemple).
Finalement, pourquoi a-t'il choisi Angular ? Et bien un peu par hasard. Il a choisit à un instant donné le framework qui était le plus populaire. Il n'y connaissait pas grand chose en front, mais n'a finalement pas été déçu. Son retour d'expérience est que les Controllers d'Angular sont assez proches de son code Cocoa, il a quasiement juste eu à copier-coller le code d'un langage à l'autre, modifier quelques itérateurs et quelques éléments de syntaxe mais la majorité était déjà faite.
Pour les directives par contre, il tient le même discours qu'un peu tout le monde : c'est très compliqué. On peut leur faire faire des composants simples et modulaires comme on peut en faire un système complexe de gestion de template et de fenetres (ce qu'il a fait).
Pour lui la courbe d'apprentissage d'Angular est très forte. Même en utilisant des projets de bootstrapping comme angular-seed ou yeoman c'est beaucoup de choses à ingurgiter en une seule fois. Sans parler des npm et bower. Quand on vient du monde du dev Mac où on ne doit supporter qu'une version, deux maximum, toute cette histoire de gestionnaire de dépendances et de version lui semblait overkill.
Il a pas mal buté sur les paradigmes différents entre une appli Desktop et une appli web, ou sur des fonctionnements similaires qui portaient des noms différents, ou au contraire des comportement différents qui portaient le même nom dans les deux univers.
Chose qui m'a surprise, il utilise abondamment $watch dans son appli, comme élément fondateur pour faire communiquer les différentes parties, de la plus haute à la plus basse.
Finalement quand on lui demande s'il a des tests automatisés d'IHM dans son appli il réponds que non. Que pour lui le meilleur test est celui que tu fais à la main, ou par un réel utilisateur. Il pense que c'est de son temps passé chez Apple, ou l'UX a beaucoup d'importance, c'est quelque chose qui se ressent en le faisant, qu'on ne peut pas abstraire dans un test. Il ajoute aussi que quelque soit le harnais de test que tu mettes en place, quand tu passera ton appli à un utilisateur lambda il va te remonter des bugs que tu n'aurais jamais pu imaginer.
Angular UI
Le second talk n'a failli pas avoir lieu. Douglas Duteil, développeur chez Sfeir nous parle des animations dans angular. Il doit présenter ce talk à ngEurope et donc ça lui permettait de faire une petite répétition. Mais finalement il semblerait que le core commiter d'Angular qui se spécialise sur les animations fasse aussi une présentation sur les animations, du coup Douglas va devoir sans doute trouver un autre sujet.
Bref, revenons à nos animations et à un problème que je n'imaginais pas. Angular peut gérer des animations, par exemple pour faire apparaitre ou disparaitre un élément avec un bel effet de fondu. Oui mais si on lie cela au two-way binding et à ng-if, comment est-ce que ça marche ? Notre élément doit disparaitre quand la valeur testée devient fausse, mais si on y a mis une animation ça veut dire qu'il y a donc une différence entre l'état de notre application (sous forme de data) et son état visuel. L'animation peut prendre une seconde à s'effectuer alors que notre variable est bien devenue false. Du coup la vue ne représente pas exactement le modèle. Et que faire si elle redevient true alors que l'animation pour la faire disparaitre n'a pas terminé de se jouer ?
Comme dans un bon polar, Douglas nous laisse sur nos questions pour partir dans une autre direction. Il nous parle de la Web Animation API, un spec en cours sur les animations qui semble lui donner des étoiles dans les yeux. Elle a pour but d'uniformiser sous une API commune les animations CSS, Javascript et même canvas. Elle permettra d'exposer un objet normalisé représentant l'horloge d'une animation. Cet objet étant passé en paramètre aux fonctions appellées à chaque tick des animations, ce qui permettra de savoir exactement où on en est dans l'animation et de pouvoir influer directement dessus, voir d'influer sur d'autres animations dans la page.
Douglas avait travaillé sur un projet perso nommé WAaA pour Web Animation and Angular qui devait permettre de porter cette API dans les browsers qui ne l'implémentent pas et plus particulièrement de remplacer ng-animate par ce polymer. Le projet n'a pas trop évolué, les performances étant assez mauvaises. Et la team officielle Angular n'avait pas l'air trop motivée pour l'utiliser, leur argument étant que la spec allait arriver officiellement dans les browser plus tard.
Et c'est effectivement le cas car Chrome 36 incorpore la Web Animation API !
J'ai eu la chance de participer à la formation "Réussir ses présentation PPT" à Octo. N'ayant jamais touché à PowerPoint et étant sous Linux, j'ai un peu galéré à installer une version de Windows Trial, et une version Office Trial pour pouvoir avoir PowerPoint le jour J.
Il s'est avéré que la formation portait plus sur les présentation en règle générale, sur les messages à faire passer et comment les passer que sur l'outil en lui-même.
La formation était orientée sur la création de présentations dans un contexte professionnel, à destination de nos clients finaux. Dans cette optique, on considère que l'on utilise le même support pour la présentation, en personne, devant eux, que celui qu'on leur enverra par mail et qu'ils pourront relire ensuite.
Partant de là, il est important de proposer deux niveaux de lecture. Chaque slide doit porter un message, et on peut suivre la suite des messages, et donc le message global rien qu'en lisant les titres de chaque slide. Ensuite, si on veut avoir plus de détail, on peut aller le chercher dans la slide en question, et si vraiment on veut creuser très profondément, on peut rajouter des annexes qui explicitent certains points.
Les slides doivent être auto-portants, notre présence ne doit pas être requise pour comprendre le gros du message. Notre auditoire possède une capacité de concentration limitée, il faut donc lui faciliter la lecture et la compréhension de chacun des messages. Si un message est trop complexe, on le découpe en deux slides.
Même si l'auditeur décroche quelques secondes, pour cause d'un moment d'inatention, il faut que la slide puisse lui rappeller en un coup d'œil où on en est dans le déroulé. Ce n'est pas grave si notre auditoire décroche par moment, c'est normal. Mais il faut lui laisser la possibilité de suivre la présentation à son rythme et de pouvoir décrocher et raccrocher quand il le souhaite.
Dans la même optique, il ne faut pas jouer sur le suspens, en annoncant petit à petit notre message, et en présentant la conclusion seulement à la fin. Il faut être direct, et présenter la solution dès le début. Ca s'applique tout aussi bien dans la présentation dans son ensemble que pour chaque slide prise séparement. On présent dès le début la conclusion de notre étude, ce que l'on pense qu'il faille faire, etc. Et ensuite, le reste de la présentation permet de démontrer, de prouver, de corroborer ce que l'on a annoncé dès le début. Il ne faut pas que l'auditeur ai à attendre la fin pour comprendre le message, sinon il va décrocher.
C'est pour cela qu'il faut porter grande attention aux titres, et faire en sorte qu'ils ne soient pas creux. Il faut oublier les titres de genre "Contexte", "Constat", "Nos préconisations". Il faut que chaque texte transmette une prise de position, une description. Par exemple "Un contexte difficile", "Un constat en demie-teinte", "Former les développeurs pour plus de flexibilité".
On a aussi vu, par la pratique, à quel point notre cerveau humain percoit les formes et les images beaucoup plus rapidement que le texte. Il faut donc faire attention aux éléments que l'on utilise pour illustrer nos propos, faire attention qu'ils ne phagocytent pas le message que l'on souhaite faire passer. Une image ne doit être incorporée que si elle ajoute réellement de la valeur, de l'illustration au message à passer. Une image qui donne un exemple est très parlante, notre cerveau s'en rappellera bien, mais une image "pour faire joli", va trop attirer le regard et le détourner du propos initial.
On n'est pas là pour raconter une histoire, pour parler de soi ou pour divertir. On est là pour démontrer une thèse, pour montrer ce que l'on pense, et le démontrer ensuite. Notre message doit être clairement explicité, avec une slide par idée. On montre dès le début la conclusion, et on explicite seulement ensuite. On évite les titres creux, il faut qu'ils transpirent une conviction, une croyance. Les phrases doivent être simples, deux virgules maximum. Si la phrase est trop longue, alors l'idée est trop complexe. Pour rester factuel et uniforme essaie de garder tous les verbes à l'infinitif, sans les conjuguer. Au pire, on mets au présent. On évite les verbes trop génériques (faire, dire, être, avoir), on remplace par de synonymes plus précis. Et on ne doit pas avoir peur du blanc, du vide, il ne faut pas chercher à remplir la slide à tout prix. Par contre, ce que l'on mets doit être aéré, aligné, et cohérent.
Si on doit faire une liste, on fait attention à la cohérence (liste de noms, de verbes, etc), et on mets en avant (en gras par exemple), les idées principales de chaque ligne. Si on a choisi le gras pour la mise en avant, on s'y tient, on n'utilise pas de la couleur ou de l'italique sur une autre slide. Dans la même idée, on limite le nombre de couleurs utilisées à 3, ou 4 au grand maximum. Une seule police maximum.
Une fois sa slide terminée, on vérifie sa checklist pour être sûr de n'avoir rien oublié : - Deux niveaux de lecture. L'idée principale dans le titre, plus de détail dans la slide. Je dois pouvoir suivre le plan général juste avec les titres. - Qu'est-ce que je veux dire ? Quel est mon message ? Quels sont les élements chocs, convaincants ? - Est-ce que je suis obligé de dire tout ça ? Est-ce que je peux en enlever ? Ou au contraire, est-ce que je n'ai pas oublié un élément primordial ? - D'abord la conclusion, ensuite la démonstration. - Est-ce que mes données, mes sources, mes graphes sont bien à jour ? Attention aux copié-collé d'anciennes présentations dépassées. - Est-ce que mes visuels servent vraiment mon propos. C'est eux qu'on va voir en premier, est-ce que c'est vraiment ça que je veux ou est-ce que c'est superflu ?
Enfin, si vous ne savez pas comment faire le plan général de votre présentation, il y a plusieurs idées assez classiques : - FSVOM: Les Faits, ce que l'on Sent, ce que l'on Veut, les Obstacles et les Moyens - Diagnostic : Le problème, la possible solution, les conséquences et la décision finale. - SOSRA: Situation, Observation, Sentiment, Réflexion, Action - PPL : Principes, Portée, Limites
Et finalement un dernier conseil. Si après tout ces conseils vous avez bien taillé dans le lard de votre présentation et enlevé tout le superflu pour ne garder que l'essentiel et que votre message est bien clair, mais que malgré tout tout semble aussi important et capital, il faut encore prioriser. Si tout est important, en fait rien n'est important. Il va falloir prioriser, et prendre une décision, une conviction qu'on doit pouvoir démontrer dans la présentation.
Mardi dernier avait lieu les HumanTalks. Cette fois-ci c'était dans les locaux de So@t, et c'était sur le thème des jeux vidéos.
Au menu, on a eu 5 présentations :
Board Game Arena, un site communautaire pour jouer à des jeux de plateau en temps réel, et explication de la stack technique derrière (Jetty, Apache, PHP, long-polling)
Overview de ce qu'est la gamification, et comment ça marche.
Présentation de Gosu, une librairie Ruby pour faire des jeux vidéos en 2D très facilement.
Les Agile Games, et en quoi jouer stimule des parties spéciales du cerveau et peut aider à l'innovation, le cohésion de groupe et l'empathie.
Et finalement, retour d'expérience d'un game designer de chez Quantic Dream, et comment se passe les cycles de développement d'un AAA vu de l'intérieur.
BoardGameArena
Gregory Isabelli (@boardgamearena), nous parle de Board Game Arena, un site où il est possible de jouer en temps réel avec d'autres joueurs à des jeux de plateaux.
Le tout est (bizarrement) codé en PHP, avec un Apache devant, et des connections avec le serveur en long-polling. Derrière ces choix étranges, il faut savoir que le site a déjà près de 6 ans d'existence si je me souviens bien, et que c'était pas un si mauvais choix de stack à l'époque.
Le paradigme classique du web (le client initialise une requete, le serveur l'attrape et réponds) n'est pas possible pour faire du temps réel, vu qu'il faut que le serveur puisse notifier ses clients quand une nouvelle action se passe (classiquement, quand un autre joueur à fini son tour).
Il utilisent donc un serveur jetty devant leur apache pour gérer le long-polling. Pour ceux qui ne sont pas familiers avec la technique, le long-polling consiste à ce que le serveur prenne le plus de temps possible pour répondre (mais sans timeout). Le client envoie une requete, et si le serveur n'a rien à répondre, il maintient la requete ouverte. Si jamais il est notifié d'un event en interne, il ferme la requete en envoyant le résultat de cet event, et le client renvoie aussitot une nouvelle requete. Si jamais il n'y a pas eu d'event, le serveur renvoie quand même une réponse pour éviter le timeout, et le client relance une requete.
Comment ça se passe par derrière en PHP ? Et bien, quand un joueur A envoie ses ordres, le serveur s'occupe de calculer le nouvel état du plateau de jeu. Il notifie ensuite le serveur jetty avec le nouvel état, et celui-ci ferme toutes les requetes ouvertes de tous les joueurs avec ces nouvelles informations (qui en ouvrent à nouveau de nouvelles automatiquement).
Sur boardgamearena, ils ont en moyenne 1000 joueurs connectés tous les soirs, et leur unique serveur jetty tient tout à fait la charge. Néanmoins, ils savent que s'ils doivent scaler pour accueillir plus de joueurs, il leur suffit de rajouter de nouveaux serveurs jetty (environ 1 pour 20.000 joueurs) et de modifier le PHP pour qu'il notifie plusieurs jetty à la place d'un seul.
Étant moi-même grand joueur de jeux de plateaux, j'ai beaucoup aimé ce site, que je ne connaissais pas. Ils proposent aussi un mode "studio", dispo directement dans le navigateur pour coder ses propres jeux.
La Gamification, qu'est-ce que c'est ?
David Grezinger, développeur chez Xebia, qui nous avait déjà fait une présentation sur les MOOCS à un précédent HumanTalks, nous a cette fois parlé de la Gamification (sujet qu'il a appris grâce à Coursera).
Il nous a d'abord parlé du but de la gamification, qui peut être d'attirer des utilisateurs sur une plateforme, ou de favoriser le travail en équipe. Pour cela on utilise une mécanique de points, de badges, de barres de progressions, qui peut être plus ou moins subtile. Foursquare est un exemple de Gamification assumée et très flagrante, idem pour les badges sur CodeSchool. Les barres de progression quand on rempli son profil sur LinkedIn par exemple en est un autre exemple. StackOverflow finalement est un exemple un peu plus subtil.
Mais il ne suffit pas de rajouter des points ou de badges pour avoir une gamification réussie. Le but est de réussir à recréer des mécanismes qui nous paraissent ludiques, amusants, et qui incitent, sans qu'on le remarque, à faire des tâches qui nous auraient sinon semblées rébarbatives. Il existe des applications de fitness qui poussent la gamification très loin, en simulant un mode envahi de zombis, en faisant appel à un savant mélange de carte google maps et à l'imagination de l'utilisateur pour le forcer à courir d'un point à l'autre de sa ville pour "éviter les zombis".
Il a fini par faire un parallele avec World of Warcraft, où pour réussir à battre l'un des boss les plus difficiles du jeu, il fallait à une époque réussir à regrouper une équipe de 40 joueurs différents, avec des classe de personnages (et donc des roles) complétement différents. Réussir à la coordonner, plusieurs fois par semaine, pendant des mois, échec après échec, pour finalement réussir à battre ce satané Ragnaros. Essayez donc de faire la même chose en entreprise, coordonner 40 personnes, à distance, avec des compétences et des égos complétement différents, pour atteindre un but commun, échec après échec.
Ceci n'est qu'un résumé de son talk qui était lui-même un résumé du cours de Kevin Werbach sur Coursera, donc si vous voulez creuser le sujet, je vous invite à aller directement à la source.
Faire des jeux en Ruby avec Gosu
Matthieu Segret, co-fondateur des HumanCoders nous a fait une présentation sur Ruby, et plus particulièrement Gosu. Gosu en Ruby est simplement une interface qui se bind sur une library en C qui permet de créer facilement des jeux 2D.
C'est cross-platform, ça permet de générer une fenetre dans l'OS, avec un background, des sprites, et une boucle de jeu qui écoute les événements clavier.
Lors de ses formations d'initiation à Ruby, c'est cette library qu'il utilise pour apprendre Ruby a des débutants, parce que le feedback visuel est instantané et le code est facile à lire et à écrire.
Je ne vais pas trop m'étendre dessus, vu qu'il l'avait déjà présenté à un parisRB, il vous suffira de retrouver le compte-rendu initial.
Agile Games
Talk présenté par un formateur agile de So@t dont j'ai malheureusement oublié le nom. Il nous a parlé du jeu comme mécanisme d'amélioration, d'innovation et d'estimation.
Jouer permet de manipuler des concepts de manière plus forte que de simplement les lire ou les écouter, cela permet de se les approprier avec plus de force, d'en devenir utilisateur et non plus seulement spectateur. Cela permet aussi de créer des liens entre des personnes, une synergie, une empathie qui n'est pas forcément créée naturellement dans un contexte d'équipe traditionnel.
Selon lui, on retient plus facilement une leçon quand elle est liée à une émotion forte, et comme il ne peut pas taper sur ses élèves, il préfère les rendre contents, par le jeu.
D'un point de vue purement neurologique, ce ne sont pas les mêmes zones du cerveau qui sont sollicités quand on réfléchit à un problème que quand on manipule physiquement des objets. On peut ainsi faire sortir des idées qui ne seraient pas venues si on s'était simplement limité à réfléchir au sujet. C'est simplement humain.
Il a ensuite donné plusieurs exemples de jeux agile qu'il utilise. La product box, qui consiste à essayer de construire la "boite" de notre produit si celui-ci pouvait simplement être vendu en supermarché et que l'acheter suffisait à résoudre les problèmes qu'il est censé résoudre. On réfléchit donc à mettre en avant ce à quoi le produit doit servir. Le cadrer dans un exemple concret auquel on est habitué, peut permettre de plus facilement s'approprier l'exercice. Cela permet aussi de discuter sur ce qu'il est nécessaire de mettre en avant sur le produit, et de potentiellement voire les différences de perception entre les personnes sur ce qui est important. La place sur la boite étant limitée, on doit se concentrer sur le plus important.
Il a ensuite présenté des estimation games. Partant du principe que c'est aux développeur d'estimer eux-même la durée de leur charge de travail et non pas à leur boss, que l'intelligence collective permettrait un meilleur chiffrage que l'estimation individuelle. Il nous a donc présenté le planning poker, rajoutant que l'esprit humain est facilement capable de faire des comparaison (machin est plus grand que bidule) que de donner des chiffres exacts (machin mesure 1m82). La suite de Fibonnacci est donc parfaitement adaptée pour ça.
Il a ensuite donné l'url du site tastycupcakes.com pour trouver des idées de jeux agiles, et a annoncé qu'ils avaient développés en interne à So@t un Kaizen Game, permettant d'aider l'amélioration continue, et qu'ils le présenteraient à un meetup prochainement.
Bonnes idées, même si je pense qu'on utilise un peu les mêmes techniques à Octo, je n'en ai jamais utilisé personnellement, et j'ai aimé avoir des arguments (neurologiques) sur en quoi c'est intéressant, et que ce n'est pas simplement parce que c'est plus fun.
La création d'un AAA
Alexis Moroz nous parle de son parcours de game designer dans plusieurs boites de jeu vidéo français. Il a surtout parlé de son travail sur Heavy Rain, chez Quantic Dream vu que c'est là qu'il a passé le plus de temps.
Quantic a 17 ans d'existence, et 5 jeux produits. Ils sont spécialisés dans les "Interactive Drama", un genre qu'ils ont inventés, genre de films interactifs, avec beaucoup d'émotion, mais que beaucoup de gens qualifient comme "n'étant pas des jeux".
La production d'un jeu AAA comme Heavy Rain a couté environ $20 millions de dollar, plus environ $30 millions de marketing. Au final, le jeu aura rapporté $113 millions. Aux dires d'Alexis, Heavy Rain n'était pas vraiment un "triple A", mais plutot un "2.5 A", car depuis des jeux comme les Assassin's Creed ou GTA ont complétement réhaussé le budget nécessaire à la conception des jeux. On dépasse aujourd'hui les budgets des blockbusters de cinéma.
Le rythme de développement d'un jeu de ce genre est très différent de ce à quoi nous sommes normalement habitué dans les projets informatiques. Tout est drivé par les milestones : pré-alpha, alpha, pré-beta, beta, release candidate et gold. Les dates de ces milestones sont fixées à l'avance et coincident avec des événements majeurs du milieu (E3, TGS, etc). Il n'est donc pas possible de les déplacer, une version du jeu doit être sortie à cette date, quoiqu'il arrive.
En plus de cela, les budgets pour les jeux étant colossaux, Quantic ne peut pas investir sur ses propres fonds. C'est donc le travail de l'éditeur, dans leur cas, Sony. Ils passent un contrat avec Sony, où Sony s'engage à payer leurs dépenses (locaux, salaires, etc) jusqu'à la prochaine milestone, et eux s'engagent à un certain nombre de features qui doivent apparaitre dans cette milestone. S'ils ne remplissent pas leur part du contrat, alors Sony ne remplit pas la sienne non plus. C'est à dire qu'ils ne sont pas payés, et que donc des jeux peuvent ne jamais voir le jour si une des milestone n'a pas été atteinte.
Il n'est pas possible de négocier sur les délais comme on l'a vu, et très difficile de négocier sur le périmètre, Quantic s'engageant sur celui-ci au début. Néanmoins, Alexis nous avoue que généralement on triche sur les specifications. Si on a dit qu'un niveau entier doit etre jouable, ou que tous les personnages doivent être texturés pour une étape donné, on ne fait quand même que le minimum pour ce qui n'est pas indispensable. Niveau vide à part pour l'intrigue principale, textures de basse qualité pour les endroits éloignés, etc.
Du coup, si ni les délais ni le périmètre ne peuvent bouger, qu'advient-il de la qualité ? Et bien c'est là que tout est subjectifs. Chez Quantic, les jeux jouant beaucoup sur l'émotion, les tests des niveaux sont effectués par des humains, qui jouent et rejouent, et des playtesteurs externes. Il n'ont que très peu de tests automatisés, voire pas du tout. Ils ont de grandes sessions de QA, mais faites par des humains (un chèque cadeau de 100€ contre 3-4h de test d'un niveau).
Quantic, et Ubisoft, et finalement pas mal des grosses boites de jeu sont connues pour avoir des rythmes de développement effrenés quand les dates de milestone approchent, surtout quand la dernière arrive. Ils savent qu'après la date finale, ils ne pourront plus rajouter de contenu sur leur jeu, et ils y ont travaillé des années, par passion, ils ont envie qu'il soit parfait. Et comme ils sont aussi généralement en retard des milestones précédentes pour avoir grapillé sur les specs, ils ont beaucoup de travail à faire à la fin. Ces periodes de burn sont très durs, et il est fréquent que des démissions arrivent à la pelle après ces périodes, qui en dégoutent plus d'un de travailler dans ce milieu.
Les salaires ne sont pas mirobolants non plus, les boites jouant beaucoup sur le fait que "mais tu viens faire ta passion, travailler dans le jeu vidéo c'est pas donné à tout le monde, si tu ne veux pas de ce poste, je vais en trouver facilement d'autres, tu devrais être content."
Ce qu'il est intéressant de noter sur la composition des équipes, c'est qu'il y a autant de développeurs (une vingtaine chez Quantic en tout cas) pour la conception du moteur de jeu en lui même que pour la conception des outils internes (outils pour importer les textures, gérer les modèles 3D, gérer le motion capture, etc).
Finalement dernière point intéressant pour revenir sur les différentes milestones, c'est que généralement les deux premières (pre-alpha, alpha) contiennent surtout des artworks et pas de phase de jeu, puis vient la "vertical slice", qui est censé donner une vue d'ensemble d'un niveau du jeu. Avec la musique, les effets, le scénar, le moteur 3D, etc. Bref, toutes les couches du jeu sont présentes, mais sur une durée limitée. Ce genre de production peut difficilement être réutilisée dans le projet final, et c'est donc finalement du temps "perdu" en développement, mais gagné pour le coté marketing.
Cette fois-ci, c'était chez Meetic, qui ont de chouettes locaux en plein Paris, mais on peut passer devant sans s'en rendre compte vu que ce n'est pas marqué sur la façade.
Améliorer les performances de ses applications Angular
Jonathan Meiss, ancien collègue Octo désormais chez Meetic, nous présentait toute une liste d'astuces pour améliorer les performances d'une appli Angular. Globalement c'était des choses assez basiques et connues.
On a pas mal parlé de ngRepeat qui est là que généralement les problèmes de perf se font sentir. Déjà il est éviden que la page va être moins performante si on doit afficher 1000 élement que si on n'en affiche que 10. Du coup, il peut être intéressant de faire appel à limitTo pour paginer les résultats. Une autre solution est de tirer parti de l'infinite scroll qui permet de ne charger des éléments que quand ils vont apparaitre dans le viewport. Il conseille la library ng-infinite-scroll pour ça.
Toujours sur les ngRepeat, il faut bien sur éviter de faire des boucles sur des résultats de fonctions (ie pas de ng-repeat="item in filteredList()") car cela force à recalculer le contenu de filteredList à chaque digest cycle. Mieux vaut soit utiliser des filter dans la vue, soit itérer sur une variable du scope.
Dernier conseil sur ngRepeat; angular génère un id unique à chaque élement sur lequel il itère pour les différencier. Si on le laisse faire il utilise les clés interne de l'objet pour générer son id. Si on sait qu'une de nos clés (id par exemple) est unique dans la liste, autant lui spécifier avec track by pour lui simplifier son calcul et lui éviter d'ajouter des éléments inutiles au DOM.
On est ensuite passé sur le two-way binding qui est l'élément qui nous a fait rêver au début d'angular, mais qui reste un processus couteux. A partir de 2000 watchers, les performances commencent à en patir. Si on sait qu'on ne fait qu'afficher sans avoir besoin de modifier des données, on peut ajouter bo-text="user.name" sur l'élément sur lequel on itère pour qu'angular ne crée pas de two-way binding.
Il nous a fait un petit retour sur ngIf et ngShow et les cas d'usages pour chacun. ngIf ne va ajouter des éléments dans le DOM que si la condition est vraie, il ne faut donc pas l'utiliser si la condition change souvent, au risque de créer trop de rendering au browser. Au contraire, si le contenu affiché dans l'élément nécessite un processing intense, il vaut mieux le mettre dans un ngIf plutot qu'un ngShow. ngShow quand à lui est utile si on veut "cacher" des éléments dans le DOM pour les afficher plus tard rapidement.
Bien sur, il conseille d'activer le cache:true sur les ressources, et $q.all quand possible pour parallelliser les requetes aux API. Idem pour définir des resolve dans son router (à noter que si une seule des resolve fail, alors le controlleur cible ne sera pas instancier. Il peut donc être intéressant de ne définir qu'un seul resolve, qui englobe une promise custom avec $q.all et retourner un unique object avec des clés undefined si les sous-promises failent, et gérer les fallbacks dans le controlleur).
Finalement, il ne faut pas oublier que la performance ne se calcule pas en ms réelles, mais en perception utilisateur. Il peut donc parfois être intéressant d'utiliser des résolve pour afficher à l'user une page avec toutes les données, mais parfois de les afficher au fur et à mesure. A noter qu'en dessous de 100ms le cerveau humain considère une action comme immédiate. On peut donc afficher un spinner à l'utilisateur pour lui indiquer qu'une action est en cours, mais ne l'afficher que si le traitement prends plus de 100ms pour lui éviter un flicker inutile. Si on veut aller au bout des best practices, on peut commencer à afficher des placeholders pendant le chargement pour lui montrer que quelque chose se passe. Il est important aussi de lui laisser accès à des fonctions de base (sidebar, menu) pour lui permettre de naviguer si la navigation prends trop de temps (plutot que de se retrouver sur une page freezée et qu'il soit obligé de quitter la page).
Finalement John a fini par un troll en disant que si vraiment vous voulez des pages réactives qui se chargent vite, utilisez React.
SVG
Présentation molle et avec des soucis techniques. Au final on a juste (re)appris que SVG c'était cool parce que c'était vectoriel et donc ça scale aux résolutions. Mais surtout c'est du XML dans le DOM, donc ça se scripte en Angular très facilement et ça se style en CSS. Et on peut faire des formes complexes à base de suite de points pour faire par exemple une carte de france des régions.
Voila, voila.
Le talk était fait par un statisticien qui était passionné (et passionant) quand il parlait des données, mais semblait découvrir en Angular ce qui pour moi faisait partie des bases. Au final, d'un point de vue technique je n'ai rien appris, et d'un point de vue des données en elle-même, cela semblait certes le passioner, mais n'ayant pas la même fougue pour les nombres, ça m'est juste passé au dessus de la tête.