GameCampParis (5 décembre 2009) : feedbacks / retours

La 1ère GameCampParis a donc bien eu lieu hier dans les locaux de notre généreux sponsor PlayAll.

PlayAll logo

Globalement c’était très sympa, intéressant et je suis impatient de participer à la prochaine. Avant d’essayer de faire un (bref) compte rendu des sessions que j’ai réussi à suivre on va peut être parler des quelques points qui m’ont déçu :

  • on avait 2/3 salles pour gérer 4/5 sessions en parallèles donc des fois c’était dur de s’entendre. avec les locaux qu’on avait c’était dur de faire mieux, on nous les prêtaient gratuitement donc on ne va pas trop se plaindre.
  • l’hétérogénéité des participants (qui est un point positif) pouvaient être des fois perturbantes sur l’interprétation du sujet des sessions. En gros les sujets des sessions étaient suffisamment vague pour que chacun voit la chose à ça façon. alors oui c’est bien de mélanger les genres, mais des fois ça pouvait prendre une direction assez différente de ce à quoi je m’attendais … pas de souci dans ce cas … hop on se lève et on va voir ailleurs … mais des fois ça fait bizarre. bon ce n’était pas très génant non plus mais ça me l’a fait une fois (et demie) quand même. en gros j’ai l’impression qu’on avait les oppositions suivantes
    • codeurs (qui ont tendance à trop partir de / ramener à la technique/techno/moteur) VS graphistes/level designers/game designers
    • je veux monter mon petit projet perso, monter ma boîte, être mon compte ….. VS je veux comprendre, améliorer, …. le travail dans une structure importante
  • je schématise un peu et je ne sais pas si j’emploie les bons pour expliquer mon ressenti … en tout que personne n’y voit une attaque contre tel ou tel camp

Avant de commencer, il se peut que ma vision de certaines soit biésée dans une certaine direction du fait que je suis un programmeur et que je réfléchis à des projets peros (donc tout le coté indie, fait à la maison, …).

Les sessions aux quelles j’ai participé :

Indie : faire un jeu tout seul

Ce barcamp était quand même globalement assez orienté développement indépendant / indie, projet perso, … Cette première session ouvrait un peu la voie aux autres. C’était la première session on était donc par encore très chaud … en plus un barcamp c’était un peu nouveau pour nous mais on s’est un peu dérouiller au fur et à mesure.

Dans le thème il y a indie et seul.

  • Faire un projet seul, cela veut dire que l’on maitrise différent corps de métier (code, gfx, gd, son, …) ce qui est quasiment à la porter de personne. Certains parti pris artistique peuvent permettre à un codeur de tout faire : on a cité l’exemple de Love (http://www.quelsolaar.com/love/index.html).
  • Indie ? ça veut dire quoi indie … dans cette session on n’a pas trop disserté sur le sujet mais en fait la définition reste assez floue (projet perso qui devient un truc a visé commercial, projet fait en très petite équipe, projet faire par une équipe indépendante quelques soit ça taille, ….)
  • On peut être seul à l’origine du projet et à gérer/contrôler le projet mais faire appel à d’autres personnes pour certaines partie que l’on ne maitrise pas. Cela parait plus réaliste : à coder aura surement besoin d’au moins un graphiste, …
  • On tombe donc sur la problème d’être plusieurs, surement distant … et qu’il va falloir gérer tout ça ? existe-t-il de plateforme facilitant se travail collaboratif … on a cité trac (http://trac.edgewall.org/) il me semble. Quelqu’un a cité une plateforme communautaire où l’on peut noté les gens, ce qui permet de simplifier le passage de quelqu’un à un autre.
  • A un moment on a un peu dérivé car on est partie sur les projets perso qui ne sont plus vraiment des projets indie de mon point de vue. même si un projet perso (à coté de son travail) peut finir en vraie projet un plein temps (indie ou pas … encore ce problème de définition du mot indie). Un projet perso dans un contexte jeu vidéo peut être une démo technique, un petit jeu (mobile ou pas), un mod (half life 2 et autres) … avec différents buts (carte de visite, purement loisir, basculer en projet principale, …).
  • Quand on fait un projet à un (ou en petite équipe) le risque est partir sur un projet trop ambitieux et de ce noyer. Le plus important est donc de fixé un cadre très précis : thème, objectifs, durée. Cette notion de durée est très importante en fait pour bien cadré le projet. On a un peu parlé des différents concours/expériences/festival qui propose de faire un jeu sur une semaine, un week end … le fait de contraindre la durée force à faire beaucoup de choix/concessions ce qui peut être bénéfique au final.
  • Cette notion de durée très courte nous a amené à parler de projets tel que world of goo.  Ce jeu est issue d’un projet qui s’appelle tower of goo qui a vu le jour via le “projet” Experimental Gameplay (http://experimentalgameplay.com/). De là on a dérivé sur l’aspect promotion de son jeu indie … en fait différent jeu tel que word of goo, crayon physic, … si issue de prototype qui ont été médiatisé. il y avait donc une attente autour du jeu. Certains font aussi du merchandising pour promouvoir leur jeu (Castle Crusher).

Gameplay : bottom up – top down

Un sujet sur le gameplay. Discipline que ne connais pas du tout. J’étais donc plutôt de curieux de voir de quoi on allait parler. (seul bémol … à cause de acoustique du lieu ce n’était pas facile d’entendre tout le monde).

  • déjà c’est quoi cette histoire de bottom up – top down. en gros si j’ai bien compris il y aurait du façon de concevoir un jeu :
  1. soit on part d’un point/contrainte technique : idée de contrôle, parti pris visuel, avancé technologique et on cherche à construire un jeu (univers) autour de cette idée : c’est le bottom up.
  2. soit on part d’une univers et on descend vers la technique, le gameplay : c’est le top down.
  • le bottom up on n’a pas d’univers dès le départ donc on est moins cadré. par contre ça oblige quasiment systématique de faire un proto ce qui n’est pas une mauvaise chose. on pourrait croire qu’il est plus dure de “vendre” un projet construit en bottom up mais ce n’est pas forcément vrai. on peut vendre un projet autour d’une “technique” particulière. genre on va faire un RTS qui gèrera des univers énorme comme on en a jamais vu.
  • le projet top down qui parte d’un univers sont souvent des commandes éditeurs ou liés à une licence. le problème de ce type de projet est qu’on met du temps à définir le gameplay et donc le fun du jeu.

Logiciels libres

globalement les participants a cette session était plutôt pro libre donc il n’y a pas eu de contradicteurs.

  • le premier problème avec les logiciels s’est qu’on se rend compte que les gens comprennent rarement ce que s’est. générale ils retiennent que c’est gratuit (on verra que c’est en partie faux).
  • cette incompréhension amène des sociétés à bannir purement et simplement l’utilisation de soft/librairie open source.
  • on a aussi cité le cas de Nintendo qui récemment à banni l’utilisation de code open source dans les jeux wiiware (si j’ai bien compris). ce qui veut dire qu’on ne peut même pas utiliser la zlib par exemple :( . cette situation semble temporaire en attendant que le légal de chez Nintendo clarifie la situation.
  • les arguments classiques employés contre l’opensource sont
    • c’est gratuit donc pas sérieux (quid de soft comme apache, gcc, firefox, …).
    • il n’y a pas de support.
  • à l’opposé un middleware commercial a un support. le problème c’est que le support n’est pas toujours de qualité. que se passe-t-il en cas de liquidation/rachat de la société (on a parlé de l’expérience renderware de certains).
  • globalement il faudrait éduquer les décideurs aux logiciels libres, leur faire comprendre que ça un coup (maintenance, intégration, suivi de la communauté, intégration de patch, ….) mais qu’on n’a pas à faire à une boite noir. de plus le métier d’un éditeur de jeu n’est pas de faire un moteur 3D, donc utiliser un moteur free (tel que ogre3d), voir y participer n’est pas se tirer une balle dans le pied.
  • au final il faut être pragmatique est utilisé le meilleur outil pour faire le job, commercial ou opensource.
  • il y a aussi la distinction outils/libs à faire. généralement les “gens” sont moins retissant à utiliser des outils opensource pour leur prod (cvs/svn, ….). malgré tout on a eu un témoignage d’un switch cvs -> perforce pour cause de crash cvs qui a entrainer le perte de données (car il n’y avait pas de backup sérieux). pas évident que perforce aurait récupéré leurs données en cas de crash sans backup correct.

- logiciel libre : maitrise du code qu’on a pas avec une boite noir tel qu’un middleware
- mais ça a un coup quand même (le libre) …ne pas le cacher

Prototypage

pas trop suivi …. on est partie sur plus de proto avant une grosse prod … pas mal d’expérience de l’équipe de Darkworks. je m’attendais plus à du proto pour petit projet (même si en fait il n’y a pas trop de différence).

travailler chez soi – projet perso

trop de monde dure à suivre … globalement c’est super dur de se motiver. le travail en équipe peut aider. définir des cycles court. aller le plus vite possible à quelque chose de visible (ça rejoins à un peu ce qu’on disait le matin). certains remarque que pour y arriver il faudrait mettre en place des méthodes de gestion de projets aussi rigoureuse qu’au boulot alors que des fois on voudrait faire ça à la cool (moi j’aurais tendance à dire qu’il faudrait des fois être encore plus rigoureux qu’au boulot car on a encore moi de temps).

fédérer partage de techno et autres (indie ?)

  • session que j’ai initié … naïvement (et/ou par provocation) je voulais appeler ça “playall indie”. en gros l’idée était de dire qu’au final si on veut faire un jeu le moteur 3D, réseau, son, …. n’est qu’un outil donc autant ne pas perde de temps dessus. pareil pour les éditeurs de niveau, ressources, exporteurs, …. et autant se concentrer sur l’histoire, le gameplay, le visuel, …
  • donc est ce qu’il ne serait possible de mettre des “ressources” en commun. on a surtout parlé ressources techniques (code) mais on pourrait très bien étendre ça à d’autres sujets (focus groupes, markcom, …).
  • le premier constat est que si il y a partage de ressources il “faut” se mettre d’accord sur les règles du jeu. c’est à dire avec qui on partage, comment, les conditions, … le risque est qu’au final les différents participants se tire dans les pattes à coup de “moi j’en fais plus que toi, mon truc est mieux, ….”.
  • la solution la plus simple semblait de se dire qu’il fallait que tout soit opensource. n’importe qui participe, n’importe qui en profite.
  • on a donc besoin de créer/gérer une communauté : on a pris l’exemple de boost. l’intégration de modification, évolution est valider par un comité qui intègre dans la “branche” officielle. ce qui nous a amené à un peu parler de git (qui avait été le sujet d’une autre session du matin). git (et les outils de gestion de code décentralisé) semble intéressant pour gérer ce genre de projet.
  • on n’a pas conclu sur un truc clair mais (conclusion perso) il me semble intéressant de creuser l’idée de fédérer une communauté opensource pour le monde du jeu. il existe déjà des projets “sérieux” (ogre3d, bullet, box2d, cocos2d, …) ça manque peut être un peu d’outils et de personne s’investissant (plus facile à dire qu’à faire)
  • petit point important qu’on a abordé au début en fait : ça veut dire quoi indie. ou s’arrête la limite ? l’utilisation de l’opensource aurait aussi cet avantage : on ne met pas de barrière.

One Comment

  1. tof says:

    La plateforme de gestion d’équipe citée était http://www.assembla.com

    Trac/la gestion de projet par tickets a été aussi évoquée pendant la session projet perso comme moyen d’avancer globalement en ne s’occupant que d’une micro-tâche a la fois en fonction des créneaux qui se libèrent pendant le temps libre.

Leave a Reply