Leur 3ème journée au GameJam de Portsmouth

Mardi 11 juin : Jour 3

Ce deuxième jour de concours commença par la prise en main pour certains et la « reprise » en main pour d’autres du moteur de jeu que nous avions utilisé pour notre précédent jeu : Unity3D. Autour de nous, développeurs, graphistes et autres chevaux (cf. photo ci-dessous) s’afféraient allègrement à la tâche, dans une ambiance à la fois studieuse et bon enfant, toujours ponctué d’un humour bien britannique.

game jam portsmouth 2

Pour en revenir à notre travail, le choix de Unity3D s’est fait selon différents critères : en effet, il s’agit d’un moteur à la fois graphique et physique, proposant un environnement de développement très facile à prendre en main, le tout accompagné d’une documentation et d’une communauté en ligne tout à fait prolifique. Tous ces arguments (ainsi que la possibilité de développer sur une version gratuite) correspondent à notre besoin : nous n’avons que peu de temps, certains membres de l’équipe n’ont pas eu l’occasion d’utiliser ce genre d’outils, nous ne sommes pas graphistes (et l’interface graphique de Unity permet de faire beaucoup de choses sans trop connaître ce domaine), bref ! Le seul inconvénient de ce moteur de jeu est sa relative gourmandise en ressource, mais dans notre cas, à savoir dans le cas d’un jeu de toute petite ampleur, ce facteur n’est pas décisif.  D’ailleurs, nous avons pu observer qu’une grande partie des équipes concurrentes travaillaient sur cet outil.

Mais, comme dans toute confrontation, il peut y avoir des dommages collatéraux : pour réaliser un jeu vidéo digne d’intérêt, il faut lui conférer une partie visuelle agréable. Nous nous sommes donc rendus à l’évidence que l’un d’entre nous « allait y passer », et Jean-Bertrand, Matthieu, Thomas et moi avons désigné le volontaire de l’équipe : Jean.

Pour les intéressés, Jean utilise le logiciel 3ds Max, et grâce à cela, il a pu travailler de concert avec Matthieu sur un premier élément du jeu : l’environnement. Concrètement, le jeu se déroule dans une sorte de mine, au sein de laquelle notre personnage-joueur avance dans un chariot.

Il s’agit donc d’un gameplay de type « couloir », par opposition au « bac à sable » : il ne s’agit pas d’un environnement ouvert où plusieurs choses se passent simultanément et dans lequel le joueur peut se déplacer librement. Ce choix, tout à fait partial, nous a permis de réfléchir à un élément intéressant pour un jeu : la génération automatique et aléatoire du décor.

Cet aspect peut paraître banal, mais une telle gestion de l’environnement nous permet d’assurer une durée de vie minimale à notre jeu ainsi qu’une densité de jeu suffisante : nous créons des portions de couloirs, que nous pouvons agencer de différentes façons ; ainsi, elles peuvent se répéter plusieurs fois, sans que le joueur s’en rende forcément compte en raison de l’enchaînement différent entre elles, et nous avons un couloir plus long. De plus, nous savons exactement ce que va voir le joueur vu qu’il n’a pas le choix, et de fait, nous pouvons nous assurer qu’il ne s’ennuiera pas.

En comparaison, le recours à un environnement ouvert peut être dangereux : la création d’un environnement ouvert demande beaucoup de temps, car il faut penser à l’équilibre global, de façon à ce que le joueur ne se retrouve jamais sans rien à faire, ou qu’il n’atteigne pas le bout trop vite en prenant des raccourcis imprévus.

Pour résumer, la décision d’offrir un jeu de type couloir limite un certain nombre de risques dans notre projet, tout en nous offrant des possibilités techniques intéressantes.

De son côté, le duo de choc Jean-Bertrand et Thomas s’est afféré à un autre aspect important de notre jeu : les QTE, ou Quick Time Events. Il s’agit d’évènements qui surviennent à des moments d’un jeu, et qui nécessitent de réagir rapidement pour enclencher ou déclencher une réaction. Les QTE sont généralement des évènements simples, comme « appuyez rapidement sur la touche A », et permettent d’apporter de la variété au jeu.

 Devinez qui s’est donc retrouvé avec le travail consistant à réaliser les différents éléments contextuels (et textuels) du jeu ? Non, pas l’homme à tête de cheval, mais bien moi, et même si je le présente de façon ingrate, il s’agit d’une partie intéressante du travail. En effet, que ce soit le menu d’accueil du jeu (qui permet de consulter l’histoire, l’explication de la jouabilité, etc.) ou le HUD (Affichage Tête-Haute en Français, partie qui regroupe les différents éléments contextuels comme le score, la santé, le temps, pendant une partie), ces éléments sont importants pour deux aspects : la compréhension et l’immersion.

Je vous présenterai demain nos travaux sur tous ces points !

Rémi CARLES

Advertisements

À propos de Marie-Amelie

Exia Cesi Bordeaux - matrias@cesi.fr // 05 56 95 50 65

Publié le juin 12, 2013, dans Actualités, Game Jam 2013, GameJam 2012. Bookmarquez ce permalien. Poster un commentaire.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :