Bonjour,

Effectivement, l'objectif que l'on s'est fixés à court terme est la création d'un prototype jouable (ce qui inclut les différents aspects qui participeront à l'immersion du joueur à mon sens, même si on a sans doute pas la même définition de prototype).

Je comprends ce que tu veux dire, mais pour ma part je vois les choses de la manière suivante : l'idée n'est pas de donner du boulot aux gens à ce stade, c'est d'avoir une sorte de temple où faire de la recherche, avec donc une démarche de chercheur (c'est l'attitude avec laquelle il faut aborder le projet), avant de pouvoir proposer un quelconque prototype à qui que ce soit. D'autant que le stade actuel est particulièrement intéressant parce qu'on met en place le workflow et les grandes décisions autour du desgin, donc c'est un moment intéressant sur lequel venir travailler.

Soyons clairs, j'invite les gens éventuellement intéressés à venir participer s'ils le souhaitent, à un stade de développement où il y a plein de choses intéressantes à mettre en place, je ne monte pas un projet pour faire travailler des développeurs indépendants (enfin pas à court terme). C'est effectivement important de préciser cela, merci de l'avoir souligné.

Et si, on a besoin de 3D artists parce qu'on en est au moment où on on va pas tarder à geler définitivement des choix de design importants, ce serait bien de pouvoir démultiplier les points de vue. On à besoin de character animators parce qu'on est en mesure commencer à travailler sur l'animation (d'autant qu'il y a pas mal de boulot avec des rigs un peu particuliers qui s'éloignent des formes humanoides classiques, donc ça va prendre du temps), on a besoin de compositeurs pour la même raison qu'on a besoin de 3d artists, pour travailler sur l'environnement en collaboration, etc. La démarche qu'on veut entreprendre, c'est justement de faire se répondre les différents espaces de travail et les faire travailler ensemble. Ce serait chouette de voir ce que ça donne avec une équipe complète et quel impact ça aura sur les différentes phases de développement. Voilà pourquoi on invite les gens à venir.

Sur la question de la compétence, on est pas à la recherche de grosses brutes, d'autant qu'on est dans une démarche d'apprentissage sur plein de domaines également, mais il faut quand même quelques bases à la fois en termes techniques et à la fois en terme de workflow. Et puis c'est vachement bien d'avoir plein de marge pour évoluer.

Les screens viendront, avec peut-être quelques éléments de gameplay (mais j'aime pas montrer des trucs avec des white box alors on verra), d'ici peu !

EDIT : ah et concernant notre expérience, effectivement c'est important : pour ma part c'est mon premier projet de jeu vidéo spécifiquement, j'ai des compétences en gestion de projet, management, droit de la consommation, compétences pour lesquelles j'ai un cv qui peut éventuellement se demander, et spécifiquement sur le jeu vidéo je suis intermédiaire en développement (en train de passer la certif unity, je verrais quand j'aurais le temps pour faire ça de manière très officielle) et intermédiaire en environment design. En ce qui concerne mon collaborateur, c'est un 3d artist, il vient de l'industrie, et comme je vais pas faire le boulot à sa place il va venir se présenter à un moment ou un autre.

D'accord avec toi sur l'essentiel. Cependant, j'ai assez d'expérience dans la réalisation de projets pour savoir comment m'y prendre, et la manière dont j'ai choisi de bosser est due à plusieurs facteurs, liées à mes conditions de vie etc. C'est sans doute pas idéal, mais c'est comme ça.

Plusieurs problèmes dans les points soulignés, ou en tout cas points qui me semblent discutables :

-"A mon avis il faudrait que tu détaches pour l'instant ton projet de la license Warhammer" Effectivement, si on était dans le contexte des années 2000 où GW faisait extrêmement attention à leur license, jouer la sécurité serait la meilleure option pour voir le projet aboutir à quelque chose. Cependant, leur politique vis à vis de leur IP a bien changé ces dernières années et s'est vachement ouverte aux jeux vidéos. En gros ils laissent les développeurs faire, ça fait de la pub pour un univers qui est désormais archivé chez eux depuis the end times. Donc de ce côté là, c'est pas ce qui m'inquiète.
Jouer la sécurité oui, mais je vois mal comment on peut faire des choix de design en se détachant de l'identité choisie. Se voir refuser l'utilisation d'une license, quelles que soient les précautions prises, c'est une invitation à retoquer l'art de A à Z.

- "Intégrer des personnes à ton projet au ptit-bonheur-la-chance est hyper casse-gueule, et peut rapidement devenir un bien plus gros handicap qu'une aide" Pas faux, mais je suis convaincu (et c'est l'expérience qui m'a convaincu, pas un quelconque fantasme), que le recrutement est un sujet sérieux, et donc qu'il faut prendre les gens au sérieux. Créer un espace dans lequel on peut les faire bosser, et voir petit à petit comment ils s'intègrent à une équipe. Oui, ça prend du temps, ça demande des aménagements, mais ça a plusieurs avantages : coupler le processus de recrutement à un processus de socialisation, en gros, quand on te recrute t'as déjà des méthodes de travail qui collent avec la manière dont on bosse, et enfin, ne pas louper des talents qui se seraient mal présentés (et inversement repérer assez vite les éléments qui ont un super cv mais qui sont de vraies épines dans le pied). Donc la manière de faire, c'est de laisser la porte relativement ouverte, de laisser aux gens la possibilité de venir s'essayer. Pas besoin de contrat pour le moment pour protéger le contenu (ça c'est dû à la manière dont on intègre le contenu dans unity et dont on utilise les mesh produites, je développe pas plus), mais effectivement la question se posera à un stade plus avancé de développement). Et on demandera pas aux gens de faire 4000 assets et puis s'en va, c'est pas comme ça qu'on va bosser, mais je vois l'idée soulignée^^.

- Paragraphe sur le chef : tout à fait d'accord, il s'agît d'avoir une vision claire et une vue d'ensemble du projet, de donner des directions, des limites etc, et de pouvoir trancher de manière éclairée. Fort bien, je passe sur le procès en incompétence qui arrive un peu vite à mon goût, je comprends ta démarche et je trouve ça sympa de filer des conseils. Simplement, j'ajouterai une objection à ce que tu dis : construire un prototype et ensuite aller vers les gens c'est bien, mais une fois le projet porté sur un produit monétisable, avec une équipe de pro motivée par les possibilités éventuellement financière qui rend le projet viable, on est face à des problèmes qu'on peut traiter en amont et qui font perdre du temps (beaucoup beaucoup de temps en fait) : harmoniser les workflow, acculturer les uns et les autres à des manières de bosser spécifiques etc. En montant le prototype en question en équipe, on est prêts directement pour la phase d'après. Et dernier argument, qui est il me semble le plus important, une entreprise c'est avant tout un écheveau de relations humaines. Faut partir là dessus d'abord pour s'assurer que la suite de l'aventure se passe sainement et sans les coups fourrés auxquels tu fais référence (tout en étant pas naïf, je suis bien d'accord).

- Enfin, c'est un peu exagéré de dire "arriver sur un mode "j'ai plein d'idées pour un fantasme de jeu mais j'y connais rien, venez faire le jeu que je voudrais gratos svp" ", encore une fois je vois ce que tu veux dire, mais il me semble que c'est pas comme ça que j'ai présenté les choses (et c'est pas comme ça que les choses se passent). Par exemple sur les éléments de gameplay cités, j'ai déjà des choses codées qui marchent (loin d'avoir tout évidemment je suis tout seul), et je sais ce qu'il me reste à faire pour arriver à un truc satisfaisant. Donc j'attends pas des nouveaux qu'ils fassent le boulot à ma place et c'est effectivement présomptueux de venir le présenter comme ça. Je suis pas là non plus pour vous "démontrer" ma capacité à, je passe pas un entretien d'embauche, et si ça plaît pas à des gens j'en ai malheureusement pas grand chose à faire. J'ai jamais vu aucun projet aboutir sans qu'il n'y ait eu entre les collaborateurs, à certains moments, des gestes de foi ou des gestes de confiance. Alors oui, je demande aux gens de rentrer dans le projet sur ce genre de geste. Y'a d'autres manières de faire, mais c'est comme ça que je fais. Cela dit, je trouve que tu as tout à fait raison de rappeler les risques que cette manière de faire amène. Et puis, que chacun prenne ses responsabilités, moi comme les autres.

Alors oui, y'aurait fallu que je puisse mettre quelques images ou quelques éléments de mécanique pour montrer la faisabilité de ce qui est proposé, et pour que les gens se fassent une idée de si le projet peut coller aux ambitions à un moment ou un autre, mais j'ai rien de présentable tout de suite (on va en mettre au fur et à mesure, dès qu'on a des choses un peu léchées, mais j'aime pas mettre des photos de cubes blancs en guise d'éléments de présentation). M'enfin, ça viendra bien assez tôt.

En gros, j'ai bien conscience des frilosités éventuelles du milieu dans lequel je viens avec mes gros sabots, mais je compte venir y amener ma manière de bosser que j'importe d'autres milieux professionnels où j'ai pu voir que ça marchait bien, et que ça marche toujours très bien à l'heure actuelle. Mais clairement, comme tu le soulignes, on ne pourra en reparler posément que d'ici un an ou deux, quand j'aurais mené mon combat jusqu'au bout. Dans l'immédiat, si personne ne vient avant qu'on ait effectivement un prototype jouable, c'est pas grave, les gens auront juste loupé des étapes intéressantes. Et mine de rien y'a des curieux...

Enfin, sur les ambitions, j'ai lu pas mal de trucs justement dont beaucoup de développeurs expérimentés qui, à raison, mettaient en garde contre le surplus d'ambition. En fait ça se passe exactement de la même manière dans tous les milieux où à terme on compte produire quelque chose. Un truc cependant dont il faut se méfier dans cette démarche : brider ses ambitions pour un projet X ou Y, on le fait quand on évalue la faisabilité du projet, donc avant de le présenter au quidam, et on le fait d'abord pour des questions de faisabilité, liées à la technique, à la timeline etc. Ici, j'ai "la chance" de justement pouvoir me passer de timeline et de pouvoir dire ce que je peux et ne peux pas faire parce que j'ai essayé en amont de les faire. Puis, une fois ceci établi, je vise un cran au-dessus, pour me fixer une marge d'amélioration de mes compétences à atteindre. Ca à l'air d'être un peu tiré par la carapace dis comme ça, mais c'est la base pour pouvoir créer des innovations. Et ça peut d'ailleurs s'appliquer dans n'importe quelle industrie. Or j'estime qu'un milieu comme celui des JV, avec une industrie qui est depuis quelques années dans le satisfecit infini, à besoin qu'on y réintroduise des innovations, et que les développeurs indépendants peuvent amener ça (à condition qu'ils crèvent pas la dalle, ce qui est malheureusement le cas en ce moment). Ca implique de prendre son temps pour faire... De la R&D ! Mince c'est un peu ce que je propose aux gens de venir faire non ?

Voilà, j'espère avoir pu un peu clarifier ma démarche. En tout cas, merci de soulever ces points qui sont de vrais points épineux, voir pour certains de vrais points de débat.

Hey le papier est cool, t'en as d'autres comme ça ? Les PBD c'est pas ce qui est utilisé par le mec qui fait EBS ? Ca c'est pas de la R&D, c'est de la recherche fondamentale, et non je compte pas faire une thèse. De la R&D sur un projet, un process, ou un une technologie donnée ça va de la simple copie (samsung copie telle ou telle tech de chez apple par exemple, ou l'inverse peu importe), qui est un processus de R&D à l'innovation complète basée sur la recherche fondamentale, ou comment on développe de nouvelles technologies/techniques en se basant sur les apports de la recherche fondamentale (donc comment j'utilise le papelar que tu viens de me sortir pour développer de nouvelles techniques). La R&D ça inclut aussi le travail sur les process de production (ici on parle de workflow), et ça inclut aussi, rentrez vous ça dans le crane messieurs les industriels, la recherche artistique. Donc oui, je prétends faire de la R&D, mais bien sûr pas de la recherche fondamentale. En économie, la R&D qu'une firme donnée va vouloir développer va dépendre de son capital technique et de son capital en terme de connaissances fondamentales (même si la grande tendance, c'est plutôt orienté capital technique, sauf dans les multi-nationales et les "firmes d'état" (genre pentagone), qui peuvent investir sans risques dans la recherche fondamentale).

Sur la question de la crédibilité, ok pour dire qu'il faut se vendre, mais là je viens poser mes balloches sur la table en disant je fais ça, qui m'aime me suive. On se vendra quand on aura quelque chose à vendre (oui, un prototype !).

Sur l'expérience, est-ce que tu considères que la gestion de projet dans le jeu-vidéo est spécifique et qu'aucune compétence n'est transposable ? Si c'est le cas, ce n'est pas un point de vue que je partage. Mais oui, je comprends en quoi ça peut gêner d'éventuels intéressés.

Donc selon toi, il faudrait que je concentre mes efforts sur un prototype, je veux bien, mais j'ai du mal à en identifier le contenu. Si on prend un exemple simple : actuellement on peut mettre quelques scènes en place dans lesquelles faire évoluer le joueur, on a quelques modèles qui peuvent faire des trucs, et imaginons que veuille mettre dans ma démo l'inventaire. J'ai un prototype d'inventaire préparé mais auquel il faut ajouter pas mal de choses pour que ça pique pas les yeux (comme des sprites par exemple), et qui devra évoluer quand j'aurais mis en place certains éléments de gameplay qui ne sont pas encore implémentés. Dans l'optique de la démo, j'en fais quoi ? Je le fous tel quel ? Je ne trouve pas ça satisfaisant et ce n'est pas le genre de travail que je veux présenter. Je me concentre là dessus pour le finir ? A ce moment là je vais devoir faire ça pour tout les éléments que je veux intégrer dans la démo, et autant faire le jeu tout seul. Tu vois, je veux bien mais j'arrive pas à trouver un genre de paquet à montrer qui soit satisfaisant. C'est grave docteur ?

En me relisant, je me suis pas trouvé très clair sur la R&D, mettons bien l'accent sur la différence qu'il y a entre R&D et recherche fondamentale, qui ne sont pas du tout la même chose. La R&D est spécifique à une entreprise donnée, selon ses différents capitaux (on pourrait d'ailleurs en faire un capital, même si je connais aucun économiste qui le fais aussi clairement), et n'est dépendante de la recherche fondamentale et de ses évolutions que de manière parcellaire. En gros, si on schématisait tout ça, le socle commun à tout le monde c'est la recherche fondamentale, et la R&D c'est les connaissances propres à chaque entreprise. C'est très important parce que ça veut dire que si une entreprise (admettons mon studio indépendant que j'aurais intelligemment nommé super-copter) veut entrer sur le marché, elle entrera avec le socle de connaissances communes (les avancées de la recherche fondamentale) PLUS le stock de R&D qu'elle aura pu développer en amont (ou après son entrée sur le marché). Si la recherche fondamentale avance, donc s'il y a des chercheurs qui viennent produire des connaissances comme tu en faisais mention précédemment, ça bénéficie à tout le monde (parce que ça rentre dans le socle commun de connaissances; qui, oui, n'est pas si commun que ça). Or si la R&D avance, cela ne bénéficie qu'à l'entreprise. Faire de la R&D c'est produire des connaissances spécifiques, qui existent peut-être déjà, celles-ci ne passant de toute façon pas par le filtre habituel (peer review etc.), qui finiront dans le stock de l'entreprise et dont l'utilisation est prévue pour l'entreprise. La seule "certification" des connaissances produites par la R&D qui n'en est pas vraiment une, c'est le brevetage, qui dépend de comment l'entreprise perçoit la connaissance ou le process produit. On est donc face à deux processus finalement très différents.

Hm ok je vois où tu veux en venir. Genre un build qui donne simplement une idée d'où je veut aller avec mes mécaniques de gameplay, juste pour montrer que c'est faisable. On va essayer de faire ça dès que possible alors.

Sur la R&D : non justement, il s'agit de mettre en avant l'importance du R de R&D et de montrer à quel point la recherche (fondamentale) est cruciale pour TOUT LE MONDE. Mais c'est un processus qu'on doit impérativement différencier de la R&D que fait une firme, même si elle peut par exemple financer de la recherche fondamentale pour un projet d'application quelconque par la suite. Que ça s'appelle de la R&D alors que oui c'est du développement, c'est pas de mon fait, mais la distinction est importante pas uniquement parce qu'il s'agit de terminologie, mais surtout parce que ça permet de bien identifier les canaux d'investissements et leurs objectifs (et accessoirement de faire comprendre à des preneurs de décision qu'il serait bien de financer un peu de RECHERCHE, et un peu moins de R&D dans des domaines spécifiques, comme par exemple la pharmaceutique).

Sur la gestion de projet : j'utilise ce terme parce que c'est un terme générique à peu près compréhensible par tout le monde, même ceux qui l'aiment pas, mais je suis d'accord que c'est un terme fortement discutable.

Et toi sans indiscrétion, tu as des exemples de projets sur lesquels tu as bossé et qui ont abouti ? Ou de projets sur lesquels tu bosses ?