Samedi 5 décembre 2009 a eu lieu le premier Gamecamp à Paris. Il s'agissait d'un Barcamp ayant pour thème la création de jeux vidéo.

L'idée avait commencé à germer dans des commentaires de blogs et twitter. Cela faisait quelques temps que Whirly parlait du format Barcamp et du fait que cela n'avait pas été fait en France sur le thème de la création de jeux vidéo.

Quelques personnes, dont Daz (archive) et Pedro ont pris le sujet à bras le corps et, d'un coup (2 semaines !), tout a pris forme : le (ou la ?) Gamecamp Paris avait pris forme. Date, lieu, organisation, t-shirts,...

Pas évident de dégager tout à coup un samedi aussi rapidement pour moi, et je remercie ma femme d'avoir pris sur elle pour que je puisse me rendre à cet évènement.

Arrivée

À 9h10, j'arrive chez PlayAll, qui prête ses locaux gracieusement. Il n'y a pas encore grand monde, mais ça arrive a un rythme soutenu. Tout le monde discute en attendant le démarrage des sessions.

Puis, à 9h30, Daz et Whirly font un petit discours de bienvenu et d'introduction du principe de la journée. Dans un Barcamp, il n'y a pas de programme, il y a un grand tableau croisé entre salles disponibles et horaires (une heure par session) et, sur la même base que le fait d'être venu, la volonté, chacun peut remplir une case avec un thème. À l'heure dite, il se rend alors dans la bonne salle et voit qui vient.

Cela a tendance à gêner les habitués de la sur-planification, de même que le format d'une heure semble gêner les bavards.

Pour la planification : on est ici dans l'« agile », beau buzzword qui sert surtout à décrire un fonctionnement où l'on s'adapte au fil de l'eau. Pas besoin de programme : les gens qui sont venus, un samedi, hors boulot, sont a priori des gens qui ont envie de faire quelque chose de cette journée. Ils ne sont pas là en touriste. On peut donc leur faire confiance.

Sur le second point : une heure, c'est très bien. S'il reste des choses à dire, des sujets annexes qui sont apparus, pas de soucis, il suffit de noter un nouveau créneau sur le tableau. Il faut cependant veiller à garder le cap de la discussion pendant l'heure qui lui est consacrée.

Un autre point qui a été soulevé est celui du mélange des métiers : je trouve au contraire que c'est une bonne chose si le sujet s'y prête. Pour filtrer un métier, ce n'est pas compliqué, il suffit d'intituler une session de manière précise. Lorsque j'ai proposé le thème un peu technique des bases de code décentralisé (voire plus loin) j'étais à peu près certain de n'y retrouver que des métiers techniques.

J'attends de voir deux premiers thèmes inscrits, je jette un coup d'œil à mes notes, et j'inscris à mon tour deux thèmes en faisant attention que cela ne chevauche pas un thème qui m'intéresse.

Puis à 10h, débute la première session.

1. Méthodes agiles

Un sujet assez vaste et qui draine pas mal de monde. Dans le groupe, il y a des gens qui ne connaissent pas et sont venus pour découvrir, un petit rappel de quelques principes de méthodes agiles est donc fait.

Une méthode agile est un ensemble de processus pour une gestion de projet qui puisse réagir rapidement aux changements ; c'est un ensemble d'outils pour une planification flexible et les métriques qui vont avec.

Expérience de Creative Patterns

Whirly (patron de Creative Patterns) expose brièvement sa mise en place de méthodes agiles, d'abord avec XP (eXtreme Programming) en 2001 puis Scrum (ces deux méthodes ne s'occupent pas exactement des mêmes choses et leurs principes sont compatibles).

Les discussions vont ensuite flotter, mais Whirly va régulièrement donner des retours d'expérience tout au long de la session. Je regroupe le tout :

• Creative Patterns utilise Scrum avec le designer en tant que client des programmeurs.
• Pour les estimations, ils utilisent un story point en tant qu'une heure de Perfect Engineering (une heure consacrée entièrement à la tâche, sans interruption et avec toutes les ressources nécessaires disponibles : une heure idéale).
• Après un suivi avec des cartons sur un tableau, l'équipe utilise Trac pour la gestion des stories.
• Au début, ils testaient absolument tout, jusqu'à des tests d'interface utilisateurs. Maintenant, ils implémentent les tests « gratuits » (ceux qui ne demandent pas d'effort particulier et sont faits en parallèle du développement). Pour les tests plus complexe, une évaluation de l'intérêt du test par rapport à sa complexité et surtout, sa future maintenance, est faite avant de l'implémenter.

Comme il y avait beaucoup de monde, que prendre la parole était assez difficile lors de cette session et que mon argument n'aurait pas avancé à grand chose sur place, je l'ajoute ici : j'ai le même constat à propos des tests. Globalement, plus on s'enfonce dans les couches basses dans du code qui ne va pas changer, plus il est intéressant de faire du test. Plus on monte vers du code gameplay sensible aux modifications design, moins il est intéressant de faire du test automatique.

Il donne aussi des conseils sur l'application de méthodes agiles lorsque d'autres intervenants avec des expériences malheureuses les rapportent :

• il est important que l'équipe de production soit protégée de l'éditeur/client. Cela fait partie de la conduite d'un projet que de filtrer les demandes externes.

Note personnelle : je suis absolument d'accord, mais je précise qu'il ne faut pas traduire « filtrage » par « mentir à l'équipe ». Certains chefs de projet font cette erreur.

• lors d'une réunion hebdomadaire de suivi de projet, la première question posée à chaque membre de l'équipe est : « comment te sens-tu ? » Pendant la réponse, il n'est permit aucune interruption de parole et aucun jugement ne doit être porté sur la réponse. Après des premières semaines méfiantes où personne ne va oser se lancer, cette question devient une soupape de sécurité qui aide à faire remonter les problèmes le plus rapidement possible.
• mettre en place une méthode agile ne s'impose pas. C'est une méthode qui doit venir de l'équipe, qui pourra avoir besoin d'un temps d'adaptation. Pour cela, le mieux est d'avoir dans l'équipe au moins une personne (et éventuellement un noyau) à l'aise avec ces concepts. Le changement se fait alors par contamination, naturellement, lorsque les réfractaires se rendent compte des bénéfices qu'ils gagnent avec ces méthodes.
• il conseille aussi de segmenter l'équipe complète en cellules entre lesquels ont détermine des point de communication. Ces points de communication sont des membres d'équipe qui s'assurent que l'information passe ; cela ne signifie donc pas que toute information ou demande doit passer par eux.

Ces conseils se retrouvent généralement sous une forme ou une autre dans les livres ou articles à propos des méthodes agiles. Avoir quelqu'un qui raconte son expérience en face (ou presque) de soi est cependant un plus car il peut réagir aux mésaventures de ceux qui ont vécu de mauvaises expériences dans ce domaine.

Autres expériences

Des intervenants, la plupart des autres rapportaient de mauvaises expériences avec les méthodes agiles. Ou plus précisément avec Scrum. Ils étaient tous du même studio et s'étaient vu imposer Scrum par leur éditeur... sans mode d'emploi.

Vu l'ampleur du changement, l'absence de compétence Scrum dans les équipes, la rigidité du fonctionnement qui transparaissait des témoignages et la taille des équipes de Scrum (jusqu'à 35 !), l'échec était assuré.

Des exemples d'interventions directes du client/éditeur dans l'équipe ont été aussi rapportées.

Pour un employé d'un autre studio, Scrum était vu dans son environnement pour quelque chose de trop raffiné.

Ma conclusion

Beaucoup de monde à cette session a empêché d'approfondir les choses. La majorité avait eu une mauvaise expérience avec Scrum. J'espère que cela ne les a pas empêcher d'écouter les très bonnes pistes de Whirly. Du fait du dialogue qui s'est instauré entre ces deux expériences, pratiquement aucune place n'a été laissé au reste.

Cependant, la session a ouvert une autre session sur Scrum en particulier. Je ne l'ai pas suivie, mais d'après les retours que j'ai vu, il s'agissait d'expliquer un peu Scrum.

C'est un avantage du fonctionnement par sessions d'une heure : pour l'approfondissement d'un sujet, il suffit de proposer une nouvelle session sur le projet.

2. Perforce vs. Git

C'est une session que j'ai proposée, avec en sous-titre : intérêt et mise en œuvre des bases décentralisées. Comme on peut le voir sur la photo du whiteboard, j'ai ajouté SVN sous Perforce et Bzr sous Git ; c'était suite à des commentaires derrière moi lorsque j'écrivais le sujet.

Une erreur : mieux vaut un titre clair. La session s'auto-régule par la suite.

Un sujet un peu plus technique donc, à laquelle je ne m'attendais pas à voir grand monde... mais peut-être un peu plus quand même. Nous avons commencé à 3 et terminé à 5. L'avantage étant qu'avec ce format là, nous avons pu creuser un peu plus en profondeur.

J'ouvre la session. Nous sommes deux à avoir utilisé Git ou un autre système décentralisé. On discute donc un peu de l'intérêt d'une solution ou d'une autre. L'accord est vite trouvé : Git intéresse surtout les programmeurs, qui y gagnent en flexibilité de contrôle de révisions (branches gratuites, pas de blocage en cas de fermeture temporaire de base en vue de milestone, possibilité de travailler sur la même fichier dans deux « changelist » différentes,...).

Il y a aussi consensus sur le fait qu'à moins d'outils pour cacher le fonctionnement, imposer Git à d'autres corps de métier n'est pas une bonne chose. De plus, ces autres métiers ont très souvent besoin de locker des fichiers binaires sur la base, ce que ne permet pas Git seul.

Des essais ont été fait. On évoque une base de 17 Go a un historique de près de 230 Go. Git stockant l'historique sur chaque poste, cela peut poser des problèmes de place disque. Surtout si l'on travaille sur plusieurs projets. Chez un studio qui fait du jeu pour téléphone, les volumes sont de l'ordre de cent fois plus petit. Pour ces volumes, une solution Git complète (en gardant à l'esprit les commentaires sur les utilisateurs non programmeurs) peut être envisageable.

Sam propose alors une piste qu'il creuse lui-même en ce moment, à base d'un mélange de Perforce comme base centrale et de Git pour les programmeurs qui le veulent. Il utilise pour cela git-p4, qui permet de migrer les historiques entre les deux systèmes. Grâce à un jeu de Workspace (pour perforce), les données restent gérées par Perforce et seules les sources sont gérées par Git.

Il mentionne aussi une version patchée de Git de son cru, git-bigfiles, qui a de meilleures performances sur les gros fichiers (voir son site).

La solution de Sam me plait. Je pense creuser dans cette direction dès que j'en ai le temps.

Autres choses notées à cette session :

• une remarque de Daz, qui était à cette session : on a des process de plus en plus long dans le jeu vidéo et il faut trouver les bon outils qui peuvent nous aider. Question base, à peu près tous les studios se greffent sur une solution Perforce ou Subversion, sans se poser trop de questions.
• d'un point de vue stockage, Nicolas L. fait remarquer que stocker des formats compressé n'est pas efficace avec Subversion (et probablement les autres). Les révisions étant stockées sous forme de diff compressés, cela fonctionne mieux sur des formats de fichier où une petite modification entraîne un petit changement dans le fichier. Ce n'est pas le cas des fichiers déjà compressés.

Pause déjeuner

C'est aussi un moment de discussion.

3. Outils libres dans la production

C'est le second thème que j'ai proposé. Une dizaine de personnes autour de la table, le plus gros des troupes étant parti sur les sessions sur Unreal et le piratage sur mobiles.

Rapidement, on sépare deux grandes utilisations du libres : bibliothèques intégrées à un jeu et outils utilisés de production.

Un des premiers soucis de l'utilisation du libre dans une entreprise est la mauvaise connaissance de leurs licences par les départements légaux. Il y a souvent de la méfiance et une réaction qui consiste à refuser l'utilisation du libre car il n'est pas compris. Certaines entreprises n'aiment pas non plus n'avoir personne contre qui se retourner en cas de problème.

À cela, les intervenants de la session partagent sur des pistes :

• communiquer sur les licences, les expliquer. Il faut aussi les expliquer aux employés pour éviter de retrouver du code GPL dans un jeu au code propriétaire par exemple. Lever la confusion entre libre et gratuit.
• montrer qu'avoir un éditeur contre qui se retourner n'est pas une garantie car 1/ des données perdues sont perdues, faire un procès n'arrange pas grand chose 2/ l'éditeur se retranchera à coup sûr derrière une mauvaise utilisation du produit par l'utilisateur 3/ l'éditeur peut tout simplement disparaître, laissant l'utilisateur avec un produit non soutenu et un coût de migration obligatoire vers une autre solution.

Pour ce dernier exemple, autour de la table, nombreux sont ceux à avoir connu l'épisode du rachat de RenderWare par EA. C'est un bon exemple à montrer à quelqu'un qui voit dans l'existence d'un éditeur une garantie forte.

Les intervenants sont aussi d'accord sur un point : il faut être pragmatique. Si un outil correspond à un besoin, libre ou propriétaire n'est qu'une des variables permettant de choisir son utilisation ou non.

D'après Whirly, il manque au secteur une vraie success story autour du libre, une entreprise qui communique sur le gain que lui a apporté le libre.

Suivent les notes que j'ai pu prendre sur divers points, sans trop de mise en forme :

• la publication des modifications : c'est une évidence pour quiconque a une sensibilité au logiciel libre, ça ne l'est pas forcément pour une entreprise qui n'utilise pas.
• le management confond souvent libre et gratuit. Une solution à base de logiciel libre ne doit surtout pas être présentée comme gratuite, ce qui est de toute façon faux.
• le coût du logiciel libre correspond en gros à la ressource qu'il faudra allouer localement à la maîtrise du produit, aux temps de merge du code, à la maintenance,...
• ce coût n'est pas inexistant pour du logiciel propriétaire : ce n'est pas parce qu'il y a du support que tout est gratuit pour une équipe. Autour de la table, tout le monde est bien conscient que pour une solution propriétaire, il faut aussi une ressource locale allouée pour la maîtrise du produit, du temps pour le merge, de la maintenance,...
• ces coûts doivent être intégrés à la méthode de développement. Par exemple, un coût en story points pour une méthode agile.
• le libre présente un avantage d'indépendance par rapport à une entreprise tierce (qui peut-être rachetée par un concurrent ou déposer le bilan).
• des pistes pour présenter l'intérêt d'une entreprise à contribuer au code libre : il y a un intérêt à ce que plusieurs personnes réussissent au même endroit, c'est une sphère de prospérité ; tout le monde gagne à ne pas perdre du temps sur des outils dont tout le monde à besoin.
• il y a beaucoup d'outils de base (voire d'outils \"jouets\") dans le libre concernant le jeu vidéo. Il manque au-dessus de ces projets des outils plus avancés. C'est là que devrait se concentrer l'effort d'entreprises intéressées par le libre, plutôt que sur une énième version d'outil déjà existant.
• il y a peu de temps, le middleware propriétaire était mal vu des entreprises, son utilisation et les bénéfices que cela apporte est à présent un fait bien intégré. Ce n'est pas encore le cas pour le libre.
• un soucis qui est relevé par le management est parfois de se dire que si on revend le produit contenant des modifications à des licences forçant la redistribution, du code confidentiel risque d'être rendu public. Cette question est tout à fait hypothétique. Autour de la table, personne n'a vu le cas se présenter. De plus, toutes les licences ne forcent pas la divulgation de l'intégralité du code attaché. On rejoint là l'un des premiers points : former au libre.

Ma conclusion

Comment conclure sur ce sujet ? Je ne m'y risquerai pas. Je peux conclure sur la session : une bonne session qui a montré une véritable envie de partager, au moins sur des points qui font perdre du temps aux productions. Nous avons tous des exemples d'outils ou des parties d'un moteur refait sur plusieurs projets différents de la même façon.

Éduquer sur le sujet du libre sera un véritable gain pour les entreprises de jeu vidéo.

4. Partager les modifications custom aux moteurs et middleware

Une sorte de suite logique à la précédente question, proposée par Sam. Beaucoup de participants pendant cette heure étaient sur la session « Prototypage » juste à côté.

Le constat de base de cette session est un de ceux faits lors de la sessions précédentes : beaucoup de studios font les mêmes modifications, les même bugs fixs, aux mêmes moteurs et middleware. Cependant, ces modifications ne sont pas partagées, même dans les rares cas où le fournisseur du produit offre un espace de partage ou encourage aux retours pour intégration dans leur produit.

Les participants à la session étant déçu de ce fait et certains acteurs dans le logiciel libre, nous avons essayé de comprendre pourquoi ce qui fonctionne bien dans le libre ne fonctionne pas dans ce cas.

Voici quelques pistes :

• Volonté de garder les ressources pour soi : les studios passent du temps à corriger des produits qui ne sont pas à eux. L'intérêt immédiat est de pouvoir avancer dans sa production. Étant donné que l'on paye déjà pour le produit, donner le résultat des corrections est souvent vu comme un cadeau au fournisseur, sans intérêt.
• Manque de ressources à allouer à la gestion et communication sur le sujet : remonter des patchs au fournisseur est un travail complexe car ces produits sont généralement lourds dans leur processus. De plus, les branches locales des productions peuvent avoir beaucoup divergées et la production du patch en est aussi lourde (il faut le rendre publiable, exempt de code confidentiel, ce qui n'est pas toujours évident suivant la qualité du produit).

Cependant, un avantage évident à partager son code est à noter : remonter un patch et le voir intégrer dans la version officielle du produit, c'est s'éviter un coût de merge lors de l'intégration d'une nouvelle version du produit. Ainsi, on paye une fois pour la production du patch, mais on ne paye plus à chaque intégration. Cela peut être très avantageux.

Un autre obstacle au partage de modification à du middleware ou moteur est tout simplement le fournisseur : il peut ne pas avoir mis en place un processus facile de remontée de patch, il peut n'avoir pas envie de voir ses clients communiquer, il peut y avoir quelques obstacles contractuels sur la propriété du code,...

Ma conclusion

Cette session est vite arrivée à une conclusion : le partage de code dans du middleware propriétaire, pour être efficace, doit être encouragé et facilité par le fournisseur. Contrairement à un logiciel libre ou les différents clients/contributeurs sont libres (!) de ce qu'ils font, le code propriétaire nécessite que le fournisseur joue le jeu. En sachant qu'il y gagnera aussi.

5. Bosser sur des projets persos, chez soi

Au début de cette session, nous étions moins d'une dizaine. Personne ne semblait avoir lancé l'idée de la session, c'est donc Christophe de DK-Games qui se charge d'animer et l'on commence un tour de table.

Et tout à coup, il semble que la moitié des participants à l'évènement vient nous rejoindre, sans trop de considération pour le fait que la session a déjà commencé. Petit bémol sur ce coup-là. Le début des sessions a lentement glissé le long de la journée, mais essayer d'arriver au début de la session et se faire discret lorsqu'on est en retard me semble une bonne chose.

Du coup, le périmètre de la discussion a sensiblement varié. D'un départ a peu de personnes où nous allions parler de nos expériences précises, nous passons à beaucoup de personnes avec beaucoup de vues différentes. Comme je le disais au début, ce n'est pas forcément un mal, cela permet de donner des pistes sur des réflexions ultérieures plus précises.

Motivations

En début de la session, les participants essaient de savoir pourquoi il y a ce besoin d'avoir des projets personnels. Ce qui en ressort est que pour la plupart, il s'agit de faire quelque chose d'autre que ce que l'on fait au boulot, le plus souvent sans finalité de vente. Les projets avec finalité de transformation en projet professionnel sont minoritaires.

'J'ajoute un cas, non évoqué pendant la session : celui de la formation personnelle continue, sans finalité de produit fini.'

Au niveau des moyens, tout le monde autour de la table connaît les outils dont il a besoin, ou presque. Ceux qui ont des projets de game design utilisent des plateforme (moteurs ou mod), ceux qui font de la programmation utilisent du middleware,...

Motivation et temps

Reste le principal problème : le temps à y consacrer et la motivation que l'on a.

'On se rend compte sur cette partie que les professionnels chez eux ont strictement les mêmes problématiques que les amateurs. La différence se situe essentiellement dans la conscience de ces problèmes.'

Question motivation, tout le monde est d'accord : il est très difficile de la garder sur le long terme. Six ou sept mois en continu sur un projet semble être une limite pour la majorité. Les moyens de conserver sa motivation varient cependant beaucoup d'une personne à l'autre.

Certains préfèrent avoir plusieurs projets de front pour pouvoir changer de projet et revenir plus tard. L'avantage est de ne pas abandonner ses idées, l'inconvénient est que cela rallonge la durée d'un projet au point d'en être dégoûté, une sorte de perte de motivation de second niveau.

Une autre manière de garder sa motivation est de viser un projet de taille raisonnable. Raisonnable s'entend en fonction de ses capacités mais aussi et surtout du temps que l'on peut consacrer au projet chez soi. Éventuellement, un projet de plus longue haleine peut être découpé en tâches modestes avec à la fin de chaque tâche, un produit fini. Une sorte de \"Scrum personnel\". Pour aider dans cette méthode, utilisée par quelques participants, il est noté qu'un bug tracker, gestionnaire de tickets ou tout simplement un fichier de tâches est utilisé.

Niveau gestion du temps, il y a presque autant de réponses que de participants prenant la parole: certains préfèrent s'imposer des horaires fixes, d'autre un nombre de tâches par jour, d'autres ne veulent pas de contraintes horaires,... À chacun de trouver ses méthodes.

'Note : les participants ayant des motivations et métiers différents, cela n'aidait pas aux discussions sur la gestion des tâches et du temps. Difficile de prendre des cas précis.'

Motivation de groupe ?

Pour certains, la motivation passe par le groupe : à plusieurs, il est possible d'aller plus loin. Le recoupement des expériences montre que c'est cependant pas magique. La raison principale avancée comme explication à l'échec d'une équipe est que, tout simplement, il est difficile de travailler pour les idées des autres. Comme l'indique l'intitulé de la session, chez soi, on fait des projets personnels.

Les cas d'équipe qui fonctionnent semble être ceux dans lesquels le projet est porté initialement par une seule personne qui fait plus de la moitié du travail et qui est capable de tout faire. Avoir un bon contact et passer du temps en communication aide en plus à fédérer des gens autour de son projet. Cependant, il ne faut pas chercher à garder ces contributeurs comme des employés, mieux vaut les considérer comme des contributeurs occasionnels.

6. Fédérer la communauté indy, partage technologique et autres

Dans cette session, c'est la partie partage qui m'intéressait. Je ne suis pas indépendant. Cependant, cela a du se voir dans les différentes sessions que j'ai suivi, je suis persuadé que le partage fait progresser tout le monde, tout en laissant à chacun de quoi se différencier dans ses projets. Nos métiers concerne le jeu, les moyens de faire des jeux, de bon jeux si possible. Et perdre du temps est un obstacle à la qualité.

Cette session commence par essayer de savoir ce qu'est un indépendant. Ce n'est pas évident. Il n'y a pas eu de réponse claire, et ce n'est pas le sujet qui m'intéresse.

Ce qui m'intéresse est : comment partager ?

Deux des sessions précédentes donnent des pistes, forcément. L'utilisation du logiciel libre est probablement un bon moyen. Whirly ajoute même : une assurance. Une assurance qu'on ai accès à la ressource, que celle-ci ne disparaîtra pas avec une entité (association, entreprise ou personne).

La peur du libre est que certains soient des mauvais joueurs, qu'ils prendront sans donner. Le risque est très élevé, le monde du libre nous l'apprend, mais ce qu'il nous apprend aussi, c'est que l'impact est faible, ceux qui contribuent sont gagnants par rapport à ceux qui ne sont que clients.

Un exemple simple, pour un petit studio qui a beaucoup participé à une technologie, voire qui en est le moteur, est qu'elle a ensuite la possibilité de vendre du service sur cette technologie.

Il est évoqué que les outils sont souvent très adaptés aux besoins des studios. À cela, une solution semble se trouver dans les bases décentralisées (comme Git ; comme quoi, les sessions que j'ai suivi dans cette journée se recoupent).

Le libre demande cependant une gestion de communauté. Là-dessus, la session n'a pas trouvé de solution claire, cela nécessite d'être fouillé car les possibilités sont nombreuses. L'exemple de boost et son comité de sélection a cependant été cité.

Attention au phénomène de vide grenier : mieux vaut pour cette hypothétique communauté travailler sur des outils ayant de la valeur ajoutée. Un exemple : Ogre3d manque cruellement d'outils autour du moteur. Un autre exemple : fournir des modules pour Unity3d.

À plus long terme, une telle communauté pourrait s'intéresser au CIR et inversement.

La session s'est beaucoup attachée au partage technologique, mais il n'y avait pas que des informaticiens autour de la table. Il serait possible de partager sur de la gestion de projet, du game design. Un GameCamp est d'ailleurs un bon exemple de partage. Une idée de gestion documentaire électronique est lancée, mais il s'agirait de ne pas copier l'existant (Gamasutra par exemple).

Une autre idée de partage est lancée : le peer review. Les petits studios n'ont pas la possibilité de payer des boites de play tests. Une communauté indépendante pourrait se faire tester ses jeux par les différents studios.

Fin !

La journée arrive déjà à sa fin. Whirly nous avait prévenu : une seule journée pour un BarCamp se termine généralement par de la frustration. Encore tant de choses à dire, à partager.

Daz et Whirly font un petit debrief de la journée, sur le vif, en posant quelques questions. À première vue, tout le monde est satisfait.

Le temps de dire au revoir, je rentre chez moi.

Vraiment une bonne journée. Merci à tous.

Autres articles sur le GameCamp

• http://nicolas.hognon.com/blog/?p=9...
• http://yumenokaze.org/Jeu/GameCamp-...
• http://www.bretzelsandgames.com/200... (archive)
• http://www.antipatterns.fr/archive/... (archive)
• http://blogs.wefrag.com/channie/200... (archive)