Objectifs de l'article▲
Cet article a pour but d'illustrer concrètement quelques méthodes basiques pour le développement de 3D interactive en équipe. Ces méthodes s'appliquent au jeu vidéo, mais aussi à la réalité virtuelle, réalité augmentée ou tout autre domaine où il y a de la 3D interactive. On va aborder ensemble la vaste question :
« Comment organiser efficacement un développement en équipe ? »
En effet, on travaille toujours en équipe quand on recherche une certaine qualité. Dans le cas d'une équipe d'amateurs de jeux vidéo, le noyau dur sera constitué d'un graphiste 2D/3D, d'un programmeur et d'un level/game designer. Parmi eux, le plus expérimenté (ou le moins con) sera désigné comme chef de projet et aura comme tâche d'organiser le développement et d'affecter les tâches.
Sans ce minimum de compétences, il sera difficile de réaliser quelque chose de sympa. Par ailleurs, on remarque que ces compétences ne sont pas cumulées par la même personne.
Vous serez donc bien obligé de bosser en équipe… alors, autant savoir ce qui vous attend.
Le plus important est de s'attacher à ce que les différents intervenants du projet travaillent ensemble de manière coordonnée et sans gaspiller trop d'énergie. Il faudra éviter que Gérard écrase par inadvertance le boulot que François vient de faire dans le décor du niveau, ou que Malik perde son temps à coder un comportement pour la caméra alors que Simon a déjà développé quelque chose d'intéressant.
Ce sont avant tout des problèmes d'organisation et de communication à la charge du chef de projet. Mais il existe des outils et des méthodes qui peuvent grandement simplifier sa tâche et celle de toute l'équipe.
Dans la littérature très abondante qui existe sur le sujet de la gestion de projet, il existe assez peu d'exemples concrets qui concernent la 3D. De l'autre côté, les articles techniques ne discutent pas de la gestion de projet.
Nous avons donc fait le choix en rédigeant cet article d'avoir une approche mixte en illustrant très concrètement chacune de nos propositions en les appliquant à un exemple de projet nommé « Alone In The Church » (AITC). Pour tirer le maximum de cet article, le lecteur devra être déjà initié.
Espérons que tout cela puisse vous servir de base pour votre premier développement amateur en équipe (entre 3 et 10 personnes maximum).
Les logiciels utilisés sont 3dsMax 9, Virtools 3.5 et SVN. Les principes exposés ici sont suffisamment généraux pour s'adapter à d'autres moteurs.
L'exposé sera organisé en grands chapitres. Dans un premier temps nous allons analyser ce qu'est un développement en équipe pour déterminer ce qu'il faudrait mettre en place pour assurer sans tranquillisants. Nous verrons ensuite comment se traduit chacune des grandes étapes de développement.
I. Approche générale : le développement en équipe▲
I-A. Qu'est-ce qu'un développement en équipe ?▲
Précisons notre sujet : un développement est un processus de production numérique. Pour produire une application 3D, il faut suivre les étapes principales suivantes.
Les principales étapes de développement
- La conception pour fixer les objectifs et les méthodes employées lors du projet.
- L'implémentation pour réaliser les composants du projet.
- L'intégration pour associer les différents composants du projet.
- Les tests pour vérifier que le comportement des composants assemblés est bien celui attendu.
Même si ce processus est présenté ici comme une suite fixe d'étapes, dans les faits ce n'est pas un enchaînement statique, parfaitement prédéfini. En effet, dans tout processus de création, y compris numérique, des ajustements, des modifications, des corrections seront effectués. C'est obligatoire : votre personnage, votre décor, une interface ou même un bogue vont connaître plusieurs versions. Dans certains cas, et si vous n'êtes pas chanceux et/ou expérimenté, il y aura même certains retours en arrière qui provoqueront des pertes de temps considérables.
Vous l'aurez compris, les étapes décrites plus haut ne sont là que pour rationaliser votre approche et gagner en efficacité. Vous pourrez ensuite investir l'énergie économisée sur les aspects que vous jugerez essentiels : la jouabilité, l'originalité des graphismes ou l'adéquation entre le game play et les situations décrites par le scénario.
OK, mais comment fait-on ?
Eh bien, il faut faciliter le « work flow », c'est-à-dire le « flux de travail » littéralement. On doit considérer le travail réalisé comme un liquide ayant une source, une destination et un débit. En s'assurant que le travail de chacun des membres de l'équipe démarre au bon endroit et finit bien là où il doit finir (dans votre application et pas à la poubelle), vous garantissez un développement continu sans (trop) de surprise.
Pour assurer cette fluidité, nous allons nous attacher à ce qu'une modification puisse être effectuée et répercutée en consommant le moins d'énergie possible. Cela sous-entend qu'on doit aussi pouvoir simplement annuler cette correction si elle n'est pas satisfaisante malgré vos efforts.
Compte tenu de la quantité et de la complexité des données manipulées, c'est loin d'être évident. Mais si vous vous inspirez des mesures qui ont cours dans le milieu professionnel et que vous les mettez correctement en place, c'est tout le processus de création qui sera facilité, du graphiste au codeur.
Voyons ensemble ces principales mesures en gardant à l'esprit que « Faire un jeu est tout sauf un jeu ! » comme dirait l'autre.
I-B. Comment gagner en efficacité ?▲
Les principales mesures pour s'assurer que les modifications sont simplement apportées au projet sont les suivantes.
- Partager et sécuriser les données
Chaque membre de l'équipe doit avoir accès immédiatement à tous les documents du projet qui lui sont nécessaires, y compris la documentation. - Gérer les versions des fichiers
Pour chaque élément du projet, on doit connaître sa version actuelle et qui l'a modifié en dernier. - Diviser pour régner
On doit faire en sorte que chaque élément du projet ne traite que d'un domaine limité et soit réutilisable. Tout grand problème devra être divisé en sous-problèmes plus simples. - Compiler quotidiennement
On doit pouvoir compiler le projet tous les jours pour connaître son état d'avancement et pouvoir évaluer où l'on en est.
Ces mesures sont valables pour tous les éléments du projet : modélisation, texture, animation, documents de conception, programmes… tout, et pas d'exception.
Abordons tout cela dans le détail.
II. L'efficacité du développement point par point▲
II-A. Partager et sécuriser les données▲
L'ensemble des informations doit être accessible par tous les développeurs. Cela veut dire qu'on doit savoir si l'information qu'on cherche existe et, si oui, où elle se trouve. On pourra ainsi accéder aux documents de conception, à la bibliothèque de matériaux, à la documentation d'un composant ou tout autre élément du projet.
Concrètement, votre projet est un simple répertoire qui doit contenir au maximum dix-sous répertoires, eux-mêmes ne contenant que dix sous-répertoires et ainsi de suite. Tous les répertoires doivent avoir un nom explicite. L'arborescence précise dépend de la nature du projet, mais on peut déjà dire qu'il prendra la forme suivante :
-
MonProjetQuiDéchireTout
-
DocumentsDeConception
- Contient les documents de conception : Références, scénario, design et ainsi de suite
-
Ressources Virtools du projet
- Contient tous les composants de votre projet 3D, les textures, les modèles 3D les comportements de caméra…
-
Modélisations
- Contient les fichiers de conception de vos modèles 3D de votre projet, c'est-à-dire les fichiers 3DSMax
-
Graphisme2D
- Contient les fichiers conception de vos graphismes, c'est-à-dire les fichiers Photoshop ou autre
-
Compilation
- contient la dernière version compilée de votre projet, sous forme de fichiers VMO pour notre exemple
-
Prototypes
- contient les prototypes de vos composants
-
Dans la figure ci-dessus, le répertoire AITC contient les ressources du projet.
Ce répertoire doit être accessible à tous les membres de l'équipe via un serveur (site Internet, ftp, répertoire sur un réseau local) et doit être sauvegardé automatiquement à la fin de chaque journée de travail. Ainsi vous serez assuré qu'en cas de problème, seule une journée de travail sera perdue.
Ne sous-estimez pas ce point, car les disques durs vacillent bien plus souvent qu'on ne veut le croire. Qui plus est, plus vous aurez à bosser et plus votre matériel sera mis à rude épreuve, et plus il aura de chances de flancher.
Pour effectuer cette sauvegarde automatiquement utilisez un logiciel comme Cobian Backup (qui est gratuit) et sauvegardez vers un autre ordinateur. Vos données doivent toujours être en deux lieux différents. Ne stockez que les cinq dernières versions de votre arborescence en fonction de la place disponible.
Bien, vous avez enfin un répertoire distant qui contient la dernière version de votre projet : c'est le véritable dossier de votre projet. À partir de maintenant, vous ferez une copie sur votre poste de travail et travaillerez en local. Mais comment s'assurer que vous n'oublierez pas d'enregistrer les composants que vous modifierez ? C'est là qu'intervient le système de gestion de versions.
II-B. Les systèmes de gestion de versions▲
Le développement informatique est bien plus vieux que le jeu vidéo et un ensemble d'outils très performants ont été mis au point pour vous faciliter la vie. Alors autant en profiter.
II-B-1. Qu'est-ce que la gestion de versions ?▲
Comme son nom l'indique, c'est un procédé qui permet de gérer plusieurs versions d'un même fichier. En gros, chaque membre de l'équipe peut récupérer la dernière version des fichiers d'un projet, modifier le fichier de son choix et le livrer une fois le travail terminé.
II-B-2. En quoi est-ce utile pour développer de la 3D ?▲
C'est une technique ancienne qui date des systèmes UNIX et de CVS. Même si le monde de la 3D a mis du temps à s'approprier ces outils, ils sont maintenant considérés comme communs, voire indispensables dans le cadre d'une production sérieuse. Par exemple, 3dsMax9 est livré avec un système de gestion de versions « Vault Data Management ». Virtools quant à lui est compatible avec « AlienBrain ». Quant à nous, nous avons choisi d'utiliser SVN qui a le bon goût d'être gratuit, très performant, et compatible avec n'importe quel type de fichiers (et pas seulement avec de la 3D).
Il faut bien comprendre qu'un système de gestion de versions est un outil incontournable pour une équipe qui souhaiterait obtenir des résultats de qualité. Car qui dit « qualité » dit aussi « organisation et outils ».
On va évoquer rapidement les avantages et la souplesse que ces outils apportent, et qui leur ont permis de s'imposer.
Un intérêt assez visible consiste dans la simplification de l'arborescence de travail du projet : on ne se traîne pas les 25 versions d'un fichier.
|
|
|
Même si on dispose d'un unique fichier, on peut à tout moment récupérer l'historique des modifications effectuées ainsi que n'importe quelle version antérieure.
Dans certains cas, on peut aussi effectuer la fusion de modifications entre plusieurs versions d'un même fichier.
Par ailleurs, on peut bloquer les modifications sur un fichier pendant que l'on travaille dessus. De cette manière, vous pouvez empêcher un autre membre de l'équipe d'y accéder et de créer une version concurrente à la vôtre. Notez au passage que si deux membres de l'équipe travaillent sur le même fichier, le chef de projet n'a pas fait correctement son travail d'affectation des tâches.
Les fonctionnalités sont très nombreuses, et nous ne les citerons pas toutes. Mais pour finir, soulignons le fait que le système SVN peut fonctionner à distance. Les données de l'équipe qui sont centralisées sur le serveur distant peuvent être récupérées via le NET suivant différents protocoles, dont plusieurs sécurisés. La classe quoi.
II-B-3. Et si je veux m'y mettre ?▲
Comme dit plus haut, nous avons adopté pour cet article SVN (le successeur de CVS) et TortoiseSVN pour une intégration dans l'explorateur Windows.
Vous pouvez simplement l'installer chez vous en suivant les explications détaillées disponibles à l'adresse suivante :
Attention, même si ces outils sont performants ils ne se substituent pas au travail de gestion de projet. On ne doit pas oublier d'autres mesures comme les conventions de nommage, ou l'affectation des tâches et des délais…
II-B-4. Application concrète : une infrastructure▲
Concrètement, vous devrez disposer de l'infrastructure suivante
-
un serveur distant pour :
- Stocker votre projet sous la forme d'un répertoire géré par SVN
- Effectuer les sauvegardes quotidiennes du projet vers une autre destination grâce à CobianBackup
-
des postes de travail clients équipés :
- D'un répertoire local de travail où sera placée la dernière version du projet par SVN
- Des logiciels de travail : 3dsMAx, Virtools, Photoshop…
Cette infrastructure peut sembler substantielle au premier abord. Toutefois, si on considère les objectifs de qualité à atteindre et le fait que vous travaillez en équipe, elle n'est pas si volumineuse et reste accessible à des amateurs éclairés.
Enfin, si l'effectif de l'équipe devient important (>3), une petite amélioration peut consister à héberger sur votre serveur le site Internet de l'équipe. Réalisé sous la forme d'un site de news, il vous permettra d'assurer la communication du projet, en interne et en externe.
II-C. Diviser pour mieux régner▲
Quand un fichier va contenir une trop grande quantité de données, il faut le scinder en plusieurs fichiers de plus petite taille.
Le contenu de chaque sous-fichier sera beaucoup plus simple que le contenu du fichier original. Par conséquent, il sera beaucoup plus simple de s'y retrouver, pour intervenir et maintenir le fichier.
Par ailleurs, on permettra ainsi à plusieurs personnes de travailler en même temps sur ces données.
A priori, les critères pour décider si on divise un fichier sont :
- s'il devient difficile à manipuler ;
- si plusieurs personnes doivent intervenir régulièrement sur son contenu.
Par habitude, le moment de scinder un fichier est toujours repoussé. L'intérêt n'est pas évident au premier abord, mais une fois dans une période de stress vous râlerez abondamment sur ce p* de fichier ingérable. N'attendez pas que ça se produise, anticipez si vous le pouvez.
L'autre aspect de cette mesure est de vous amener à produire des composants indépendants et donc réutilisables. C'est excessivement important, car cela vous permettra d'utiliser vos composants dans un autre projet. De cette manière vous gagnerez un temps précieux.
II-C-1. Application : le décor▲
Prenons, comme par hasard, l'exemple d'un décor représentant une Cathédrale. On va scinder ce fichier, car le décor devient trop grand. On est constamment obligé de cacher des parties pour s'y retrouver et on perd un temps précieux.
On décide donc de prendre certaines parties de ce décor pour les placer dans d'autres fichiers. L'entrée sera placée dans un fichier à part, la nef aussi ainsi que les ailes. Le fichier original existera toujours, mais il ne contiendra simplement que des liens vers les autres fichiers rendant ainsi la maintenance bien plus simple.
Nous y reviendrons en détail dans la seconde partie de cet article.
II-D. La compilation quotidienne▲
On part du principe qu'on doit dépenser le minimum d'effort pour apporter une correction ou la supprimer. Il faut avant tout éviter les réflexions du type « Modifier l'animation de marche du personnage ? Ptain…entre le .max et le moteur de jeu, je vais encore y passer trois plombes ».
Dans une telle situation ce n'est pas tant la modification qui est fastidieuse, mais de la répercuter. Il va falloir naviguer dans des dizaines de menus pour spécifier le nouveau fichier à charger à la place de l'ancien…
On doit absolument éviter cette situation qui consiste à avoir peur d'apporter une modification. Si c'est le cas, c'est le moment de tirer la sonnette d'alarme : vous êtes en train de refuser d'améliorer votre propre projet.
Votre solution : l'intégration automatique. Elle est plus difficile à mettre en place au début du projet, mais vous ne pourrez plus vous en passer par la suite.
Pour vous en convaincre, comparons ensemble le temps nécessaire pour intégrer une modification dans le cas où le système d'intégration est automatique ou manuel.
On suppose que réaliser une modification prend 50 minutes et l'intégrer manuellement prend 10 minutes soit un temps total d'une heure. On suppose aussi que l'intégration automatique demande 10 heures d'efforts pour être mise en place, mais permet ensuite d'intégrer en seulement 2 minutes. Si on réalise un graphique pour comparer les temps pour réaliser une modification et l'intégrer manuellement ou automatiquement, on obtient le résultat suivant :
On voit très clairement que dès qu'on fait plus de 10 modifications, l'intégration manuelle prend toujours plus de temps que l'intégration automatique. Et plus vous ferez de modifications et plus il sera intéressant de mettre en place un système d'intégration automatique.
Effectivement cet exemple est un peu artificiel, mais réfléchissez : êtes-vous sûr que chaque membre de l'équipe fera moins de 20 modifications dans tout le projet ? Multipliez ça par le nombre de membres de l'équipe et il devient évident qu'un système d'intégration automatique est rentable très vite.
II-D-1. Application : le comportement de la caméra▲
Malik travaille sur la gestion de la caméra. Depuis deux jours il travaille beaucoup : l'équipe est en retard. Heureusement pour lui, il vient de terminer son composant et part chercher un café bien mérité. À son retour devant son PC, il teste son composant et a une nouvelle idée. Il décide de la tester en codant une nouvelle version de son composant caméra. Il le fait sereinement, car il sait que même si son nouveau composant n'est pas bon, il pourra revenir à la version précédente en très peu de temps. Par contre, si son composant est bon il peut participer à augmenter la qualité du projet. En plus, Malik aura une bonne image de lui ; l'équipe sera rassurée de voir qu'elle peut produire plus que le strict nécessaire. Et tout cela va participer à détendre l'atmosphère et installer une bonne ambiance : ce qui ne peut être que bon pour le projet.
Grâce à l'intégration automatique, substituer deux versions d'un composant est quasi instantané.
En supprimant l'étape d'intégration manuelle, on arrive plus vite à la phase de test. Ainsi on peut remarquer plus tôt les défauts et les corriger aussi plus rapidement. On favorise donc la qualité.
Par ailleurs, remarquez que le temps nécessaire à une intégration manuelle n'est plus gaspillé. Si la personne qui apportait la modification est compétente, ça aurait été un véritable gâchis.
Maintenant vous pouvez réinvestir ce temps économisé ailleurs : babyfoot, machine à café, ou médire des chefs.
III. Étude d'un cas▲
Maintenant que nous avons exposé les mesures à prendre, il est temps de passer à l'application. Pour rester efficaces et éviter de nous perdre dans une trop grande complexité nous allons nous cantonner à une partie du projet : le décor.
On souhaite réaliser un décor de niveau de jeu pour effectuer une démonstration technique de notre savoir-faire. Le projet est précisé dans un document de conception de base : le synopsis.
|
Synopsis du projet AITC |
|---|
|
On souhaite réaliser une démonstration de notre savoir-faire en réalisant une visite virtuelle d'un « château-cathédrale ». |
Vous noterez que ce synopsis n'est pas trop détaillé. L'équipe n'a pas de vision précise et sait que le projet évoluera en fonction des premiers résultats. Pour autant elle ne souhaite pas perdre le travail qu'elle aura effectué pour en arriver là.
Dans la partie suivante, nous allons suivre le travail des membres de l'équipe en charge du graphisme. On suppose que le reste de l'équipe va fournir les composants qui n'auront pas été produits dans cette partie.
III-A. Étude des graphismes : le décor▲
Nous allons voir comment chacune des quatre étapes de développement a été abordée par l’équipe des graphistes, et comment se traduisent concrètement les préconisations du chef de projet.
III-A-1. Conception : étude et design du décor▲
Sur la base de l'orientation définie par le synopsis, une banque d'images de référence a été constituée pour réaliser le décor. Cette banque d'images est stockée dans un sous-répertoire « EtudeGraphiqueDecor » dans le répertoire « DocumentsDeConceptions ». Un fichier texte contenant les réflexions des graphistes sur le sujet est aussi créé.
Une première partie de cette banque d'images est constituée de photographies réalisées dans un lieu s'approchant correctement de l'esprit du projet, ici la cathédrale St Pierre de Poitiers. Ces photos permettent d'approcher dans le même temps le décor dans sa globalité et les détails qui le composent.
Ces photos sont stockées dans un sous-répertoire « ReferencesPoitiersChatedrale » de manière à les dissocier des autres images de référence.
Cette approche générale étant satisfaisante, l'équipe complète sa vision du décor grâce à des plans architecturaux qu'elle stocke parmi les documents de conceptions dans le sous-répertoire « RéférencesPoitiersPlans ».
L'arborescence devient donc :
-
« DocumentsDeConceptions »
-
« EtudeGraphiqueDecor »
- « ReferencesPoitiersChatedrale »
- « RéférencesPoitiersPlans »
- Decor.doc
-
À cette étape, l'équipe des graphistes considère que la conception est suffisamment avancée pour se lancer dans la modélisation du décor.
III-A-2. Réalisation : modélisation du décor▲
L'objectif est de trouver le bon compromis entre qualité visuelle et performances.
L'approche adoptée consiste donc à limiter le nombre de polygones présents dans la scène. Les formes générales vont être simplifiées, et des textures seront préférées à la géométrie pour réaliser les détails. Enfin, comme on considère que l'utilisateur ne pourra se déplacer que dans l'intérieur de la cathédrale, les faces qui ne seront jamais vues seront supprimées.
Toujours pour simplifier la modélisation et limiter le nombre de faces, l'équipe choisit d'appliquer la stratégie du « diviser pour régner ». En effet, une cathédrale est un cas assez évident de motifs répétés. L'équipe va donc utiliser des éléments de base qui seront ensuite multipliés pour créer le décor.
Enfin, une simplification générale du plan réel est effectuée pour obtenir le plan du décor modélisé. Sur ce plan, un repère de référence est mis en place sous la forme d'un damier pour placer et retrouver facilement un objet particulier.
Dans ce plan, un module de base est présent 3*8 fois à quelques détails près.
Ce module est constitué de deux composants de base :
|
|
|
Multiplié correctement, ce module permet de générer assez simplement une bonne partie du décor. En plus, en utilisant dans 3dsMax le clonage par référence de l'élément de base, l'équipe s'assure que seul un objet en mémoire est nécessaire. C'est une belle optimisation.
Le résultat est globalement satisfaisant, mais il apparaît évident que la scène va devenir très rapidement extrêmement complexe. En effet, beaucoup d'autres éléments vont venir se greffer sur la scène déjà existante.
L'équipe des graphistes choisit donc encore une fois de « diviser pour régner » pour sa gestion des fichiers. Chacun des éléments de base (ou module) de notre scène va être placé dans un fichier séparé. Un fichier vide de toute géométrie propre va être créé : le fichier « Cathédrale.max » qui va contenir des références vers les modules.
D'un point de vue technique, on va faire usage des « Xref Objects » pour pointer les modules dont on a besoin.
Cette solution est très intéressante à plus d'un titre. En premier lieu, l'usage de références l'optimise fortement et permet une maintenance aisée. Mais le plus important est que grâce à l'usage de « XRef objects » plusieurs personnes peuvent intervenir en même temps sur le décor. Un graphiste peut retravailler la colonne pendant qu'un autre s'attache à détailler un peu plus les murs latéraux.
De cette manière les différents modules ont pu être réalisés rapidement : la charge de travail a été répartie entre les différents graphistes, et on a su éviter un goulot d'étranglement.
|
|
|
|
|
|
Dans « cathédrale.max », une fois que les modules de base sont multipliés par référence correctement et positionnés on obtient le résultat suivant :
La scène est ensuite exportée dans les ressources du projet au format Virtools « Cathe.nmo ». Notre décor apparaîtra bien comme un composant unique alors même qu'il est l'assemblage de différents composants.
III-A-3. Intégration▲
Pendant que les graphistes travaillaient, les programmeurs ont mis en place une composition Virtools (.cmo) qui contient un petit script qui permet l'intégration automatique. La composition ne contient en fait que deux informations : les composants à charger et comment les charger.
En outre, les programmeurs ont réalisé les composants supplémentaires suivants :
- « Statistics » va permettre d'afficher les statistiques courantes (nombre de faces affichées, fréquence de rafraichissement).
- « AitcFreeCam » est la caméra de base qui permet la navigation. C'est une adaptation de la « FreeCam » de base fournie avec Virtools. On a simplement modifié l'affectation des touches de navigation.
- « Interface » est un petit module qui permet d'afficher et de masquer le calque « Fil de fer » et les textures. Il a été réalisé pour permettre de saisir la complexité de la modélisation.
- Enfin « FxFire » est un petit effet spécial simulant du feu dans la cheminée. Comme le projet avançait bien, il a été réalisé pour mettre un peu de vie dans ce décor, encore un peu vide.
Chaque composant est stocké dans le répertoire des ressources, avec son aide en HTML et un fichier expliquant son utilisation, de la même manière que comme les composants par défaut de Virtools. Ainsi la documentation est assurée.
III-A-4. Tests▲
Enfin, la première compilation du projet est réalisée. Après les ajustements nécessaires, une version satisfaisante est obtenue.
L'équipe publie cette version directement dans une page de Testpage de test sur le site du projet. En effet la technologie employée permet une intégration directement en page web, alors autant en profiter.
http://nalfouille.is-a-geek.org/ProjetsPerso/Tuto/Test.html L'équipe n'attend plus que les commentaires des testeurs pour ajuster ses prochaines orientations. Et d'ores et déjà, on pense à mettre en place un système de commentaires anonymes pour recueillir directement les impressions des testeurs.
IV. Conclusion▲
Nous avons pu voir comment les graphistes ont appliqué les mesures pour le travail en équipe. Correctement orientés, ils ont pu rapidement réaliser un travail satisfaisant.
Toujours est-il que beaucoup de choses manquent ou vont changer : certaines modélisations vont être corrigées et les textures et les shaders doivent être réalisés.
Le résultat final ne sera obtenu qu'après de multiples itérations successives et tous les membres de l'équipe le savent. En discutant et en faisant en sorte que chacun puisse faire correctement son travail, ça devrait passer tranquille.
Enfin le premier commentaire arrive : la petite sœur d'un des membres de l'équipe a écrit un petit mail sympathique :
« Quoi ? Pas de collision ? Vous n’avez jamais entendu parler d'arbre BSP ? »
Bing, c'est ça l'assurance qualité : être capable d'entendre ce que les autres disent sur votre produit, et ce n'est pas toujours facile.
Mais déjà, dans l'ombre de leur bureau, les programmeurs fous pensent à une méthode pour uniformiser les communications entre scripts…
V. épilogue▲
Après un travail sur l'ensemble des composants, le projet a sensiblement évolué pour atteindre une nouvelle version disponible sur cette page. C'est mieux non ?
Pour l'instant le projet reste figé à cette étape. Il n'est pas abandonné, mais disons que l'équipe a besoin de faire un break. En fait, il n'y a pas d'équipe : le projet a été réalisé par une personne seule, l'auteur du présent article, votre humble serviteur.
À titre indicatif, pour atteindre son niveau actuel (article compris), le projet a demandé près de deux mois et demi à temps plein à une personne expérimentée dans tous les secteurs du développement.
J'espère que ceci vous permettra d'évaluer plus précisément les efforts et délais nécessaires pour votre propre projet, et que les recommandations vous permettront d'obtenir un résultat similaire en moins de temps, ou un résultat de meilleure qualité dans le même temps.
Si vous êtes intéressé pour continuer cette aventure (documentation comprise), contactez-moi par message privé. Et nous pourrons peut-être la fonder, cette équipe.
VI. Remerciements et références▲
Merci à Alexandre Delan pour son aide pour cet article : son site personnel héberge le forum francophone sur Virtools
Toujours pour Virtools, n'oubliez pas de visiter le forum officiel. Si vous cherchez une touche de 3D en plus, visitez le site de Nicolas Lefèvre.
Enfin, je vous encourage chaudement la lecture Conception et architecture des jeux vidéo de Andrew Rollings et Dave Morris. C'est un ouvrage d'une très grande qualité au sujet duquel je soumettrai une critique très prochainement.