Maquette pour le jeu Bürgermeister
Explication détaillée des résultats à obtenir
Comme on l'a vu plus haut, il s'agit de l'axe principal du stage. Les objectifs principaux de cette maquette du jeu Bürgermeister étaient les suivants :
Axes d'étude et de recherche choisis
L'un des buts de cette maquette était de voir à quel point certains modules DMS existants pouvaient être réutilisés. C'est donc dans cette optique de programmation minimum qu'a été inscrit le développement du site Bürgermaquette. Il fallait déterminer quel module était nécessaire à telle et telle tâche, décrire son fonctionnement s'il n'existait pas (cf. annexes : les modules dans Venise) et le simuler ou en donner une esquisse dans la maquette. Il fallait donc faire une analyse assez poussée des modules existants, de leurs possibilités, de leurs manques pour avoir une bonne connaissance de l'existant avant d'imaginer les nouveaux modules. Déterminer l'utilité de tel module dans le développement du jeu était aussi une étape nécessaire pour créer un planning de production. En effet, savoir qu'un module existant allait pouvoir être réutilisé apportait deux informations intéressantes pour le chef de projet : d'une part ca faisait une fonctionnalité de moins à concevoir et à programmer, d'autre part on pouvait donner le temps qu'avait duré le développement du module en question, ce qui est une bonne façon d'estimer le temps de développement d'autres modules de complexité comparable. D'ailleurs mon travail consistait aussi à développer partiellement un module pour, là encore, donner une idée de la complexité et du temps de développement à accorder à chaque module pendant la future phase de production.
Déroulement concret des études, expérimentations, mises au point
Comme on vient de le voir, il fallait composer une maquette donnant l'idée générale décrite par le game-design. Et cette maquette devait être constituée de modules DMS existants, pour ne pas allonger indéfiniment la période de pré-production. Il a fallu alors tester presque tous les modules existants pour déterminer s'ils pouvaient être utiles dans la maquette, synthétiser le game-design, et faire un site maquette qui réunisse les modules intéressants en donnant l'ambiance générale du futur jeu.
Les tests que j'ai menés pour mieux connaître les modules ont été longs à faire et relativement harassant, surtout à cause du tâtonnement obligatoire dans l'absence quasi complète de documentation sur les modules à ce moment (cf. annexes : extraits de la documentation de l'éditeur de sites SCS). Il a fallu faire une structure de test commune et intégrer un à un chaque module pour vérifier en quoi il pouvait être ou non intéressant pour la suite du développement de la maquette. Et à chaque module, il fallait deviner à partir des noms le plus souvent relativement peu expressifs des actions et des réflexes de ces modules comment les relier les uns aux autres pour tester leurs fonctionnalités, ceci sans compter que pour certains, il fallait revoir la base commune pour l'adapter aux spécificités du module en question. En fin de compte, cela m'a permis quand même de mieux maîtriser l'outil SCS Cryonics Pro et d’entraîner mon intuition pour deviner la façon dont il fallait lier certains des modules.
Lors de la lecture approfondie du game-design pour en faire une synthèse (cf. annexes : extraits du game-design de Bürgermeister), j'ai déterminé à quoi ressemblerait la maquette pour à la fois coller au game-design et être relativement facile à développer :
Lors de la lecture approfondie du game-design pour en faire une synthèse, il m'a fallu faire une liste des besoins en modules pour pouvoir faire la maquette :
Voici maintenant la liste des modules qui correspondent aux éléments ci-dessus :
Voilà donc les modules existants dont on pouvait se servir pour coller au plus près du game-design. En plus de cette partie orientée sur les possibilités techniques des modules existants, il fallait aussi avoir des objets 3d qui ressemblent aussi au thème du jeu. Voici une liste des ressources graphiques utilisées par la maquette :
Il fallait ensuite réunir les ressources graphiques au sein de scènes 3d, les organiser pour donner une certaine atmosphère aux quatre lieux. N'ayant pas de formation d'architecte d'intérieur, il a fallu faire à l'inspiration du moment, en suivant l'esprit fonctionnel de chaque lieu :
- le village est resté tel quel :
- la grande place a été agrémentée de deux portes d'accès pour le casino et la salle des ventes, ainsi que de plusieurs faux avatars qui se déplacent dans la ville :
- le casino s'est vu meublé de tables de jeux provenant de la bibliothèque d'objets médiévaux, ainsi que d'un coin de change avec des caisses d'or et de faux avatars en position autour de certaines tables :
- la salle des ventes s'est vue peuplée d'un annonceur public :
Tout cet agencement des lieux 3d ainsi que la préparation des zones cliquables et des mouvements de avatars a été réalisé dans l’éditeur du module C3d2, qui est relativement fastidieux à utiliser. Le temps de mise en place de tous ces objets les uns par rapport aux autres a été assez long, eût égard à mon manque d'habitude à utiliser les modeleurs 3d.
Une fois les scènes 3d mises au point, il a fallu les intégrer dans l'éditeur SCS et les relier entre elles grâce à des liens entre les réflexes et les actions du module C3d2 et des modules environnant.
On peut voir ci-dessous une capture d’écran du projet Bürgermaquette avec l’éditeur SCS :
Et voici le fichier généré par l’éditeur qui contient les références aux différents modules ainsi qu’aux liens entre eux :
name \ \ \ \ \ BurgerMaquette port 1300 needed locked/lib/stdlib.pkg locked/lib/quicksort.pkg Dms/L/DMSclild04.pkg Dms/L/DMScli04.pkg Dms/L/preDMI04.pkg locked/lib/hand.bmp locked/lib/cross.bmp script _load\ "locked/lib/stdlib.pkg"\n_load\ "Dms/L/DMSclild04.pkg"\n_load\ "Dms/L/DMScli04.pkg"\nmain client Worlds/burgermaquette/burgermaquette.scc timeout 120 hiding 1 background1 13160664 grid1 13160664 gridw 40 flag 0 box _ 1 1 4 link enter .3d\ place pos_place _ _ _ link enter .Term\ v1.1 start _ _ _ link enter .ToCom\ v1.2 start _ _ _ link enter .Login\ v1.1 start _ _ _ mod Worlds/burgermaquette/contact.dmi 17 8 0 zoneS Button server.Zone\ 1 mod Worlds/burgermaquette/cap-vil.dmi 11 3 0 linkCS village.left 3d\ village pos_top _ _ _ linkCS capitale.left 3d\ place pos_place _ _ _ linkCS capitale.left SiteMap\ b1 destroy _ _ _ linkCS capitale.left SiteMap\ b2 destroy _ _ _ linkCS capitale.left SiteMap\ b3 destroy _ _ _ linkCS capitale.left SiteMap\ b4 destroy _ _ _ linkCS capitale.left SiteMap\ barre destroy _ _ _ zoneC bitmap client.cap-vil mod Worlds/burgermaquette/b2.dmi 16 1 0 linkCS click_3 SiteMap\ b2 destroy _ _ _ zoneC map client.boutons mod Worlds/burgermaquette/b1.dmi 15 1 0 linkCS click_3 SiteMap\ b1 destroy _ _ _ zoneC map client.boutons mod Worlds/burgermaquette/b3.dmi 17 1 0 linkCS click_3 SiteMap\ b3 destroy _ _ _ zoneC map client.boutons mod Worlds/burgermaquette/b4.dmi 18 1 0 linkCS click_3 SiteMap\ b4 destroy _ _ _ zoneC map client.boutons mod Worlds/burgermaquette/barremap.dmi 17 3 0 linkCS click_1 SiteMap\ b1 start _ _ _ linkCS click_2 SiteMap\ b2 start _ _ _ linkCS click_3 SiteMap\ b3 start _ _ _ linkCS click_4 SiteMap\ b4 start _ _ _ zoneC map client.barre\ menu\ et\ banner mod Worlds/burgermaquette/interieur1.dmi 2 7 0 link lnk_porte 3d\ place pos_sortie_porte1 _ _ _ link entering Banner\ Propositions start _ _ _ link lnk_trone Banner\ Propositions edit _ _ _ link entering Bitmap\ Cap-Vil !out _ _ _ linkCC select1 ToCom\ v1.2 ToComutron _ _ _ link out Banner\ Propositions destroy _ _ _ linkCS getAv av3d\ v1.0 getAv _ _ _ zoneC Info client.3d\ info zoneC View client.3d zoneC List client.3d\ list mod Worlds/burgermaquette/village.dmi 17 5 0 link entering Bitmap\ Cap-Vil capitale _ _ _ link entering SiteMap\ barre start _ _ _ linkSC entering av3d\ v1.0 hide _ _ _ zoneC View client.3d mod Worlds/burgermaquette/chess.dmi 9 9 0 mod Worlds/burgermaquette/scoltris.dmi 8 9 0 mod Worlds/burgermaquette/goban.dmi 7 9 0 mod Worlds/burgermaquette/interieur2.dmi 7 7 0 link lnk_porte 3d\ place pos_sorite_porte2 _ _ _ link entering Bitmap\ Cap-Vil !out _ _ _ link lnk_chess Chess\ v1.0 start _ _ _ link lnk_scoltris ScolTris start _ _ _ link lnk_goban Goban\ v1.0 start _ _ _ linkCC select1 ToCom\ v1.2 ToComutron _ _ _ linkCS getAv av3d\ v1.0 getAv _ _ _ zoneC Info client.3d\ info zoneC View client.3d zoneC List client.3d\ list mod Worlds/burgermaquette/term.dmi 1 1 0 linkCC command 3d\ place !speak _ _ _ zoneC Term client.term mod Worlds/burgermaquette/tocommutron.dmi 5 3 0 linkCC display Term\ v1.1 display _ _ _ mod Worlds/burgermaquette/move.dmi 10 5 0 link Move_avatar 3d\ place addObj.anch_1 _ _ _ link Move_avatar2 3d\ place addObj.anch_2 _ _ _ link Move_avatar3 3d\ place addObj.anch_3 _ _ _ mod Worlds/burgermaquette/login.dmi 12 9 0 link loginchanged 3d\ place !chglogin _ _ _ link loginchanged 3d\ casino !chglogin _ _ _ link loginchanged 3d\ vente !chglogin _ _ _ zoneC Button client.login\ button zoneC Text client.login mod Worlds/burgermaquette/bannerprops.dmi 2 9 0 zoneC Banner client.barre\ menu\ et\ banner mod Worlds/burgermaquette/place.dmi 9 3 0 link entering Bitmap\ Cap-Vil village _ _ _ link lnk_porte1 3d\ vente pos_int1 _ _ _ linkCS getObj Move getobj _ _ _ link lnk_porte2 3d\ casino pos_int2 _ _ _ linkCC select1 ToCom\ v1.2 ToComutron _ _ _ linkCC hear Term\ v1.1 display _ _ _ linkCC getFocus Term\ v1.1 getFocus _ _ _ linkCS getAv av3d\ v1.0 getAv _ _ _ link entering av3d\ v1.0 start&show _ _ _ zoneC Info client.3d\ info zoneC View client.3d zoneC List client.3d\ list mod Worlds/burgermaquette/av3d.dmi 11 5 0 link changed 3d\ place !chgav _ zoneC Button client.photo\ button endbox doc server 1 124 53 0 0 _ _ _ zone Zone\ 1 2 3 122 51 enddoc
Une fois arrivé à cet état d'avancement de la maquette, elle a été présentée à l'équipe qui a effectivement reconnu que la maquette était assez proche du game-design. Après leur avoir fait une présentation rapide de la maquette, il a été décidé de modifier la vue donnée à l'utilisateur dans la capitale : la maquette se servait en effet des modules existants qui n'autorisaient que la vue subjective à la hauteur des yeux de l'avatar, et l'équipe était unanime pour développer un module d'avatar qui permette d'avoir une vue extérieure, comme dans Tomb Raider ou dans Alone In The Dark.
L'idée de départ était simplement de modifier la position de la caméra pour la mettre quelques mètres derrière et au-dessus de l'avatar, pour avoir une vue légèrement plongeante, tout en gardant une bonne visibilité devant l'avatar. Cette modification était très simple et a été réalisée très rapidement en modifiant le temps d'un test les sources du module C3d2. Après une seconde présentation à l'équipe, il a été convenu que l'avatar était beaucoup trop fixe dans la vue de trois quarts ainsi obtenue. En effet, avec la solution de modifier uniquement la position et l'orientation de la caméra, l'avatar restait le père hiérarchique de la caméra et donc ne bougeait pas d'un iota lors de ces déplacements. Pour comparer avec un jeu existant, dans Tomb Raider l'avatar (Lara Croft) est suivi par une caméra active qui se recale en permanence selon les mouvements ordonnés par le joueur dans un angle de vue convenable. Il fallait donc tâcher de mettre au point une autre façon pour la caméra de suivre l'avatar.
Les façons de faire qui viennent immédiatement à l'esprit sont les suivantes :
- subordonner la caméra à l'avatar : on a vu que cela donnait un avatar qui reste fixe au centre du champ de la caméra,
- établir un modèle physiquement réaliste du mouvement de la caméra comme un corps massif avec une inertie, une vitesse et une accélération propre : on a estimé que cela prendrait trop de temps de calcul inutile sur chaque client et que cela pénaliserait les possesseurs de machines peu puissantes,
- établir un modèle physique approché ou simplifié du mouvement de la caméra.
C'est la troisième solution qui a été retenue pour le développement du module de l'avatar en vue extérieure : Avatar3d. En plus d'approcher le modèle physique du mouvement de la caméra, il fallait aussi que l'utilisateur puisse lui-même régler la position de caméra comme il le souhaitait. Il fallait donc intégrer un système de reconnaissance de commandes dans le module de communication, comme dans la norme d'IRC où les commandes commencent par le symbole "/". Pour notre application nous avons choisi le symbole "!" pour détecter une instruction donnée à la caméra :
- !link : ordonne à la caméra de se subordonner aux déplacements de l'avatar
- !unlink : ordonne à la caméra de se désolidariser des déplacements de l'avatar
- !move : ordonne à la caméra de suivre l'avatar dans ses mouvements
- !stop : ordonne à la caméra d'arrêter de suivre l'avatar
- !up : décale la caméra vers le haut pour avoir une vue plus plongeante
- !down : décale la caméra vers le bas pour avoir une vue plus horizontale
- !- : ordonne à la caméra de faire un zoom arrière
- !+ : ordonne à la caméra de faire un zoom avant
- !speed- : ordonne à la caméra de suivre les mouvements de l'avatar plus doucement
- !speed+ : ordonne à la caméra de suivre les mouvements de l'avatar plus vite
- !in : repositionne la caméra en vue subjective
- !out : repositionne la caméra en vue extérieure de trois quarts
- !cam: ouvre une petite fenêtre de debug qui comporte toutes les informations disponibles sur la caméra
Le suivi de la caméra est réalisé par la fonction suivante :
fun moveCamera(objb,i2)=
{
let M3getObjVec session shcam -> [xcam ycam zcam] in
let M3calcPosRef session dummyCam shell -> [[xdummyw ydummyw zdummyw] _] in
{
set xcam = xcam + (xdummyw - xcam) / av3dCamSpeed;
set ycam = ycam + (ydummyw - ycam) / av3dCamSpeed;
set zcam = zcam + (zdummyw - zcam) / av3dCamSpeed;
M3setObjVec session shcam [xcam ycam zcam];
let M3calcPosRef session dummyTarget shell -> [[xtargetw ytargetw ztargetw] _] in
M3setObjAng session shcam (M3angularTarget (M3getObjVec session shcam) [xtargetw ytargetw
ztargetw]);
0
}
};;
La fonction registerTri charge l'objet 3d avatar, ainsi que les matériaux associés. Puis elle enregistre la classe "default".
La fonction newTri initialise un avatar. Le traitement est différent selon qu'il s'agit de l'avatar de l'utilisateur de la machine ou de l'avatar d'un autre utilisateur, notamment parce que ce système est prévu pour une vue subjective. Cette différence est gérée par le test :
if o==owner then ... else ...
Dans le cas de l'avatar utilisateur, une structure un peu surprenante est créée :
Dans le cas d'un avatar autre, la structure est plus simple :
Une autre possibilité offerte par le module AvatarPhoto a été reprise dans ce module : le fait de pouvoir personnaliser la texture du visage de l'avatar pour pouvoir mettre sa propre photo dessus. Evidemment, cette particularité devra être limitée dans la version finale du module puisqu'un problème immédiat se poserait lors d'une partie on-line : en entrant dans une grande place pleine d'avatars, il faudrait télécharger les textures de chacun, ce qui ralentirait considérablement tout le monde. Il sera donc toujours possible pour le joueur de choisir l'apparence de son avatar, mais seulement dans une petite sélection de masques prévus et distribués avec le jeu, sans possibilité de le modifier soi-même.
Il est à noter qu'avec la façon choisie de désolidariser la position de la caméra et l'avatar pose un problème lors de la gestion des collisions. En effet, les collisions sont testées sur l'objet 3d de l'avatar avec pour principe que la caméra occupe la même position que l'avatar. Dans notre module, ce n'est plus le cas et la gestion des collisions empêche bien sûr toujours l'avatar de pénétrer les murs, mais la caméra n'a pas ce contrôle de position et il arrive relativement souvent que la caméra se positionne derrière un mur. C'est une fonctionnalité qu'il faudra bien sûr implémenter dans la version finale du module qui ne sera développé qu'en phase de production, c'est à dire après la fin de mon stage. En effet, le problème n'est pas simple et implique des tests pour trouver des plus courts chemins dans la scène 3d sans toucher les boîtes de collision.
Interprétation et critique des résultats
La maquette dans son état actuel de finition ressemble effectivement beaucoup au projet tel qu'il est décrit sur le papier, mis à part la forme de l'interface. L'ambiance générale est plutôt bien rendue, on sent bien la philosophie du jeu on-line. La partie on-line du jeu dans Venise est un peu plus aboutie que la partie gestion du village (cf. annexes : extraits du game-design de Bürgermeister) qui n'était pas définie précisément lors du développement de la maquette.
La réalisation de cette maquette a eu pour utilité principale de mettre au grand jour les problèmes sur lesquels allait tomber l'équipe de programmation. Elle a permit aussi de voir tous les modules qui étaient réutilisables, que ce soit entièrement ou en partie, et ce qu'il fallait leur ajouter pour les intégrer au jeu. C'est aussi grâce à ce travail que le planning de développement a été établi : une suite d'étapes (ou milestones) avec pour chacune un temps, un coût et une difficulté de développement associés.
Pour ce qui est de la présentation au comité de direction, de la décision du lancement de la production et de la présentation aux joueurs, elles auront lieu au cours du premier trimestre 1999. D'ici là, je continuerai le travail de pré-production sur Bürgermeister avec un contrat d'auteur chez Cryo Networks.