Little God Story : DevBlog #1

La génèse du projet

Avant de démarrer cette série d’article sur mon projet actuel, Little God Story, je tiens à préciser deux/trois choses afin qu’il n’y ait pas d’ambiguïté sur mes intentions. Ce devblog n’a pas pour but premier de faire la promotion de mon jeu, mais d’expliquer ce qui a guidé certains choix de game-design. Un jeu est une entité qui part d’un point de départ, avec certains objectifs, mais cela reste très changeant. Je vais ici parler de choix de game-design déjà effectués et validés par des tests extérieurs. Dernière chose : le début de ces articles démarre exactement là où mon post-mortem d’Unreal Safari se terminait. Je vous conseille la lecture de ce dernier pour bien comprendre les choix suivants.

Exil

Après une expérience en solitaire de près d’un an et demi sur Unreal Safari, j’arrivais au bout de ma motivation. Cherchant à intégrer une équipe pour un mod/jeu solo, je profitais du fait qu’Exil migre sur l’UDK pour postuler. Embauché en tant que mappeur, je me faisais plaisir en modélisant un monde médiéval sombre aux ombres tranchées. Cependant, Exil ne mit pas très longtemps à capoter. Je pense qu’il est important que je précise un petit peu ce qu’est réellement ce jeu.

Exil est un jeu en vue à la troisième personne. Au moment où j’intègre l’équipe, Exil est une sorte de clone de Prince of Persia (tendance les Sables du Temps). Si le monde diffère légèrement (plus médiéval qu’oriental) même le roi, Enklave, ressemble à s’y méprendre au prince de perse. Dans le cahier des charges, seul la notion de cristaux diffère du jeu original.

Lorsque j’ai commencé à mapper, le but était de rechercher une ambiance dans le but d’attirer le codeur (comme pour beaucoup d’équipe). Malheureusement, j’ai vite souffert du manque de programmation dans l’équipe. Sans un embryon de gameplay, difficile de faire quoi que ce soit. Mes premières demandes furent pour des choses bêtes : à quelle hauteur peut sauter Enklave ? Sur quelle longueur ? A quelle vitesse va-t-il ? Rapidement, je me suis lassé de mapper « pour mapper » et non pas pour du gameplay. Je n’ai jamais été intéressé par le mapping pur, j’ai toujours aimé le côté level-design qui est pensé avant tout par rapport à un joueur.

Nous avons alors eu une discussion avec Froyok, chef de projet, afin de définir précisément le gameplay d’Exil et d’essayer de le différencier un peu de Prince of Persia. L’idée était d’opposer cristaux et eau. J’avais alors comme idée que le personnage pourrait se transformer en cristaux et accroître ses performances (hauteur de saut, vitesse…). Le problème c’est que dans ce mode, il serait vulnérable à l’eau. Je voyais alors un gameplay où Enklave se transformerait en cristaux pour sauter plus loin mais devrait, en vol, redevenir normal pour traverser le filet d’eau qui le sépare de la plateforme suivante…

Cette idée n’a pas été retenue pour le gameplay d’Exil, mais j’ai senti qu’il y avait quelque chose à creuser. En attendant d’avoir un prototype de gameplay pour mapper pour Exil, j’ai travaillé ce concept en l’étendant aux quatre éléments. Plutôt que de n’avoir qu’une combinaison cristaux/eau, je multipliais les possibilités de gameplay avec terre/air/eau/feu. Pour traverser du Feu, il faut être en Eau. Mais pour sauter haut, il faut être en Air, etc. Rapidement, j’ai pu développer pas mal de combinaisons possibles. C’est pour cela qu’au départ, Little God Story est un jeu avant tout de plateforme en vue à la troisième personne. Au final, le concept évoluera beaucoup. Mais contrairement à Unreal Safari, j’ai pris le temps d’asseoir mon gameplay avant de démarrer quoi que ce soit.

Deux semaines plus tard, Exil s’interrompait (le projet a plus ou moins repris depuis). Le travail en équipe n’avait pas été productif et ne m’avait montré quasiment que des désavantages. Mon concept de jeu semblait assez solide et prometteur. C’était un jeu solo, linéaire et dans une ambiance qui me plaisait. Je commençais alors à travailler plus sérieusement sur Little God Story. En solitaire.

http://www.moddb.com/games/exil

http://www.moddb.com/games/little-god-story

11 commentaires à propos de “Little God Story : DevBlog #1”

  1. Tu pourrais faire un billet sur tes méthodes de travail?
    – outils pour créer tes docs et travailler dessus en groupe
    – outils et partage de tes mesh/maps
    etc

  2. Froyok a dit :
    Ouais mais nan, pas de faux espoirs : Exil c’est définitivement mort.

    C’est pas ce que dit la page ModDB… Dommage.

    skaven a dit :
    Tu pourrais faire un billet sur tes méthodes de travail.

    Justement, quand on a travaillé sur Exil, on avait pas ce genre d’outils. Donc je n’ai aucune idée de comment font les équipes pour partager leur travail (ça doit souvent être un beau bordel !)

  3. Sur le dernier projet sur lequel j’ai bossé, les softs en quelques mots:

    Subversion comme VCS. Personnellement je déteste, des vrais soft pro comme AlienBrain (payant.. cher) que j’avais utilisé au taff avant, sont bien plus complets et facile d’utilisation, et avec une vrais interface graphique au lieu du truc un peu bidouillé intégré dans le shell de windows.
    Si certains connaissent de bons VCS, ou client pour Subversion je suis toute ouïe !

    Vu qu’on bossait par le net, on utilisait aussi googledoc pour se partager des tableaux excel-like, avec les listes d’assets, deadlines, attributions, % de finition des différentes étapes, pour la 3D, j’imagine qu’il y avait d’autres tableaux pour les devs, mais je n’y ai pas touché. Certains des docs étaient accessible en lecture seule pour une partie de l’équipe, et réservée aux leads.

    Un wiki-like privé pour la doc technique interne, et pour l’édition des game-design documents, et textes de background. Avec aussi une section réservé aux nouveaux qui rejoignent le projet, pour expliquer un peu le fonctionnement global de l’équipe et des softs.

  4. ng-aniki a dit :
    Sur le dernier projet sur lequel j’ai bossé, les softs en quelques mots:
    Subversion comme VCS. Personnellement je déteste, des vrais soft pro comme AlienBrain (payant.. cher) que j’avais utilisé au taff avant, sont bien plus complets et facile d’utilisation, et avec une vrais interface graphique au lieu du truc un peu bidouillé intégré dans le shell de windows.
    Si certains connaissent de bons VCS, ou client pour Subversion je suis toute ouïe !
    Vu qu’on bossait par le net, on utilisait aussi googledoc pour se partager des tableaux excel-like, avec les listes d’assets, deadlines, attributions, % de finition des différentes étapes, pour la 3D, j’imagine qu’il y avait d’autres tableaux pour les devs, mais je n’y ai pas touché. Certains des docs étaient accessible en lecture seule pour une partie de l’équipe, et réservée aux leads.
    Un wiki-like privé pour la doc technique interne, et pour l’édition des game-design documents, et textes de background. Avec aussi une section réservé aux nouveaux qui rejoignent le projet, pour expliquer un peu le fonctionnement global de l’équipe et des softs.

    Merci pour tes infos ng.aniki. Je pense qu’actuellement, un wiki privé est un bon moyen de mutualiser les infos en effet.

  5. Putain faire l’apologie d’AlienBrain…on aura tout vu ! 😉 Aniki, regarde plutôt du côté de Perforce pour les gestionnaires de version pros et propres

  6. J’avoue, j’ai pas eu l’occasion d’en voir beaucoup, mais par rapport à subversion et svn, il n’y a tout de même pas photo.
    (De ce que j’ai pu voir, AlienBrain était bien foutus, après vous avez p-e eu de très mauvaises expériences ?)

Répondre à SPTX Annuler la réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*