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é 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 jeu 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 tache 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 concerne la 3D. De l'autre coté les articles techniques ne discute 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 grand chapitres. Dans un premier temps nous allons analyser de 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 cela se traduit chacune des grandes étapes de développement.

II. Approche générale : le développement en équipe

II-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
  1. La conception pour fixer les objectifs et les méthodes employées lors du projet.
  2. L'implémentation pour réaliser les composants du projets.
  3. L'intégration pour associer les différents composants du projet.
  4. 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 bug 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 retour en arrières qui provoquerons 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 graphisme ou l'adéquation entre le game play et les situations décrites par le scénario.

Ok mais comment fait-on ?

Et 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 fini 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é 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 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.

II-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 à tout 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 simple.
  • 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.

III. L'efficacité du développement point par point

III-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 comportement 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 graphisme, 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.
Le répertoire du projet AITC
Le répertoire du projet AITC



Dans la figure ci dessus, le répertoire AITC contient les ressources du projet.

Ce répertoire doit être accessible à tous les membre de l'équipe via un serveur (site internet, ftp, répertoire sur un réseau local) et doit être sauvegardés 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 chance 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 2 lieux différents. Ne stockez que les 5 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. A 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 version.

III-B. Les systèmes de gestion de version

Le développement informatique est bien plus vieux que le jeu vidéo et un ensemble d'outils très performants on été mis au point pour vous faciliter la vie. Alors autant en profiter

III-B-1. Qu'est ce que la gestion de version ?

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é.

III-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 version "Vault Data Management". Virtools quand à lui est compatible avec « AlienBrain ». Quand à nous, nous avons choisit d'utiliser SVN qui a le bon goût d'être gratuit, très performant, et compatible avec n'importe quel type de fichier (et pas seulement avec de la 3D).

Il faut bien comprendre qu'un système de gestion de version est un outil incontournable pour une équipe qui souhaiterais 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 fichiers.

Avec gestion des versions
Sans gestion des versions
Avec gestion des versions
Avec gestion des versions



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.

Exemple d'historique d'un fichier .max
Exemple d'historique d'un fichier .max



Dans certains cas, on peut aussi effectuer la fusion de modifications entre plusieurs version 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 votre. 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 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.

III-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 aux adresses suivantes :

Attention, même si ces outils sont performants ils ne se substituent pas au travail gestion de projet. On ne doit pas oublier d'autres mesures comme les convention de nommage, ou l'affectation des tâches et des délais...

III-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 sauvegarde quotidienne du projet vers une autre destination grâce à CobianBackup
  • des postes de travail clients équipé :

    • D'un répertoire local de travail où sera placé la dernière version du projet par SVN
    • Des logiciels de travail : 3dsMAx, Virtools, photoshop....

Cette infrastructure peut sembler conséquente 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 conséquente 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.

III-C. Diviser pour mieux régner

Quand un fichier va contenir une trop grande quantité de donnée, 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 rallerez 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.

III-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 partie de ce décor pour les placer dans d'autres fichiers. L'entrée sera placé 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.

III-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éflexion du type « Modifier l'animation de marche du personnage ? Ptain...entre le .max et le moteur de jeu, je vais encore y passer 3 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 :

Image non disponible



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 modification 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 membre de l'équipe et il devient évident qu'un système d'intégration automatique est rentable très vite.

III-D-1. Application : le comportement de la caméra

Malik travail 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é. A son retour devant son PC, il teste son composant et a une nouvelle idée. Il décide de la tester en codant un nouvelle version de son composant caméra. Il le fait sereinement car il fait 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 stricte nécessaire. Et tout cela va participer à détendre l'atmosphère et instiller 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 gachi.

Maintenant vous pouvez ré investir ce temps économisé ailleurs : babyfoot, machine à café, ou médire des chefs.

IV. étude d'un cas

Maintenant que nous avons exposé les mesures à prendre, il est 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 » .
Le décor devra sembler crédible, vieux et impressionnant. L'accent sera mis sur la qualité graphique et, dans cette optique, on devra utiliser tous les procédés disponibles (lightmaps, normal mapping et shaders ).
En terme d'interactions, ce sera très simple : l'utilisateur pourra déplacer une caméra sans contraintes particulière. Elle devra simplement afficher les statistiques courantes pour évaluer les performances de l'application.


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.

IV-A. Étude des graphismes : le décor

Nous allons voir comment chacune des 4 é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.

IV-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érences a été constituée pour réaliser le décor. Cette banque d'image 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 et aussi crée.

Une première partie de cette banque d'image 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 compose.

Ces photos sont stockées dans un sous-répertoire « ReferencesPoitiersChatedrale » de manière à les dissocier des autres images de références.

Références générales du projet AITC
Références générales du projet AITC



Cette approche générale étant satisfaisante, l'équipe complète sa vision du décors grâce à des plan 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
Références détaillées : plan au sol
Références détaillées : plan au sol
Références détaillées : coupe transversale
Références détaillées : coupe transversale
Références détaillées : Coupe longitudinale
Références détaillées : Coupe longitudinale

A 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.

IV-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é consiste donc à limiter le nombre de polygone 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é 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.

Plan du décor modélisé
Plan du décor modélisé


Dans ce plan, un module de base est présent 3*8 fois à quelque détails prés.

Ce module est constitué de deux composants de base :

un autre composant intégrant simplement la colonne
un composant intégrant simplement la colonne
un composant constitué du plafond et du sol
un autre composant constitué du plafond et du sol


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.

Multiplication du module
Multiplication du module


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 graphiste choisis 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ée : 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.

Fenètre Xref
Fenètre Xref



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.

Module entrée
Module entrée
Module Nef
Module Nef
Module coté
Module coté



Dans « cathédrale.max », une fois que les modules de base sont multipliés par référence correctement et positionnées on obtient le résultat suivant :

Cathédrale assemblée
Cathédrale assemblée


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.

IV-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.

Tableau des composants à charger
Tableau des composants à 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 navigations.
  • « Interface » est un petit module qui permet de 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.

Script de chargement de composants
Script de chargement de composants

IV-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.

Tous les composants intégrés dans Virtools
Tous les composants intégrés dans Virtools


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'attends plus que les commentaires des testeurs pour ajuster ses prochaines orientations. Et d'ors et déjà, on pense à mettre en place un système de commentaires anonymes pour recueillir directement les impressions des testeurs.

V. Conclusion

Nous avons pu voir comment les graphiste 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élisation vont être corrigées et les textures et les shaders doivent être réalisé.

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 soeur d'un des membre de l'équipe a écrit un petit mail sympathique :
« Quoi ? Pas de collision ? Vous 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 bureaux, les programmeurs fous pensent à une méthode pour uniformiser les communications entre scripts.....

VI. épilogue

Image non disponible
Version actuelle



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 pas d'équipe : le projet a été réalisé par une personne seule, l'auteur du présent article, votre humble serviteur.

A titre indicatif, pour atteindre son niveaux actuel (article compris), le projet a demandé prés de 2 mois et demi à temps plein à une personne expérimenté 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és pour continuer cette aventure (documentation comprise), contactez moi par message privé. Et nous pourrons peut-être la fonder, cette équipe.

Image non disponible

VI. Remerciements et références

Merci à Alexandre Delan pour son aide pour cet article : son site personel héberge le forum francophone sur Virtools
Toujours pour Virtools, n'oubliez pas de visiter le forum officiel. Si vous cherchez une touche de 3DS 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é dont je soumetrais une critique trés prochainement.