EPITECH - Brice (responsable Physique):

Pour ma part ma premiere parti dans le projet a été sur de la recherche et des tests sur les differents moteurs physique disponible sur le net. Cette premiere partie a été assez laborieuse et peu pratique etant donné que j'etait tout neuf dans le domaine. Une fois le moteur choisie il a fallut apprendre a l'utiliser et reflechir qu'elles etaient les techniques à utiliser. Cette partie fut aussi complexe comme on peut le rensentir en conduisant la moto. Il est vrai que pendant cette partie, il a été dur de ce motiver mais bon rien que pour le bonheur de rentrer dans une signalisation de direction avec une moto ca valait le coup . La collaboration avec Creapole nous a vraiment tous remotivé pour le jeux et elle nous a soutenu jusqu'a la fin de notre projet. De plus une tres bonne entente c'est effectué entre les eleves de creapole les plus motivés , la teamBR et surtout le professeur d'animation de creapole qui à mener la partie graphique d'une main de maitre. Pour conclure, meme si on a tous faillit s'entretuer plusieurs fois durant ce projet  (vu la difficulte de ce projet pour des personnes debutante dans le milieux du jeux PC) celui ci a été une superbe aventure dont je suis fiere et que je ne regrete en rien.

ps : il faudra notifier en debut d'article que l'on ce connait tous depuis 5 ans et que l'on a bcq bosser ensemble je pense que ca a son importance.

EPITECH - Yann (Responsable technique, responsable réseau)

Style interview (desoler mais c'est trop marrant): -

Comment avez-vous l'idee geniale de remettre au gout du jour le gameplay de road rash? On fait partie de cette generation qui s'est eclatee a jouer sur des concepts tout simple comme le fait de filer un bon coup de batte de baseball a une moto qu'on depasse dans un virage (rire). Plus serieusement on s'est dit que les possibilites reseau pouvaient vraiment resusciter le concept. Il y avait un vrai potentiel que ce soit pour l'ancienne generation de joueurs qui ont connus road rash comme pour les plus jeunes pour lesquels ce genre etait inexistant.

- Quel a ete ton travaille dans ce projet ?

Sur le projet Overdrive je me suis d'abord occupe de la partie reseau et j'ai ensuite travaille sur le moteur de jeu, qui est tres lie au reseau, et aussi sur le gameplay.

- Tout a l'heure tu m'a dit que l'arrivee des etudiants de creapole dans le projet avait completement boulverse votre organisation interne, est-ce que tu peux m'en dire un peu plus?

Non plutot mourir (rire). Il y avait un gros travail de suivi et d'echange avec Creapole dont notre chef de projet a herite et qui a represente un surcroit de travail trop important. Il fallait que l'on fasse quelque chose rapidement, on a recentre le chef de projet au suivi de Creapole et des intervenants exterieurs d'une maniere generale. J'ai herite de l'organisation technique du projet et notre responsable qualite est egalement devenu responsable du planning. Ce partenariat a vraiment remonte le moral de l'equipe qui etait alors un peu en baisse. Lorsque l'on a presente le jeu on a eu un tres bon retour des etudiants qui etaient tres interresses par le projet. On avait maintenant la possiblite d'avoir des graphismes de qualite ce qui nous a permi de nous recentrer sur le jeu. Mais cela s'est aussi accompagne d'une pression supplementaire a savoir qu'il fallait que l'on soit a la hauteur encore plus qu'avant (rire).

Detail sur mon travail: Au debut j'ai fais des tests afin d'arreter une solution technique. Le developpement a commence avec une premiere librairie qui s'est relevee inadaptee au bout d'un certain temps car boguee et trop difficile d'utilisation. Une autre librairie open source tres orientee jeu a ete choisi et il a donc fallu porter la partie qui avait deja ete developpee vers cette nouvelle librairie. Un des aspects techniques les plus difficiles a ete le reglage de l'interpolation de la position des joueurs qui est assez problematique dans un jeu de moto ou les modeles se deplacent tres rapidement. Un soin particulier a egalement ete apporte a l'optimisation des paquets afin de limiter la bande passante utilisee par le jeu au maximum.

EPITECH - Rodolphe SCHILLING - Membre de l'équipe de départ sur Overdrive

mon travail c'est divisé en 3 étapes. La premiere a commencé tout d'abord par une ébauche du réseau avec une librairie résau en essayant de mettre en place une archi client/serveur qui puisse être utilisée pour les tests.

La deuxième étape fût la rélexion sur le gameplay en terme de classe avec l'aide de Gueorgui notre chef de projet, il fallait trouver un système qui réponde à nos exigences en terme de gameplay tout en tenant compte des limites de programmation.

La dernière étape était la mise en place de cette architecture au niveau graphique en intégrant le système de scène manager (2D pour les menus/ 3D pour le jeu)

Ce que je retiens de ce projet : Une expérience humaine inoubliable aussi bien grâce au partenariat de Créapole que par tous les autres intervenants comme les musiciens. En espérant qu'en lisant nos avis, vous aurez l'envie de jouer à notre jeu et de participer à cette aventure qui fût la notre.

EPITECH - Loïc (Interface 2D)

Ma contribution sur le projet Overdrive se place au niveau de l'interface 2D, c'est à dire l'élaboration des menus du jeu et affichage des informations durant la partie.

Au début du projet il a fallu apprendre à utiliser les fonctionnalités 2D du moteur graphique (ogre3D). Ensuite en accord avec le reste du groupe nous avons fait la maquette des différents écrans des menus (mise en place des différents éléments des menus). Au fil des mois, nous nous sommes apperçu que les performances 2D d'ogre étaient limitées (pas beaucoup "d'objets" pour agrémenter les menus), ce qui rendait le développement laborieux.

Nous avons donc laisser tomber le développement des menus avec l'interface d'ogre et nous avons opté pour l'utilisation d'une librairie suppplementaire (compatible avec le moteur graphique): CEGUI.

Cette librairie nous a sauver la vie. Elle nous a permis de repenser entièrement le développement des menus car plus performante.

S'en est suivi d'une phase d'apprentissage de CEGUI, puis d'un long développement. Le plus difficile dans l'élaboration des menus était de placer correctement les différents éléments (beaucoup de "tatonnage").

EPITECH - Benoit (Responsable qualité et son)

Ce qu'il est important de dire je pense.

Beaucoup de programmeurs se lance dans la realisation de jeux video, mais le plus souvent ils negligent trop les graphismes et donc leurs jeux aussi bien realise techniquement n'obtiens pas le succes escompte et l'interet du public. Nous ne voulions pas faire cette erreur et etre un de ses jeu de plus qui s'arrete par manque de moyens ou d'ambition, c'est pourquoi nous avons fait appel a une ecole graphistes. Cela a egalement permi d'ouvrir d'autres perspectives, partager des points de vue, travailler de maniere plus professionnel.

Mon impression personnel :

Un jeu c'est une masse de travail considerable, et beaucoup abandonne en plein milieu par peur devant cette masse de travail qui se dessine devant leur yeux au fur et a mesure de la definition du jeu. Un jeu necessite de regler et d'anticiper un nombre considerable de detail, il est donc primordial de s'organiser, de documenter, d'avoir une demarche qualite pour pouvoir reussir a gerer les choses. Un jeu c'est aussi quelque chose que l'ont voit se construire et evoluer, une sorte d'oeuvre d'art en perpetuelle amelioration, une quete pour trouver la personne qui va pouvoir realiser au mieux chaque detail, et c'est beaucoup de satisfaction lorsque l'on a trouve un element qui colle bien au jeu, dans une telle perspective, la programmation est bien plus passionante que pour un logiciel classique. Le plus gratifiant c'est lorsque les gens a qui l'on demande de participer au projet rentre a fond dans l'univers du jeu, apporte leurs idees et leurs touche personnel et dans le cas d'overdrive, que ce soit les graphistes ou les musiciens, ils sont tous rentre completement dans l'univers de jeu imaginer au depart et l'ont fait vivre.

EPITECH - Gueorgui (Chef de projet, responsable moteur 3D)

J'ai travaillé sur le moteur graphique du jeu, ainsi que sur la communication entre les équipes de développement et de graphisme.

LE MOTEUR GRAPHIQUE:

OGRE 3D Pour ce qui est du moteur graphique, notre choix s'est assez rapidement arrêté sur Ogre3D en raison de ses performances, de la bonne documentation disponible et surtout d'une communauté très impliquée autour du moteur, qui a répondu à beaucoup de nos questions au cours du développement du jeu.

Nous avons eu pas mal de difficultés avec le moteur 3D. En premier lieu, n'ayant pas vraiment fait de 3D de manière sérieuse avant ce projet, j'ai eu du mal avec les concepts et les techniques qui s'y rapportent. J'ai également passé pas mal de temps à lire et à essayer de comprendre le fonctionnement interne d'Ogre3D, et à débattre avec les membres de la communauté de celui-ci pour trouver une bonne solution aux problèmes qui se posaient.

Un de nos grands soucis était la performance de l'affichage. Nous avons adopté plusieurs solutions qui se sont révélées assez efficaces, mais pas toujours suffisamment pour faire tourner le jeu sur des machines "moyennes". Nous avons, entre autre, utilisé l'algorithme octree pour subdiviser les cartes de jeu et ainsi accélérer l'affichage de celles-ci; utilisé des textures au format DDS (qui est un format natif aux cartes graphiques, et ne doit donc pas être converti pendant l'exécution du jeu, contrairement à des formats comme le JPEG ou le PNG) et finalement essayé de limiter le nombre de polygones à l'écran (pas toujours évident avec des graphistes qui se lachent :) )

Un autre problème était d'exporter les données depuis notre outil de création (3D Studio MAX) vers Ogre3D. Les exporteurs existants n'avaient pas toutes les fonctionnalités dont nous avions besoin, nous avons donc du développer notre propre exporteur à partir d'un squelette open-source. Cet outil nous permettait d'exporter les cartes de jeu avec divers "objets cachés", qui indiquaient au jeu l'emplacement d'éléments interactifs, tels que la ligne de départ, les checkpoints, des objets avec lesquels le joueur peut interagir, les sources sonores...

L'exportation des animations (des motos et des personnages) a également posé problème: l'outil qui permettait de le faire avait continuellement des problèmes, et nous n'avons pu intégrer les animations correctement qu'avec une version de l'outil qui est sortie 2 mois avant la fin du projet!

LA COMMUNICATION INTERECOLES

La communication entre les équipes de Creapole et la TeamBR d'EPITECH ne s'est bien entendu pas faite sans difficultés :) Nous avions une relation quasi-fusionelle avec Jean-Philippe Saintherand, le professeur d'animation de Creapole qui a pris en charge le projet dans cette école, mais à part ça nous n'avions presque pas de communication directe avec les étudiants de Creapole qui travaillaient sur Overdrive.

Nous avons bien entendu fait des présentations de l'avancement du jeu à Creapole à plusieurs reprises, présentations qui ont eu plus ou moins de succès , mais notre interlocuteur principal était toujours M. Saintherand, qui dirigeait les élèves de son côté.

Ainsi, l'aspect graphique final du jeu correspond sans doute plus à la vision de M. Saintherand et de ses élèves qu'à la notre, mais c'est certainement mieux ainsi: chacun sa spécialité! D'autant plus que le résultat est réellement impressionnant.

AU FINAL...

Il faut certainement préciser qu'Overdrive comporte toujours des bugs (le développement était mené de manière assez fiévreuse les quelques semaines avant la soutenance), et la performance n'est pas toujours au top. Cependant, nous restons très fiers du travail accompli, et surtout du résultat. Notre collaboration avec Creapole est sans aucun doute à l'origine du succès de notre jeu (dont la note finale par les responsable de projet est de 20/20). Ce contact a permis de remotiver l'équipe de développement, et nous a mis le petit coup de pression nécessaire pour mener le projet à bout.

CREAPOLE - Jean Philippe SAINTHERAND - Professeur d'Animation 3D

Pour moi ce jeu a vraiment démarré après la phase de test de juillet 2004. Nous avions réalisé 2 maps et les résultats me laissaient entrevoir les ressources que nous pourrions utiliser.

Les contraintes du jeu

La TeamBR avait opté pour des choix techniques visant à l'économie. Le but étant de développer un jeu qui pourrait tourner sur des configues moyennes de PC. Vers la fin du projet, le travail d'optimisation qu'avait réaliser la TeamBR avait fait évoluer nos contraintes de manière considérable. De là allait dépendre nos capacités à coller à l'univers du jeu.

La phase de conception

Le scénario qu'avait élaboré la TeamBR décrivait un univers à mi-chemin entre AKIRA, MADMAX, JUGDREED. et NEW-YORK 1997;

L'idée fut de renforcer les concepts déjà présents dans le scénario et donner une identité graphique pour chaque Gang. Les élèves firent des recherches afin de constituer des dossiers de character design. La phase de conception malheureusement ne dura que 2 semaines. L'univers du jeu se déroulant dans Paris, cela nous laissa une chance unique de travailler sur des ambiances encore relativement inédites. La seconde idée fut d'intégrer des éléments caractéristiques symbolisant Paris pour chaque maps de gang . (Ex : Pigalle, la tour Eiffel, les catacombes parisiennes. La Défense et le quartier Chinois du 13 ème ).

Je remercie La TeamBR qui a toujours été ouverte aux nouvelles idées proposées et qui a su les accepter sans montrer aucun sentiment de propriété. Leur scénario était riche d'ambiances multiples. C'est cette richesse qui m'a poussé à m'investir personnellement sur ce projet.

La phase de production

Au final quatre ambiances avaient été définies. Une dizaine de maps était prévue et nous avions une cinquantaine d'élèves engagés sur le projet. Nous disposions de 4 à 6 mois pour réaliser l'ensemble du travail. Mais suite à des complications internes le Projet OVERDRIVE ne pu être intégré dans le cursus principal de CREAPOLE. Ce changement divisa de moitié la quantité de nos élèves et réduit de même nos capacités de production. Dés ce moment nous dûmes réduire nos ambitions à la réalisation de 2 maps principales.

Organisation du temps

Au départ le suivi du projet se faisait en cours, 1h30 par semaine. Ce qui est vite devenu impossible car la complexité du projet nécessitait un suivi quasi quotidien. J'ai du investir sur mon temps personnel. Ce qui a peut -être représenté 20 à 30 heures supplémentaires en plus de mon programme de cours.

Organisation du travail

Je mis en place un système de feuille production et regroupa les élèves en équipe dirigée par des délégués. Je dictais les taches sur MSN Méssager aux différents élèves le cas échéant en leur distribuant les ressources nécessaires. Les délégués recevaient les instructions qu'ils faisaient suivre à leurs équipes. Leurs rôles étaient aussi de me présenter la production hebdomadaire de leurs équipes. Je me chargeais du contrôle qualité et vérifiait la mise à jour des feuilles de suivi. Ce système quoi que viable se révéla trop lourd et trop rigide face aux besoins d'adaptation constante que nous imposaient le développement du jeu.

Le niveau des élèves

Ayant autorisé les classes de 2ème année à participer au projet. Je me suis retrouvé avec des élèves de niveau complètement différent, certains avaient déjà une expérience approfondie des méthodes de conception pour le jeu vidéo et d'autres n'avaient quasiment jamais touché un ordinateur. Ce problème entraîna vite des difficultés sur la distribution des tâches et vit réduire le nombre d'élèves au fur et à mesure de l'avancement. Se constituait en même temps un noyau solide qui allait au final répondre à la plupart des besoins. Encore une fois le temps nous avait manqué pour faire une évaluation générale et mettre à niveau tout le monde sur les techniques à utiliser pour le jeu.

LA communication avec Epitech

Le travail s'organisait autour de réunions hebdomadaires avec la TeamBR et le contact quasi journalier avec Georkie sur MSN Messager. Il était parfois comique de constater les problèmes d'interprétation qu'il pouvait y avoir entre un codeur et un infographiste, surtout en face des bugs du Moteur Ogre, comment positionner une moto sur X devenait une question épineuse. Et comment les exigences en apparence les plus simples se révélaient les plus compliquées.

La TeamBR m'avait proposé d'organiser des réunions avec les élèves pour gérer le suivi de la production en parallèle. J'ai préféré éviter cette solution car je craignais une certaine dispersion voir une confusion dans la transmission des informations. La plupart des élèves étant novice sur les concepts même de la 3D. Cela aurait pris un certain temps avant de développer un langage commun entre les programmeurs et les infographistes. J'ai préféré éviter cette solution et prendre en charge moi-même la distribution des consignes. Et cela n'a pas été sans entraîner tout un tas de complication. Je me rappelle de session Msn avec + de 1O élèves connectés en même temps à en devenir fou.

Cette solution n'était plus vraiment nécessaire vers la fin du projet car le nombre d'élèves était plus réduit, et ils possédaient tous une meilleure maîtrise de leurs outils 3D.

Ce projet fut un véritable épreuve vu le nombre de situations chaotiques qui s'est présenté. Mais cela a été une chance unique pour moi de suivre le développement d'un jeu en touchant de près à toutes les étapes de sa réalisation. Cela a représenté aussi une belle expérience humaine très enrichissante.

Je tiens tout spécialement à remercier

Georckye TCHERNINCHENKO : Grand maître d'oeuvre du Porjet OVERDRIVE. Nos 2 visions ne se sont jamais opposées, nous partagions les mêmes qualités obsessionnelles, fixant un niveau de qualités bien précis sur le résultat à obtenir. Contribuant à motiver nos équipes chacun de notre côté.

Brice NANOUM ainsi que toute la TeamBR : Avec qui j'ai toujours eu une entente agréable, malgré le fait qu'il m'ait fait recommencer une cinquantaine de fois la mëme motos.

Nathalie Foussier  : qui fut sans doute la personne la plus motivée sur ce projet et qui a fourni le travail le plus régulier du début à la fin. Tout ça dans un apprentissage constant de 3DSMAX. On lui doit nombre de belles textures sur la maps des REDDRAGONS. Chapeau !!!

Fréréric KAISERBLUETH : qui vint apporter la note supérieure en qualité de beaucoup d'éléments de scène, notamment sur les véhicules et sur quelques façades d'immeubles. Armes de persos etc. Il fut sans doute l'élève le plus polyvalent (texture, modeling) fonctionnant de manière autonome et travaillant sur plusieurs maps en même temps. Il était toujours relativement aisé de lui faire confiance quand à la qualité des résultats.

Damien DONOT et Benois FERRIER : Mes principaux lieutenants depuis le début du jeu. Organisés en binôme, ce sont eux qui ont réalisé la plus grande somme de travail : des maps de test jusqu'à l'imposante maps des REDDRAGONS. il ont su sacrifier de leurs temps sur le cursus général de Creapole pour faire avancer le projet. Sans eux le jeu n'aurait sans doute jamais vu le jour.

Jean Edouard FAGE : . Il réalisa quasiment à lui seul la map des RIPPERS. Il était le senior du groupe pas tant par son âge mais par son niveau compétences dans le jeu vidéo même s'il délaissa le projet sur la fin pour travailler sur des maps d'HALFLIFE2 (on peut le comprendre)

Je remercie également Jean Remi TESSIER, Cédric JANNOT, Grégoire DURAND DE GEVIGNEY, Cyril BEAUFORT et bien d'autres, qui ont tous apporté des éléments majeurs à OVERDRIVE. Mais qui à mon grand regret, on été un peu isolés faute de pouvoir leur consacrer plus de temps.

CREAPOLE - Nathalie FOUSSIER - Etudiante en 2 éme années JVA

J'ais travailler sur la texture, modeling, principalement sur la map des REDDRAGONS.

Un jeu qui m'a appris énormément en 3D, unité graphique , expérience proche de la réalité de production. Un partenariat extra avec la TeamBR qui a régulièrement organisé des réunions autour d'Overdrive et qui a beaucoup dialogué avec nous. Un professeur super qui a réussi a manager le projet jusqu'à sa finalité.

Nous étions quelques élèves sur ce projet, nous avons beaucoup travailler ensemble et nous y avons appris beaucoup de chose. Il régnait une ambiance grisante, surtout dans la dernière ligne droite où nous devions produire beaucoup, vite et bien. J'ai vraiment aprécier de pouvoir en apprendre un peu plus sur le fonctionnement et la réalisation d'un jeu , sa programmation, ses contraintes et son organisation. Et d'apprendre la 3D de manière plus ludique avec un projet très intéressant et avec un objectif concret ! Je suis aujourd'hui épaté par ce petit jeu né d'un travail d'équipe, de grandes motivations, et de challenges !

À quand le prochain jeu ?

CREAPOLE - Frederic KAISER BLUETH - Etudiant en 2 éme années JVA

Idem textures, modeling. J'ai travaillé sur la plupart des Maps du jeu et est également réalisé pas mal de véhicules, objets et éléments de scènes principales.

Lorsque qu'en début d'année, tandis que je n'avais que de très vagues notions de 3d, on nous a proposé de participer au projet Overdrive, en collaboration avec la TEAM BR d'EPITECH et les 3ème annéers du département jeu video animation de l'école, j'ai sauté sur l'opportunité.

Enfin, quand je vois Overdrive aujourd'hui, avec un niveau en 3d tout de même plus confirmé,je trouve le résultat plutôt satisfaisant lorsque l'on considère
notre niveau et le temps de développement dédié à ce projet.
Je concluerai en disant qu'Overdrive à été une première expérience très riche, aussi bien sur le plan professionnelle que sur le plan humain...

CREAPOLE - Jean Remi TESSIER - Etudiant 2 éme années JVA

J'ai travaillé sur beaucoup de piéces principales d'immeubles qu'il fallait réaliser dans un style chinois, traditionnelle et moderne.

Overdrive fut pour moi une expérience très enrichissante. C'était en effet le moyen pour moi d'approcher pour la première fois les conditions de création d'un jeu vidéo. Mon travail sur ce projet fut essentiellement la création de texture et de bâtiments et en particulier sur la map des Red Dragons.

Le plus intéressant et excitant était certainement le challenge des contraintes. Essayer de faire un minimum de poly par objet étant donné la masse d'objet présent sur une carte relativement grande était sans doute le plus grand des challenges. Cela oblige ainsi à modéliser des maillages les plus propres possibles. Ceci représente en soit un très bon exercice de modélisation.

Un autre point vraiment intéressant était de découvrir les diverses astuces utilisées pour contrer certains problèmes liés au jeux vidéo pour optimiser la scène global.

En finalité ce projet m'a appris énormément et m'a donné envi de renouveler ce type d'expérience à l'avenir.

CREAPOLE - Benoit FERRIER - 3eme année JVA

Coréalisateur de la map Red Dragons,

 La tâche consistait essentiellement à définir et modéliser le circuit de la map des REDDRAGONS, et composer les différents quartiers. Après avoir modélisé et texturé une version alpha qui s'est vite relevée inexploitable, partiellement en raison de ses dimensions, les prétentions ont dû être revues à la baisse, mais la version définitive a gardé un certain gigantisme, qui reste encore pour moi le plus gros challenge de cette entreprise...

 La principale difficulté était d'assimiler les contraintes flottantes d'un moteur graphique en rodage permanent, et la synergie constante avec la Team BR par le biais de J.P. SAINTHERAND s'y est révélée capitale, du moins j'ai peur d'imaginer ce qu'on aurait engendré d'un travail en mode furtif...

L'autre difficulté a été de coordonner nos propres effectifs, avec la désertion progressive de nos troupes avec par moments des retombées néfastes sur notre propre motivation... Mais l'arrivée des élèves de deuxiéme année en renfort a remis la production sur les rails, et le travail a globalement porté ses fruits...

 Conclusion : malgré un travail en dents de scie avec des rushes de productivité, cette affaire s'est montrée très enrichissante pour tous ceux qui comme moi n'étaient pas rompus aux processes du jeu vidéos...Et je pense parler pour tous les créapoliens..

 Compliments à la Team BR et bonne continuation..

CREAPOLE - Damien DONOT - Etudiant en 3 éme années JVA

Modeling, texture, Demo de Test, Map REDDRAGONS

Ma collaboration au projet Overdrive s'est faite en deux étapes. Tout d'abords nous avions en charge de modéliser une carte de démo afin de déterminer les différents formats et tailles qui allais être utilisés. Ce travail laborieux s'est fait avec une équipe restreinte de 3, 4 personnes. Une fois les tests fait, nous avions donc les contraintes techniques du jeu qui étaient établies.

Dans un deuxième temps, nous avons du réaliser une carte pour le jeu : le circuit du Gang des Red Dragon. Nous avons cette fois été aidé par des deuxième année qui modélisaient des façades et différents objets. J'avais en charge la moitié de cette carte. Le gros du travail consistait à mettre en place les routes et de modeliser tout le quartier, puis de placer les immeubles. Nous avons modéliser pour 200 000 polygones de buildings, route, périphérique, quartier traditionnel chinois, jardin publique, etc..

Cette aventure à été très enrichissante sur tout les point de vue. J'ai pus constater les nombreuse contraintes du au moteur graphique et au jeu en général. Une partie difficile a consisté à motiver les personnes (l'équipe se réduisant au fur et à mesure), le travail en équipe demandant une certaine implication personnelle. Cette expérience m'a fais évoluer dans ma conception de la création d'un jeu de manière positive. La teamBR étant satisfaite de notre travail cela fait vraiment plaisir.

L'Absent