Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

02/07/2009

Project Bootstrapping

Tous les projets ont pour origines au mieux une vision, au pire une intention, dans la tête d’une personne seulement (ou une poignée, plus rarement), mais peu de projets peuvent s’épanouir de par eux même. Faire grandir un projet requiert de réunir un certain nombre de personnes, chacune avec des compétences spécifiques et probablement une façon de voir les choses différente.

 

 

Jusque là, rien de très surprenant.

 

 

Quelque soit le contexte, grande ou petite entreprise, projet d’envergure ou à court terme, il y a toujours un premier document, une première passe, une première maquette, dont le propos est de « bootstrapper » le projet.

 

 

Ce n’est pas tant que le contenu ou la forme de cette initialisation soit vraiment importante – peu de projets peuvent se targuer d’avoir été « spot on » dès le départ. Un projet va vivre, évoluer, grandir ou se modifier, et il est parfaitement possible que le résultat final se retrouve à des lieux de l’intention initiale.

 

 

Non, ce qui fait que cette passe est si importante, c’est qu’elle conditionne de façon assez déterminante la survie d’un projet. D’abord parce qu’il est facile d’arrêter un projet à cette phase là (très peu d’investissements, très peu de conséquences). Ensuite la capacité à convaincre, à rassembler ou à mobilier une équipe autour de se projet dépend grandement de la qualité ce cette phase.

 

 

Une personne en charge de bootstrapper un projet (que cela soit par sa propre initiative ou par assignement) a donc une lourde responsabilité. Il lui faut réunir le strict minimum de personne suffisant pour permettre au projet de démarrer, avec un objectif clair : se concentrer sur ce qui permettra au projet de survivre pour passer à l’étape suivante.

 

 

On voit souvent deux erreurs assez caractéristiques pouvant nuire à cette phase. Parfois la personne s’isole et décide de bootstrapper le projet par elle-même, ce qui a plusieurs conséquences fâcheuses (étalement inconsidéré de cette phase dans le temps, qualité dégradé des documents produits, mauvais choix effectué sans manque de recul, difficulté à « vendre » le projet par la suite).

 

 

L’autre erreur commune est – à l’inverse - de réunir trop de personnes avant même que le bootstrap ait été effectué, ce qui entraine une certaine dispersion de l’énergie, un manque de vision commune sur le projet, un trop grand nombre de malentendu, et une qualité globale également réduite.

 

 

Bref, bootstrapper un projet n’est pas une tache aisée, que cela soit dans le cadre d’une entreprise ou dans le cadre d’un projet individuel indépendant.

 

 

Il n’y a évidemment pas de recette magique, mais j’ai remarqué des choses qui ne marchent pas trop mal pour moi. Par exemple, pour moi, la taille idéal pour bootstrapper un projet, c’est 3 personnes. En dessous, il n’y a pas assez d’inputs (et de bras aussi), et au-delà  se forme déjà des mécaniques de divisions ou de dilution de la vision ou de l’objectif.

 

 

A trois, il est possible de partager assez simplement une même vision, tout en ayant assez d’inputs créatifs et assez de retour constructifs pour faire un bon bootstrap. Enfin, trouver trois personnes avec le bon baggage de compétence et la bonne attitude ne me semble pas si compliqué que cela. Evidemment, il faut les 3 bonnes personnes pour que l’alchimie puisse prendre.

 

 

Ce n’est déjà pas forcément simple dans le cadre d’une entreprise (où vous ne choisissez pas forcement avec qui vous allez travailler), mais en discutant avec quelques amis, j’ai découvert de façon surprenante que c’est encore plus compliqué en tant qu’indy, car si le champs des motivations est déjà vaste dans le microcosme professionnel, il est quasiment infini dans le monde amateur.

 

 

Bref, si encore une fois le démarrage d’un projet de présage en rien de sa forme finale, elle est déterminante quand à ses chances de succès, et cela indépendamment de son contexte.

Commentaires

Hello,

- 3 personnes me semblent également le nombre idéal (toujours une majorité pour faire avancer les choses).

- Toutes 3 doivent produire données et/ou code... oui je sais ce sont également des données :-).

- A ce stade, pas de doc (ou alors 2 pages avec une grosse fonte et surtout des images).

- Uniquement du prototypage avec tous les outils possibles et inimaginables (cf. tes posts précédents).

- Playtest constant du concept et des prototypes auprès des collègues / de la communauté Indy. Si une critique revient plus d'une fois, il faut l'adresser. Elle reviendra de manière récurrente jusqu'à la fin du projet.

PS: Merci pour tous les liens/réflexions que tu envoie. C'est un blog vraiment agréable à lire.

Écrit par : Serpico | 03/07/2009

Hello Serpico ^_^

Ca fait un bail, non ? Merci pour tes encouragements, j'espère juste ne pas raconter trop de bêtises ;-)

C'est juste ce que tu dis, à 3, on a pas forcément besoin de documentation (sauf quand la documentation est ce qui est demandé, auquel cas le document devient "le produit" du process en quelque sorte).

Ce qui l'emporte dans la majorité des cas, c'est ce que j'appelle "la démonstration par la preuve" i.e quelque chose qui puisse être soit lu sans effort (abondamment illustré et simplifié), une vidéo prototype (une cible qui "réalise" la vision), voir une maquette jouable (avec des contraintes techniques différentes de celle de la production).

Perso, j'essaye quand même de maintenir une sorte de journal de bord. Ce "journal" ne sers pas de document pour le projet, il sert de trace écrite du travail intellectuel effectué au cours du bootstrapping.

J'ai souvent remarqué qu'un peu ou même beaucoup plus tard dans l'avancement, on perd l'explication rationnelle qui sous tend tel ou tel logique dans le projet. C'est particulièrement vrai quand le bootstrap se révèle difficile parce qu'on patine a mettre en place ces fameux outils qui donneront une direction au projet.

De même qu'une idée peu paraitre brillante un soir au coucher et complètement stupide une fois au réveil, il est parfois utile de se rafraichir la mémoire, surtout quand un réel effort de persévérance est requis pour progresser.

Enfin, comme tu le signale, avoir du feedback de qualité, c'est souvent ce qui fait la différence. Et là, malheureusement, c'est peut être ce que je trouve personnellement le plus difficile à obtenir...

J'ai de la chance, j'ai beaucoup d'amis de qualité et aucun problème pour m'exprimer, ce qui est une bénédiction quand je dois confronter mes idées à titre personnel.

Mais j'imagine aisément que j'aurai plus de difficulté à emmener tel ou tel idée dans le cadre du studio, non que mes collègues ne comprendraient pas, mais juste parce que ces idées, ces visions, ne font pas parties de la culture de l'entreprise.

Au travail, en dehors des aspects techniques sur lesquelles j'ai un réel mandat et donc un peu d'autorité (puisqu'on me paye pour ça), je ne pense pas agir pas en tant que force de propositions, mais plutôt en tant que catalyseur ou facilitateur.

C'est d'ailleurs un point que j'aurai pu citer au sujet des motivations au travail, certaines personnes ont besoin de ce rôle de proposition tandis que d'autres préfèrent comme moi un rôle de révélateur.

Mais je digresse là, non ? ^_^

Écrit par : Daz | 03/07/2009

Documentation qu'il faut fournir: La plus simple et illustrative possible comme tu le dis.

Journal de bord: Tout dépend de "l'équipe de 3", mais oui tu as raison, c'est mieux de garder un historique. Le tout est de ne pas se perdre dans une bible et de ne pas perdre trop de temps là dessus.
Mais cela dépend de la personne... Left Brain / Right Brain. J'envie mes collègues qui le font. J'en suis incapable :-(

Pour le rôle de catalyseur / faciliteur, ça me fait penser à un interview de Harvey Smith en tant que creative director je ne sais plus où: "Mon rôle n'est pas d'avoir les meilleurs idées dans une réunion, mais de savoir qui a les meilleures idées dans cette réunion."
-> Les personnes capables de faire accoucher des idées ne sont pas légion. Enjoy :-)

Quitte à digresser (et cela s'applique au Bootstrap):

Il faut se réserver du temps pour penser au projet... ou à autre chose!

- Tous les projets sont dans l'urgence (à quelque phase qu'il soit).
- Et en même temps, lorsque l'on analyse rétrospectivement un projet "extrêmement urgent du début à la fin", quelle journée a vraiment été déterminante? Le ratio est généralement très faible quel que soit le corps de métier :-(
-> Se réserver quoi qu'il arrive du temps de réflexion (hors sprint conjoncturel: E3, fin de prod, etc.).

Je n'y suis jamais arrivé en 10 ans de prod :-)

Écrit par : Serpico | 03/07/2009

Clair! Si il y a une chose qui peut me miner parfois c'est bien le manque de recul qui entraine l'urgence quotidienne, surtout quand intimement tu sais que ce n'est qu'une agitation sans fin.

J'avoue que comme toi, en presque 10 ans, je n'ai jamais vu personne mettre en place ce processus de prise de recul quel qu'il soit! ^_^ Grande ou petite entreprises, les échelles changent, la nature des problèmes aussi, mais les symptômes sont souvent les mêmes...

Je crois que c'est aussi pour ça que les "GDC" sont si populaires: les conférences servent aussi à définir un "temps" en dehors de l'entreprise qui peut servir à prendre du recul et à confronter nos pratiques. Et à boire des bières.

Bon, ok, boire beaucoup de bières ;)

Mais plus sérieusement, quand j'y réfléchi, c'est peut être ça qui m'amène à parler de plus en plus de nos process de production.

Ce n'est pas que je ne crois plus en la technique (je reste un codeur), mais je crois que le plus important en ce moment, c'est s'interroger sur comment on travaille, et pourquoi on a parfois des conditions difficiles alors qu'objectivement, on devrait tout avoir pour être serein...

Comment en tant que "senior" je peux aider à créer cette sérénité, comment je peux la promouvoir, comment puis je contrôler les facteurs qui me pousse à quitter cette zone de sérénité, comment museler le "troll" en moi, comment apprendre à travailler mieux...

Bref, pour t'emprunter ton image, comment améliorer le ratio de journées déterminantes par rapport à celles du quotidien... ^_^

Écrit par : Daz | 04/07/2009

Quelques idées en vrac:

- Journée swap de map: les binômes art/ld échangent et évaluent la map de leurs collègues.

- Journée swap de projet (dans le cas où plusieurs projets sont en parallèle): l'équipe créative d'un projet travaille sur les problématiques d'un autre projet (avec l'équipe concernée, bien évidemment).

- Journée "Etude des standards": l'équipe isole le standard du marché à
concurrencer, y joue, le déconstruit, et le compare avec son propre projet. Par exemple, Modern Warfare si l'on fait un fps. Fear, pour une IA combattante. Un jeu Popcaps pour un petit jeu grand public, etc.
Cela rejoint ton post sur la déconstruction d'un jeu. Comprendre pourquoi un jeu à succès fonctionne et en dériver des best practice est important (Ex: chronométrer l'apparition des reward/nouvelle capa/durée des niveaux/pts de sauvegarde).

- Semaine "Copie du standard": L'équipe copie une ou plusieurs features d'un standard du marché. La copie doit être la plus fidèle possible, sinon cela ne sert à rien (Ex: valeur d'accélération, filtres des inputs, assistances à la visée dans le cas d'un FPS).

- Weekly meeting "Où l'on en est - Quels sont les problèmes design"(1/4 d'h max) / Questions-réponses (3/4 d'h max).

- Monthly meeting de la core team (si possible 1 jour offsite) pour faire le point sur le projet.

- Journée test d'outils: Les prog outils utilisent pendant une journée les outils d'édition en condition réelle.

- Evidemment, journée playtest: L'équipe regarde des joueurs frais, sans faire le moindre commentaire.

- Journée "prototypage demomaking :-)": L'équipe a une journée pour protyper des features qui ne sont pas prévues (tous les outils sont bons: Blitz basic, Flash, Virtools... ou l'outil maison s'il est fait pour cela).

Quant à savoir comment imposer des plages de ce type, c'est une autre histoire...

Prendre du recul, c'est très dur. Cela impose d'accepter les feedbacks négatifs, de remettre en cause son travail (voire de se remettre en cause), et cela exige une grande rigueur/curiosité. Autrement, tout cela peut tourner en foutoir.

Écrit par : Serpico | 05/07/2009

Wow, vous avez vraiment les moyens de par chez vous !!! Merci de partager tout ça...

Tu te rends compte de la liste de ressources de ouf que ça fait, n'est ce pas ? ^_^

Ceci dit, en effet, quand on peux allouer autant de ressources, on aurait tort de se priver. Si je pouvais me permettre de passer ne serait ce qu'une semaine loin des considérations de production, je serait content :-)

Il faudra que tu nous explique comment vous gérer la prise de recul nécessaire quand le feddback n'est pas très positif. Comme tu le dis, rigueur et curiosité sont requis ^_^

Forcément, la question qui doit venir à l'esprit des équipes plus modestes, c'est comment assurer une telle qualité d'analyse quand on en a ni les moyens ni le temps. En général, ce travail est effectué en même temps que la pré production (ou pire, en prod), alors que souvent, il doit venir en amont.

Je n'ai pas de réponses à un tel défi, mais voici comment je vois la chose.

Quand on a les ressources disponibles pour prendre le temps de se poser les bonnes questions, on peut (doit?) se permettre de chercher différentes pistes avec différentes contraintes afin de trouver les bons produits et les bons process (ce que tu décrit parfaitement).

Dans ce cadre, j'imagine qu'on se retrouve avec un catalogue de type "stage gate", où tout une série d'initiatives mené en parallèles peuvent être évaluées, mises à profit et/ou stoppées au gré des découvertes.

Quand on a une équipe plus modeste et que l'on ne peut se permettre de mettre en place un filet large ou établir un portfolio de projet, il convient plutôt de "réduire" le scope des projets dès la définition.

Par exemple, il est parfaitement honnête de partir d'un produit existant parfaitement calibré, et de construire sur le concept en ajoutant juste ce qu'il faut comme features différenciantes.

Ca peut sembler extrêmement restrictif comme approche, à l'antithèse du mythe de l'innovation à tout prix dont l'industrie se vente de trop, mais en pratique, ça colle parfaitement avec les habitudes du marché, qui d'une génération sur l'autre à tendance à se cristalliser sur une liste de genre plus ou moins réduite.

En fait, en donnant des contraintes fortes dès le départ, on est surpris des résultats obtenues: de très bon produits naissent comme cela.

Donc, pour moi, si vous êtes une équipe réduite ou un petit studio, c'est la bonne approche pour bootstraper un projet.

Quand on est un peu plus gros (EA, Activision, Ubisoft...), la priorité est de pérenniser les IPs et la production. Dans ce cadre, il est tout à fait légitime de prendre à la fois le temps de formaliser la production et les processus d'innovations en construisant une liste d'initiatives dont on espère retirer le bénéfice.

Enfin, les constructeurs de hardware ont d'autres défis: en particulier augmenter la base installée et le fameux "attach ratio". Et là, différentes stratégies existent.

Pour Microsoft, l'objectif est de posséder le marché: pour ce faire, il cherche un titre fort dans tout les segments et les genres à fin à la fois de proposer le meilleur titre du genre en exclu sur leur console, et "driver" indirectement les 3rd party.

Pour Sony, la stratégie a clairement été un désir de différenciation, en proposant des titres uniques basés sur des IPs aussi innovantes que possible. Flower, Heavy Rain, Uncharted, tout ces titres s'inscrivent dans cette logique de différenciation.

Enfin, Nintendo cherche des titres avec un large potentiel de durée de vie sur le marché. Pour cela, elle s'est trsè largement séparé des titres à narrations fortes (à la notable exception de Zelda) pour se concentrer sur des titres entièrement basé sur le gameplay. Leur logique est que la narration est périssable et surjecte aux effets de mode (quand on a lu une histoire, on veut passé à la suivante), tandis que les titres basés sur le gameplay (Wii play, Mario Kart, Wii Sport Ressort...) on plus de potentiel sur le long terme ("long leg").

Bref, dans tout les cas, quelques soit la stratégie retenue, il est toujours important de démarrer du bon pied.

Écrit par : Daz | 06/07/2009

Oula, je dressais une liste de pistes persos pour se forcer à prendre du recul... trop rarement, voire jamais expérimentées :-)

C'est donc loin d'être la norme pour les raisons d'urgence précédemment évoquées.

D'où l'intérêt de formaliser cela avec des outils, en attendant que cela devienne une manière naturelle de développer un jeu.

J'ai juste pu tester avec succès:
- le swap de map entre LD sur plusieurs projets.
- les playtests évidemment.
- très partiellement l'aide d'une core team par une autre core team (dans le cadre d'un training qui n'avait rien à voir).
- Un meeting de la core team offsite qui avait été très productif (d'où mon idée de multiplier ce genre de truc, pas seulement en temps de crise).
- un peu de tests d'outils il y a bien longtemps.

Tout comme toi, je pense qu'"il est parfaitement honnête de partir d'un produit existant parfaitement calibré, et de construire sur le concept en ajoutant juste ce qu'il faut comme features différenciantes".

Je pense même que cela devrait être la norme dans la grande majorité des cas (et pas seulement pour un petit projet).

- Dead Space est un bon exemple (une ou deux features innovantes qui seront reprises par la concurrence, sur une base somme toute classique mais parfaitement réalisée).
- Je trouve qu'Uncharted est aussi dans cette catégorie: aucune feature que je n'avais déja vu, mais tellement bien faites que le jeu n'est que du bonheur.
- Etc.

Mais encore faut-il isoler ce qui est bon dans le produit existant, l'analyser finement et être capable de le reproduire dans son propre jeu:
- Contrôle / Caméra
- Rythme
- IA NPC
- Macro structure
- Système de reward
- Etc.

Le reverse engineering, c'est la grande difficulté (de l'intérêt de la GDC et de ses équivalents).

- Encore maintenant, peu d'équipes seraient capables de copier à la perfection les contrôles d'Halo (et l'IA qui lui est associée).
- Tout le monde a expérimenté la joie du Spawning dynamique de L4D. Qui peut faire exactement la même chose (pour les mêmes résultats)?
- Tout le monde s'accorde à dire que l'IA de FEAR n'était pas dégueulasse. Combien de projets équivalents (couloir / salle / couloir / salle) ont proposé une IA aussi bonne ?
- Que serait GTA s'ils n'avaient extrait, magnifiés et construits sur la substantifique moelle de Driver?

Bref, je suis pour la promotion du travail de faussaire dans le jeu vidéo.
- Pas des billets qui se repèrent au premier coup d'oeil façon Monopoly.
- Mais des billets qui résistent au contrôles les plus poussés et peuvent être fourgués à la banque les yeux fermés.

J'aurai bien plus confiance dans la capacité d'innovation d'une équipe qui est parfaitement capable de copier un standard que dans celle qui ne l'a jamais fait.

Mais tout cela a un coût: Cela s'évalue en mois (années?) plus qu'en semaines.
Et cela nécessite un état d'esprit: humilité, rigueur, perfectionnisme, casser et refaire quotidiennement.

Je tiens à préciser que je n'ai que partiellement voire pas du tout appliqué ces principes jusque là :-)

Écrit par : Serpico | 06/07/2009

Mais grâce à la majorité actuelle, je devrais avoir encore suffisamment de temps pour y remédier :-)

Écrit par : Serpico | 06/07/2009

Bah, tu comptais pas prendre ta retraite non plus, hein ? ;)

Comme disais Albert Einstein: “The secret to creativity is knowing how to hide your sources.” ^_^

Ceci dit, tu as parfaitement raison, on manque incroyablement d'outils et de façon de faire quand on cherche à "déconstruire" un jeu. Pour le coup, ca fait un petit moment que je réfléchi à un setup de capture "complet".

Mon système serait le suivant: Pour un jeu console, la machine enregistre en temps réel le flux vidéo du jeu, le signal des pads en input, ainsi le retour force feedback en output.

Un éditeur par la suite permet de rejouer la capture en visualisant tout les signaux associés, avec la possibilité d'annoter les passages intéressants.

Pour un jeu PC, j'irai même encore plus loin. En écrivant, ou en utilisant un driver particulier, je capturerai toute la scène en même temps. Ainsi, pendant le playback, je pourrai choisir un autre point de vue, et annoter ce que le joueur ne voit pas dans sa vue.

C'est un travail collosal, puisque cela requiert à la fois du hardware et du software, mais je pense que les gains seraient colossaux quand il s'agit de comprendre ce que fait le jeu, indépendamment des "smokes and mirrors"...

^_^

Écrit par : Daz | 07/07/2009

Les commentaires sont fermés.