Présentations: le syndrome du stagiaire

7 mars 2010 - 15:28 | Dans Marketing & Com' | 7 commentaires

J’avais vaguement parlé des présentations lors de mon article sur le livre Présentation zen.
Par présentation, on entend ici une présentation devant un public, généralement avec un powerpoint.

Étant un geek de base, je n’ai jamais vraiment aimé faire des présentations de ce genre lors de mes études, mais par la suite je me suis intéressé à cet « art » jusqu’à donner des cours sur le sujet.

Ce qu’il faut savoir, c’est que la majorité des présentations powerpoint sont nazes.
Qui s’est déjà retrouvé à un cours de lecture où le présentateur lit son slide avec vous ? C’est passionnant non ?

Il y a des tas de raisons pour expliquer cela.
Je pense que l’une des causes principales, surtout pour ceux qui sont sortis des études il y a moins de 10 ans, est ce que j’appelle « le syndrome du stagiaire ».

En effet, lorsque l’on fait un stage on a souvent une présentation powerpoint à faire à la fin qui est censée nous servir d’entrainement pour bien savoir les faire.

Pour ceux qui ne connaissent pas, une soutenance de stage ça ressemble en gros à ça :

NB: je ne sais plus où j’ai trouvé cette image, désolé pour la source…

On a une ou plusieurs personnes plus ou moins stressée(s) devant un jury de profs (ou de tuteurs de stages) qui présente(nt) tout le travail formidable qu’ils ont effectué durant leur stage.

Le gros problème, c’est que faire ce type de présentations donne 2 très grosses mauvaises habitudes aux stagiaires qu’ils garderont pour la plupart par la suite.

1- Le problème du « moi je » :

Le principe d’un stage est le suivant:
Рvous avez plus ou moins gland̩ boss̩ dans un stage, lui m̻me plus ou moins int̩ressant
– à la fin on vous file une note que vous espérez la plus haute possible
– cette note se fait en fonction d’un rapport écrit et d’une présentation orale de votre travail

Par conséquent, vous allez essayer de vous mettre en valeur lors de votre présentation pour avoir une bonne note. Cela se traduit grossièrement par quelque chose comme :

« Alors moi j’ai fait ci, moi j’ai fait ça, là y’a une photo de moi sur l’ordi, là c’est le logiciel que j’ai installé moi, là c’est le rapport que j’ai fait qui est super bien, là c’est le patron avec qui je m’entends super bien, blah blah blah »

Vous allez me dire que c’est un peu le principe d’une présentation de stage, et je suis bien d’accord.
D’ailleurs, le public est là pour entendre ça, donc pas de problème.

Le problème vient qu’une fois sorti des études, les gens ne viennent plus à vos présentations pour vous donner une note.
S’ils écoutent votre présentation, c’est soit pour apprendre quelque chose qui les intéresse, pour découvrir un produit qui peut résoudre leurs problèmes, etc.

Donc au final, ils n’en ont rien à faire de votre vie, de votre entreprise, de savoir que votre produit est numéro 1 ou présent dans 50 pays ou même de voir que vous êtes super intelligent.

Comme on dit souvent en marketing, il faut vendre les avantages pour le client et non les caractéristiques du produit.
Donc au lieu de faire une super présentation sur votre produit/service/jeu que vous vendez en décrivant votre entreprise/moteur 3D/jeu révolutionnaire, expliquez plutôt que vous comprenez les problèmes de vos clients et comment vous comptez les résoudre avec votre solution.

Ah oui, et ce n’est pas qu’une erreur de débutant. J’ai vu une présentation de Microsoft France lors d’un techdays où ils passaient toute l’introduction à expliquer en quoi leur évènement était une réussite, qu’il y avait x visiteurs, x partenaires, x entreprises invitées, x sessions prévues, x ordinateurs installés en démonstrations, x salles de prévues, etc…
Oui, c’est bien beau, vous êtes super forts… mais écouter des gens se lancer des fleurs ça apporte quoi au gars qui est dans la salle ?

Règle d’or: toujours se mettre à la place à de l’auditoire en préparant une présentation, et ne parler que de ce qui peut l’intéresser

2- Le problème du « regardez comme je suis fort » :

Toujours sur la soutenance de stage, on a souvent tendance à rendre les choses complexes pour montrer que l’on a bossé très dur, que l’on appris plein de choses, que l’on est devenu très compétent et que l’on a donc mérité une très bonne note pour ça.
Du coup, cela justifie les 10 slides présentant en détails la technologie multithreadée long polling bx15 à retour de variation asynchrone doublée dash deux en un 5.0 beta que vous avez utilisé pendant le stage.

Vous allez impressionner tout le monde, ça c’est sûr.

Maintenant, gardez en tête qu’en dehors des études la plupart du temps:
– vos auditeurs ne seront pas des experts dans le domaine (sauf conf technique, et encore…)
– vos auditeurs NE SOUHAITENT PAS devenir des experts dans le domaine, ils veulent juste savoir à quoi ça sert et quel est le principe général
Рplus vous facilitez leur compr̩hension, plus ils vous en seront reconnaissants
– plus ils comprendront simplement quelque chose de compliqué, plus ils vous considéreront comme quelqu’un de brillant pour avoir réussi à bien l’expliquer
– il vaut mieux être percutant avec une seule information qu’être chiant exhaustif sur 10

Règle d’or: simplifiez ! Il vaut mieux que l’auditoire ne retienne qu’une idée simple mais forte que de lutter pour leur faire comprendre 15 points compliqués qu’ils auront oublié dans 15 minutes

Voilà, juste avec ces deux règles en tête, on améliore de 70% la qualité des présentations de ce genre.

Il y a encore des tonnes de choses à dire sur le sujet, mais c’est tout pour aujourd’hui !

Livres recommandés sur ce thème:

Erreur classique n°10: le plantage post-proto

16 février 2010 - 19:51 | Dans Création de jeux vidéo, Erreurs classiques | 19 commentaires

D’après une étude pas du tout objective (juste une impression en fait…), il semblerait qu’il y ait deux moments critiques dans la vie des projets amateurs, deux moments où la plupart des projets se plantent.

Le premier moment, c’est juste au début, quand le projet est vraiment foireux et que la bande de collégiens qui voulait faire un « WOW en mieux » clashe parce qu’ils ne sont pas d’accords sur la couleur des poils des loup-garous qui seront présents dans le jeu.
Ça, c’est classique, on l’a déjà abordé.

Le deuxième moment est plus étrange, on voit le projet avancer, des screenshots arrivent, c’est jouable, il y a même un prototype, une petite communauté qui se crée et soudain « pouf »… le projet s’arrête: soit d’un coup avec une annonce, soit il ne donne plus signe de vie et disparaît à petit feu.

Je me suis donc demandé pourquoi. Surtout que c’est un problème qui m’est déjà arrivé plusieurs fois.

Voici donc les principales causes selon moi:

1. Trop de différences par rapport à ce qui était souhaité :

C’est ce qui arrive quand on a passé beaucoup de temps pour atteindre le prototype et que l’on se rend compte qu’il reste encore énormément de chemin pour atteindre ce que l’on souhaitait au début. Si le développement a déjà pris plusieurs années et que l’on se rend compte qu’il reste encore plusieurs années devant soi, ça décourage.

Solution: faire des projets plus simples

2. « Les autres 90% » :

En développement informatique, on dit qu’une fois les premiers 90% du logiciel développés, il ne reste plus qu’à faire les « autres » 90%.
Cela a un même un nom, la règle des 90-90 : http://en.wikipedia.org/wiki/Ninety-ninety_rule.

En fait, cela vient de l’impression d’avancer très vite au début et de faire du sur place vers la fin.
Par exemple pour un projet de jeu vidéo, on met en place Ogre pour avoir un moteur 3d qui marche, on a un début de gameplay, etc… Ce qui fait qu’on progresse très vite au début. Au bout d’un moment, il ne reste plus que les détails… en gros équilibrer le gameplay, faire les menus, les options, l’aide en ligne, paufiner l’IA, enlever le lag du jeu en réseau, débugger, traduire les textes en anglais, etc… Presque rien quoi… (ce que l’on appelle le polishing).

Sauf qu’en fait, en cumulant tous les « petits détails » de ce genre, cela prend autant de temps (sinon plus) que tout ce qui a été fait avant.

Ceci provoque tout un tas de désagréments:

• On a l’impression de ne plus avancer car les résultats des changements sont minimes
• On ne voit pas la fin du projet car il y a toujours quelque chose à modifier
• C’est un travail ennuyeux
• Il n’y a plus de créativité, plus de challenge, ce n’est que du travail « idiot »
• Quand on voit tout ce qu’il reste à faire, on a plus envie de le faire

Solution : simplifier le projet, anticiper ces étapes

3. Le contenu :

Faire un proto avec une map de test, c’est marrant.
Faire des niveaux ou des graphismes à la chaîne, c’est moins marrant… ça peut même être lassant, voire décourageant.

Solution : éviter les jeux à contenu, ou avoir quelqu’un qui aime bien faire ça dans l’équipe.

4. La sensation « d’avoir atteint sa vision » :

Quand on veut créer un jeu amateur, on a plein d’images en tête sur ce à quoi ça ressemblera quand ça sera fini.
Le truc, c’est que lorsqu’on atteint le proto et que celui-ci est conforme aux attentes, on se dit « ouais, ça marche, j’ai enfin réussi ce que je voulais faire ».
Comme on fait abstraction des détails qui manquent (les autres 90%) et qui peuvent attendre, on a l’impression d’avoir atteint sa vision et on relâche les efforts.
Et là… c’est le drame, on perd le momentum (= la lancée qu’on avait) et c’est très dur de le récupérer.

Solution : anticiper cette sensation pour redoubler d’efforts à ce moment là

5. Les problèmes techniques non anticipés :

Quand on est tout seul sur son projet, tout va à peu près bien.
Quand on commence à avoir des joueurs, il faut gérer plein de choses supplémentaires:

• les problèmes de configuration et de compatibilité (système d’exploitation, drivers…)
• les problèmes de taille d’écran
• les problèmes de lag pour le jeu sur internet
• les problèmes de scalabilité quand le jeu est trop gourmand niveau serveur
• etc.

Tout cela démotive car on doit régler les problèmes des autres que l’on a pas chez soi, ils sont souvent inattendus et ne font pas progresser le jeu d’un point de vue créatif.

On rajoute à cela tous les problèmes techniques liés à l’apprentissage de technos différentes (rendu graphique, moteur physique, IA, etc.), ce qui allonge la liste de toutes les choses à régler.

Solution : ne pas avoir de projets sur lesquels il faut apprendre trop de choses techniques en même temps, ça limitera les surprises.

6. La différence de qualité :

Si le projet est conséquent, on apprend beaucoup au cours de son développement. Le problème est que la différence de qualité entre ce qui a été fait au début et maintenant (qualité des graphismes, des maps, du code, etc.) est parfois telle que le jeu est devenu beaucoup trop inégal.
Comme continuer sur une base instable n’est pas une bonne idée, généralement soit le projet est recommencé du début « en plus propre », soit abandonné au profit d’un autre projet.

Solution : privilégier les projets courts, surtout si ce projet sert d’apprentissage

7. Les engueulades dans l’équipe :

Si le projet commence à avoir du potentiel, il arrive que l’équipe se déchire pour divergences d’opinions. Soit parce que certains veulent avoir une plus grosse part du gâteau que prévu, soit parce que rien n’a été prévu et que chacun a sa propre vision de ce que le jeu pourrait lui rapporter…

Une autre raison peut être un désaccord sur l’objectif réel du jeu (gratuit, open source, payant, etc.) ou de son style graphique une fois un proto technique réalisé.

Solution: bien définir les rôles et prévoir un accord à l’avance avant de s’engager avec quelqu’un, notamment sur la propriété des éléments réalisés en cas de départ de la personne.

8. Le départ des membres qualifiés :

Si l’équipe est composée de personnes compétentes et que le projet commence à se faire connaître, celles ci vont sûrement avoir des propositions rémunérées pour leur talent… A ce moment là, il sera dur de les garder pour un jeu amateur…

De plus, les nouveaux qui pourraient être recrutés pour les remplacer risquent d’être largués.

Solution: avoir des projets courts, particulièrement s’ils sont bénévoles. Si le projet est à visée commerciale, l’objectif est d’être rentable rapidement pour pouvoir payer l’équipe.

9. Le nouveau super projet qui est vachement mieux que l’actuel :

Ben oui, vous avez une super nouvelle idée qui est vachement mieux que le projet actuel. Et puis de toute façon votre code il est pas beau, il faudrait le rendre plus flexible. Et puis il y a ce nouveau moteur 3D qui a l’air bien mieux que Ogre/Irrlicht/Unity/Whatever. Quoique vous avez vu un tuto sur « comment créer son propre moteur 3D » et ça a pas l’air si compliqué que ça en fait…

De plus, c’est à ce moment que vous allez voir tous les défauts du projet actuel. Il est pas assez ceci, un peu trop cela… et au final, est-ce que ça vaut vraiment le coup de le finir ?

Solution : Savoir se fixer sur un projet. Pas toujours facile. Cela dépend aussi de vos objectifs: apprendre ou finir un projet ?

10. Être un concepteur et non un réalisateur :

Certaines personnes sont très bonnes pour concevoir des projets, élaborer la stratégie, les différents éléments du concept, etc.
D’autres personnes sont très bonnes pour les réaliser, passer au concret, appliquer les stratégies.

Être les deux en même temps n’est pas toujours facile.

Solution : être les deux, ou trouver les personnes qui vous complètent

Conclusion :
Tout ceci peut être changé par des facteurs aggravants :

– Être sur plusieurs projets en même temps (à éviter au maximum car un projet va toujours prendre le dessus sur un autre)
РComplexit̩ du projet
– Facteurs externes qui jouent sur le moral

Si je devais résumer, la plupart des causes viennent de la complexité du projet. Donc :

• Faîtes court
• Faîtes simple
• Créez un momentum pour bosser d’une traite sur le jeu et qu’il n’y ait pas de temps morts, surtout si vous êtes une équipe
• Méfiez vous de l’impression d’aller super vite au début
• Une fois fini, recommencez en augmentant légèrement la difficulté

Et vous, pour quelles raisons votre projet a planté après le proto ?

Résurrection

31 janvier 2010 - 23:15 | Dans News | 7 commentaires

Hum…

Ah tiens, j’ai un blog ici moi…

Bon ok ok, suite à la demande générale, je vais essayer de le faire revivre et de faire plus de posts que l’année dernière (ça devrait pas être trop dur).

J’ai pas mal d’idées d’articles en attente (un peu de jeu vidéo, de l’entrepreneuriat, des systèmes d’organisation pour geeks, des bouquins à chroniquer, des conseils sur l’art de faire des présentations, etc.)

Comme j’ai grandement réduit la liste des projets dans lesquels j’étais impliqué (je ne m’en sortais plus sinon), ça devrait laisser un peu de temps pour écrire tout ça.

En attendant, voici quelques liens pour patienter:
Dossier Faire des jeux – Intro
Dossier Faire des jeux – partie I – la 2D
Dossier Faire des jeux – partie II – La 3D
Faire des jeux – partie III – Consoles & Smartphones

Post Mortem: Fortress Forever

14 avril 2009 - 22:18 | Dans Post Mortem | 12 commentaires

Pas d’article exclusif ici mais un lien rapide vers un post mortem concernant les mods amateurs:

Le lien en anglais: http://defragdev.com/blog/?cat=6
Le résumé en français: http://blogs.wefrag.com/channie/2009/04/14/post-mortem-fortress-forever/

Et un post-mortem Stargate en cadeau: http://www.stargatetcsource.com/fr/news/

Si vous en connaissez d’autres, n’hésitez pas à les mettre en commentaire.

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.

Question d’un lecteur: « Que faire pour mieux vendre mon jeu »

28 décembre 2008 - 18:52 | Dans Questions - Réponses | 9 commentaires

Une question portant sur des jeux finis et sur leur commercialisation qui pose certains problèmes.
Et pour commencer, pardon au lecteur pour avoir mis autant de temps à répondre, car là j’ai battu un record je crois 🙂

Bonjour Dam’s,

je viens de finir mon troisième jeu « Orisha », la suite de « Alhomepage, les premières expériences » sorti l’an dernier. « Orisha » est disponible depuis septembre. Le lien : http://www.alhomepage.com

Comme son prédécesseur, c’est jeu de type Myst-like (réflexion/énigme) que j’ai réalisé seul. Le jeu est développé sous Flash/Zinc et comprend des bandes musicales originales, un environnement 3D précalculé, des vidéos et un scénario particulièrement travaillé.

Le jeu s’adresse à une gamme assez large de joueurs : les nostalgiques de Myst et Riven, les joueurs occasionnels plutôt adultes en attente de jeux vidéo un peu plus sérieux que la plupart des titres sur le marché, des gens qui aiment qu’on « leur raconte une histoire » sans avoir à sauter sur une plateforme/tuer un million de monstres/connaître l’histoire de France.

L’objectif du projet était de donner une suite honorable aux « Premières expériences » qui, a fortiori, est un jeu tirant trop du côté des puzzle-games. Avec « Orisha », j’ai voulu donner le maximum dans chaque domaine ; visuel, musical, narratif. L’arrière-plan philosophique (sans orgueil) du jeu traite de la volonté et du rapport entre la créature et son créateur. Cela ne fait pas pour autant du jeu un produit imbuvable : Orisha reste un jeu où on s’amuse sans trop se prendre la tête !

Les deux projets sont autoédités. Je suis en SARL et je sors des jeux vidéo parce que j’avais envie de le faire depuis mon parcours à l’école des Gobelins. Faute d’avoir suivi des formations dans le secteur, de moyens et de relations dans le milieu, je fais donc de l’auto-prod. J’ai vendu à l’heure actuelle plus de la moitié des produits pour les deux projets (petits tirages en sérigraphie).

Côté communication, j’ai contacté plusieurs forums d’amateurs de ce genre de jeux. J’ai d’ailleurs participé à une rencontre de joueurs l’an dernier qui étaient étonnés par mes réalisations, leur qualité. Je suis également référencé sur des sites généralistes (téléchargement de la démo technique gratuite). Quelques interviews également. J’ai enfin contacté des forums de techniciens et là, pas de mystère, ça n’intéresse manifestement personne.

Mais je stagne. Je ne sais pas trop quoi faire, qui contacter. J’ai épuisé le filon « bouche à oreille », « copinage », « forums spécialisés ». Que puis-je faire maintenant ? Avez-vous des pistes ?

Enfin, j’ai découvert que la plupart des portails de jeu vidéo sont très « snobants ». Également du côté des associations de « soutien aux créateurs » où leur action est trop en amont par rapport à ma situation. Ou bien ils ne répondent pas. Les FlashFestival et autres concours de création sont aussi très fermés, certainement par élitisme.

Dans l’attente de votre réponse
Cordialement

Alexandre Venet (AL)

Ok,
je vais donc procéder par thème. Pour simplifier, je vais m’intéresser qu’au dernier jeu: Orisha.

Le jeu en lui même
Clairement, chapeau !
C’est joli, ça a un style propre, ça a son ambiance, et c’est très adapté au style du jeu.

La démo
Là par contre, gros point négatif. La démo technique ne permet que de faire un aller retour sur 3-4 plans… et c’est tout !
Et là, ça fait pire que mieux:

• On a l’impression d’avoir perdu notre temps ! (quel intérêt de faire un aller retour dans un couloir ?)
• On apprend rien de l’histoire qui peut nous donner l’eau à la bouche
• On ne voit pas assez de gameplay qui peut donner envie
• Si la démo se boucle en 30 secondes, on se dit que le jeu doit durer 10 minutes à tout casser !

Bref, en jouant à la démo, ça fait presque tout sauf donner envie d’acheter le jeu ! Il faut revoir ce point. Il faut que ta démo soit vraiment une accroche et qu’à la fin de cette démo le joueur se dise:
« Oh putain il a l’air trop cool ce jeu, il faut que je l’achète maintenant pour connaître la suite sinon je vais avoir une vie trop malheureuse si je sais pas !! ».
(bon, ptête pas à ce point là mais un peu quand même)

Ergonomie
Je ne suis pas expert en game design/ergonomie/tout ça, et puis on ne voit pas grand chose à cause de la durée de la démo, mais je trouve que certaines choses sont trop complexes et n’ont pas lieu d’être.
Exemples:

• Le bouton pour avancer est tellement pas évident qu’il y a un panneau expliquant ce que ça veut dire… Ça serait pas plus simple de juste mettre une flèche (stylisée) vers l’avant ?
• Les menus m’ont l’air un peu trop confus avec des icônes trop petites ou des étapes dont on se demande l’intérêt (genre d’avoir 10 choix de profils pour une démo qui dure 30 secondes)

Ok, donc la première étape, c’est de changer tout ça pour améliorer le jeu et son attractivité.
Maintenant passons au :

Site Internet
Alors premier point, je n’aime pas du tout les sites « full flash »…
Ça a plusieurs inconvénients, on ne peut pas faire de control + click pour ouvrir dans un nouveau tab, il faut se taper les animations, le son, etc… Bon bref… Là c’est « moins grave » car c’est un site de présentation d’un jeu, mais c’est juste par principe, faut que je râle dès que je vois un site full flash 🙂

Par contre un autre problème, peut être plus important dans ton cas, c’est que c’est un site vitrine. Il n’y a aucune interaction avec tes joueurs potentiels. Ils viennent, il regardent si ça plaît ou pas et ils ne reviennent plus. Il faudrait changer cela, et la meilleure méthode pour commencer serait peut être de mettre tout simplement un blog en place pour montrer l’avancement de tes projets, que les visiteurs s’y intéressent et qu’ils puissent communiquer avec toi par commentaires interposés.
Par contre il faut éviter le forum à cette étape, il risque d’être désert.

Comme tu es tout seul sur ton projet, il faut que tu joues sur l’aspect « découvrez le mec qui fait ça derrière, oh qu’il est sympa ! ». C’est ce qui a fait le succès de lafraise.com à ses débuts, le fait que le gars racontait toute la création de la boîte dans son blog.

Aspect communication – business
Si ça ne marche pas super à mon avis, c’est que toute la com’ que tu as pu faire a du emmener les visiteurs vers ton site et ils ont du se dire la même chose que moi: « c’est joli mais la démo ne donne pas envie ».

Conseils:
Ce que je vois à faire de mon point de vue:

• Corriger les petits défauts d’ergonomie du jeu
• Faire une vraie démo
• Faire tester le jeu et la démo à des personnes qui te diront vraiment tout ce qui ne va pas dedans (pas à quelqu’un de ta famille qui va te dire que c’est génial pour te faire plaisir). Après tu fais tester ta démo à quelqu’un qui n’a jamais joué à ton jeu, et tant que personne n’est prêt à vouloir acheter le jeu une fois la démo finie, c’est qu’il faut encore améliorer le jeu et/ou la démo !
• Une fois ton jeu et ta démo vraiment prêts, retourne faire un tour sur les sites dédiés aux jeux d’aventures, file des versions gratos aux sites et aux personnes ayant un blog pour qu’ils te fassent de la pub
• Être référencé sur un site généraliste: je doute que ça serve à grand chose, tu vas être au fond d’un catalogue où des gens vont peut être te trouver par accident…
• Rend ton site plus interactif avec ses visiteurs
• Contacte les portails de jeux casual pour voir s’ils peuvent être intéressés pour distribuer ton jeu
• Contacte les éditeurs de jeux « budget » (Micro Application, Mindscape, etc.) pour voir si ça peut les intéresser

Si avec ça rien ne marche, ben rajoute des filles dévêtues dans ton jeu 🙂