Présentation Zen (Livre)

28 février 2009 - 18:36 | Dans Livres et magazines, Marketing & Com' | 5 commentaires

Hum…
Si je devais faire simple, je dirais:
 » Si jamais dans votre métier ou dans vos études vous êtes amenés à faire une présentation avec slides (Powerpoint ou Keynote), s’il vous plaît, achetez ce bouquin !

Cela évitera à plein de gens sans défense de devoir subir des présentations merdiques, chiantes et moches…

S’il vous plaît, pensez à eux ! »

Tiens, ben en fait elle est très bien cette version simple ! 🙂
Je crois que ça suffira, vous savez ce qu’il vous reste à faire. Disons qu’il est l’équivalent de « Stratégie Océan bleu » pour ce qui est de l’art de faire des présentations.

Je ferai un autre article sur le sujet des présentations bientôt… (à savoir, d’ici 6 mois)

Table des matières:
PREPARATION

• Créativité, limites et contraintes
• Premier jet sur papier
• Construire une histoire

DESIGN

• Simplicité : pourquoi ça compte ?
• Composition des diapos : principes et techniques
• Exemples de diapos : images et texte

PRESTATION

• Une question de présence
• Prendre contact avec le public

ETAPE SUIVANTE

• Le Voyage commence

Post Mortem: « De Evolution à Little Big Society »

25 février 2009 - 19:44 | Dans Post Mortem | 7 commentaires

Il l’avait promis, il l’a fait ! 🙂

J’inaugure donc cette rubrique « post mortem » avec cet article écrit par « sourisdudesert » qui relate les gloires et déboires qu’il a eu pendant la réalisation de son jeu indépendant.

De son propre aveu « c’est très utile d’écrire un post mortem, c’est un peu comme une psychanalyse on se rend mieux compte d’où on est et pourquoi on y est ».

Si certains d’entre vous ont des post mortem à publier, n’hésitez pas à m’en envoyer.

Je lui passe donc la main:

————————–
Ce petit historique d’un jeu indépendant a pour but de vous donner une idée des difficultés rencontrées dans la conduite de projet de ce genre, de ce qui marche et de ce qui marche moins bien, et plus généralement d’illustrer de manière concrète quelques une des « 10 erreurs a ne pas commettre » de ce blog à travers une expérience concrète.

1ière tentative, Evolution

Le concept d’Evolution est de réaliser un jeu de stratégie historique tendant au réalisme. L’idée est partie à l’époque d’une critique de la série des Civilizations dont le gameplay évoluait finalement très peu au fur et à mesure des versions et privilégiait plutôt les aspects techniques (plus beau, séquences vidéos, 3d) et la diversification des items du jeu (unités, bâtiments, technologies). Le postulat de départ pour Evolution était de dire qu’on pouvait faire quelque chose de moins impressionnant techniquement mais qui en contrepartie donne au joueur une simulation historique bien plus réaliste.

En 2000, l’idée est postée sur un forum de fans de Civilization et déclenche aussitôt l’enthousiasme de la communauté. L’idée fait son chemin et un site internet est créé. Pendant deux a trois mois, un important travail collaboratif autour du gameplay est abattu avec des idées qui fusent dans toutes les directions. Un document de synthèse – énorme, plus d’une trentaine de pages bien denses – est ensuite rédigé, qui est plus un condensé d’idées sur les jeux de stratégie historique qu’une réelle spécification.

Cette période du projet a été extrêmement enrichissante pour tous les contributeurs, et ses résultats ont été très positifs. Je reçois encore aujourd’hui des mails de personnes m’expliquant qu’on avait imaginé le jeu de leurs rêves. Et bien entendu trois mois plus tard … plus rien, ou quasiment rien.

Les erreurs commises paraissent évidentes avec le recul, et ont une bonne place dans les « erreurs classiques » de ce blog:

• Bien entendu, le concept du jeu était trop ambitieux. Pire: en répondant systématiquement que l’on voulait ‘tout’ simuler, les délimitations exactes du jeu sont devenues progressivement floues.
• Face à cette complexité, pas de stratégie de développement. Même dans les projets moins complexes, il faut avoir une idée de ce qu’on va développer dans les phases A, B, et C du projet ainsi que des plans alternatifs en cas d’imprévu (ou plutôt: lorsque l’imprévu arrive). Dans notre cas, nous avions bâti une montagne sans jamais ébaucher l’amorce d’un chemin pour la gravir.

Face à un document de description du gameplay énorme et aucune stratégie pour l’aborder, le développement du jeu s’est perdu quelque part et on a jamais trop su ni comment ni pourquoi il s’était arrêté là. Bien entendu la quasi totalité des réalisations étaient à jeter puisqu’aucun plan B n’avait été prévu. Retour à la case départ.

En 2002, l’un des contributeurs du projet initial tenta a nouveau l’aventure, sans plus de succès. Je ne m’aventurerai pas à déterminer les raisons de cet échec à sa place, mais elles sont plus où moins les mêmes.

Les leçons à retenir ?

• Ce n’est pas parce qu’on déclenche l’enthousiasme qu’on va réussir, c’est au contraire BEAUCOUP plus dur de réussir car gérer l’enthousiasme des autres est une frustration permanente pour soi même.
• Car gérer l’enthousiasme, il n’y a qu’une méthode: savoir dire non, même si ça a l’effet d’une douche froide sur les contributeurs du projet.
• Il faut au moins une ébauche de feuille de route qui réponde à la question « quelle est la prochaine étape », et bien entendu que cette étape soit réaliste.

2 i̬me tentative РEvolution

En 2004, seconde tentative. Pourquoi à ce moment ? Tout simplement car c’est à cette période que j’ai maîtrisé la programmation OpenGl à un niveau « semi pro », et que ce genre de connaissance vous donne un sentiment de puissance qui conduit à crier haut et fort: « maintenant, je peux TOUT faire ».

Surprise, on ne devient pas subitement Victor Hugo dès lors qu’on sait écrire. Cela parait évident, certes, mais le fait est qu’une maîtrise à peu près correcte d’un moteur 3D donne des résultats graphiquement impressionnants et qu’on a réellement l’impression d’être devenu un concepteur de jeux pro simplement parce qu’on a compris comment marchait une matrice de transformation.

Ce sentiment de puissance conduit naturellement à relancer des projets jugés infaisables par le passé. J’ai donc repris Evolution en commençant par ce qui me paraissait le plus difficile: le moteur de rendu 3D et tout un système de gestion de fenêtres et de contrôles (un window manager) en OpenGl. Le jeu ? Bah, si on se montre capable de faire ce moteur de rendu, vous n’allez pas me dire qu’on est pas capable de faire le jeu lui même, n’est ce pas ?

La suite, vous pouvez l’imaginer: une fois réalisée la partie techniquement la plus difficile, je me suis retrouvé une fois de plus face a la montagne des idées du jeu, qui pouvaient se résumer de la manière suivante: « Evolution est une simulation historique à un niveau de détail et de réalisme très poussé. Pour éviter le micro-management, le joueur est assisté d’intelligences artificielles et se place ainsi au sommet d’une hiérarchie d’intelligences qu’il gère comme un roi gère sa cour. »

Inutile de dire qu’après avoir vaincu le Mont Blanc, j’ai perdu ma motivation face a l’Everest.

Quelles leçons en tirer ?

• L’élément qui motive la création d’un jeu doit être le jeu lui même, et pas le fait de vaincre les aspects techniques de sa réalisation.
• On ne démarre pas un projet de cette ampleur parce qu’on a appris une nouvelle technique. Non seulement c’est un risque pour la motivation une fois l’écueil technique vaincu mais c’est en plus le meilleur moyen de faire de mauvais choix techniques dès le départ puisque ceux ci vont précéder le game design.
• Ne jamais sous estimer la réalisation du moteur du jeu lui-même. Il y a des algorithmes très simples permettant de faire voler une centaine de X-Wings à travers une escadre de Star Destroyers, mais il n’y a pas d’algorithme simple permettant d’avoir une intelligence artificielle qui assiste le joueur. Je le dis d’une autre manière: ce n’est pas parce qu’une chose n’est pas impressionnante visuellement qu’elle va être facile à développer, c’est le contraire: vous trouverez toujours des tonnes d’exemples sur le web pour les choses impressionnantes, et jamais pour le bidule indispensable à votre jeu qui parait tout simple mais que vous devrez faire tout seul.

3 i̬me tentative РFree Evolution

Ce qui nous mène en 2006, un an après l’échec précédent. Cette fois ci et compte tenu des leçons du passé, le game design du jeu a sensiblement évolué, ce qui a par ailleurs motivé le changement de nom vers Free Evolution. Du coté du jeu, la simplification a été assez radicale:

• Plus du tout d’intelligences artificielles pour « assister » les joueurs, car le jeu devient multijoueurs: la collaboration entre joueurs permet de faire face a la complexité de la simulation.
• Plus besoin d’IA pour les adversaires du joueur, puisque là encore le jeu est multijoueurs.
• Grosse simplification de la simulation elle même. Ça reste complexe – puisque c’est le concept du jeu qui veut ça – mais c’est pensé pour être abordable techniquement même si on doit sacrifier une dose de réalisme au passage.
• Paradoxalement, le jeu gagne en intérêt et en originalité: plutôt que de faire un énième jeu de guerre dans lequel le joueur est face à tous les autres, le joueur n’est qu’un notable parmi d’autre

Ayant pratiqué et surpratiqué le C++, il ne faisait aucun doute que c’est dans ce language que je devais relancer ce projet, en réutilisant au passage les briques OpenGl de la dernière tentative – ce qui est fait n’est plus à faire – sans bien sûr retomber dans les lourdeurs d’un moteur de jeu trop complexe.

Le jeu étant massivement multijoueurs online, la couche « réseau » est réalisée en premier: appels serveur, notifications des joueurs, mise en cache des données, etc… Ce dont il faut se rendre compte, c’est l’investissement que cela représente car pour un projet amateur le temps disponible est naturellement limité:

• 8 mois pour la partie réseau et les bases du jeu
• 6 mois de plus pour que le client graphique ressemble a quelque chose et que le tout soit jouable un minimum.

Pour noël 2007: joli cadeau. La dernière version publiée a été considérée comme suffisamment jouable par les joueurs pour qu’une dizaine de courageux se montrent intéressés et commencent à jouer dans l’univers créé. De plus, j’ai réussi a recruter des joueurs au delà du « premier cercle », constitué des copains et des anciens d’Evolution.

C’est malgré tout une victoire a la Pyrrus… Je découvre que toute évolution du jeu a un coût en temps qui est à la mesure de l’investissement initial. Même si la version proposée est jouable, les derniers travaux a accomplir représentent encore des mois de travail, et plus ça avance plus on s’englue dans le code. Pire: certains choix de game design sont finalement mauvais, ce qui arrive dans 99% des projets, mais pour un projet amateur qui est déjà un monstre en terme de taille de code ces adaptations nécessaires coûtent un temps fou. Du coup, les évolutions du jeu se font attendre et la frustration commence à arriver du coté des joueurs comme du mien.

Six mois plus tard (été 2008), la dernière version du jeu « n’arrive pas » a sortir. L’impression générale est que chaque fois que l’on se dit « c’est la
dernière grosse brique à mettre en place », on découvre qu’un paquet d’autres attendent derrière. Pour autant, le concept du jeu est bon de l’avis général, ce qui rajoute encore à la frustration ambiante.

Les leçons à retenir sont ici nombreuses:

• On ne peux pas tomber juste du premier coup en terme de game design. La conception d’un jeu est le résultat d’un aller retour avec les joueurs, et plus ce retour des joueurs intervient tôt moins il en coûte de changer de cap.
• Corollaire du précédent: quelque soit la complexité du jeu visé, il faut commencer par faire simple afin de valider le plus tôt possible le concept du jeu avec les joueurs. Autrement dit: retirer du jeu tout ce qui n’est pas essentiel à son concept de base.
• Dans le cadre d’un projet amateur, le meilleur choix technique n’est pas seulement lié à ce que vous VOULEZ faire, mais aussi à ce que vous POUVEZ faire. Le C++ est probablement le meilleur choix pour un jeu de stratégie MMO, mais la somme de travail à réaliser pour arriver ne serait ce qu’à une maquette est bien trop importante.

4 i̬me et derni̬re tentative РLittle Big Society

Même si le chemin suivi n’a pas été le plus simple, la tentative précédente a permis de faire valider le concept du jeu par les joueurs. Il est apparu par la suite que cet acquis a donné un sacré coup d’accélérateur au développement du jeu: quand on sait ce que l’on veut, on progresse trois fois plus vite et surtout on ne perd pas de temps.

Afin de reconfigurer le projet, je cherche alors des conseils a droite et a gauche auprès d’un peu tout le monde: ceux qui connaissent l’historique du projet ou pas, ceux qui y ont joué ou pas, etc… C’est d’ailleurs dans ce cadre que j’ai demandé l’avis « Conquérir le Monde ».

De ces consultations, il est ressorti plusieurs choses:

• Ce que j’ai déjà dit: le concept de jeu tient la route.
• 90% du développement a été effectué… et il subsiste les 90% restants.
• Peu a été fait pour le jeu, beaucoup sur les aspects techniques
• Le titre est peu adapté au jeu visé

La méthode qui a été suivie a alors été: « disposant d’un concept de jeu qui tient la route, comment prouver qu’il est bon ? ». En effet, une fois le concept de jeu éprouvé via un prototype – même expérimental -, la réalisation du jeu va pouvoir s’appuyer sur plusieurs choses:

• Un surcroît de motivation, car on sait que l’on va quelque part
• Des joueurs pilotes, ce qui permet construire le jeu avec eux
• Éventuellement, la collaboration d’autres développeurs sur une base claire (projet défini et embryon de jeu disponible)

Prouver, cela signifie réaliser une version beta du jeu auquel il manque tout excepté l’essentiel qui fait le sel du jeu. Dans mon cas, cela a signifié une simplification drastique du concept: « les joueurs incarnent des chefs de clan qui interagissent dans les domaines politique, économique et militaire pour assouvir leurs soifs de pouvoir ». Il faut donc un territoire découpé en provinces, dans lequel les joueurs peuvent produire et échanger des ressources qui leur servent a rendre leur population heureuse et à construire des armées permettant de tout démolir. Pour que les joueurs puissent interagir, il faut d’une part quelques briques de jeu (ex. dons, contrats, impots…), et d’autre part un système type « réseau social » basique. Enfin, le titre du jeu devient « Little Big Society », qui reflète mieux son ambiance.

Pour la partie technique, on simplifie là aussi: le jeu sera à 100% jouable en navigateur avec une technologie « coté serveur » (PHP) qui n’est pas la meilleure pour l’interactivité mais qui est d’une simplicité de mise en place exemplaire: gérer tout un tas de joueurs/visiteurs en même temps est la fonction même d’un site web.

Le développement a commencé début octobre 2008. Aujourd’hui, après 2 mois de développement (moteur de jeu), 1 mois de stabilisation, et un dernier mois de cosmétique, le jeu vient de publier sa première version officielle qui est plus jouable que n’importe laquelle des précédentes « tentatives ». Les demandes des joueurs sont intégrées assez rapidement, ce qui montre que le code est sain et évolutif. Le nombre de bugs bloquants est moins importants que dans Free Evolution, tout simplement parce que les mécanismes sont plus simples et reposent sur une architecture (PHP) déjà massivement utilisée pour les jeux de ce genre.

http://littlebigsociety.com

Conclusion

Bien sûr, au stade actuel il est trop tôt pour savoir si une « erreur classique » ne subsiste pas quelque part, mais j’espère vous avoir persuadé de l’importance et de la pertinence des conseils prodigués dans les blogs comme celui ci. Ces conseils valent de l’or tout simplement parce que ce n’est pas des jours ou des semaines de travail qu’ils font gagner, mais bien des mois ou des années. Reste qu’il en est des projets de jeu comme pour les projets en règle général: écouter les conseils réclame souvent pas mal d’autocritiques et de remise en question. A vous de voir.