   |
|
Aux origines, comme un bon nombre de jeux (indépendants mais aussi professionels) aujourd’hui, Koruldia se base sur un moteur de jeu. Celui ci anime le « middleware » RPG Maker VX (tkool.jp ou rpgmakerweb en occident), un moteur offrant de bonnes performances 2D et assez récent (sorti en 2008 aux USA). C’est la dernière version de la gamme RPG MAKER (ou RPG Tsukuru en VO).
Voici un aperçu des jeux qu'il est possible de créer avec le logiciel d'Enterbrain Inc, tel que mis en avant par l'éditeur :
Cela dit, de nombreuses restrictions telles que la gestion des ombres/lumières, particules, déplacements ou encore l’intelligence artificielle et les effets spéciaux avancés ont conduit dans un premier temps à l'apport de nombreux ajouts de base, tel que le « particuleur » de Fabien, un module mathématiquement complexe dont un extrait est visible en screenshot plus bas, puis dans un deuxième temps au développement d'un module-système appelé Jiritsu afin d’aller encore plus loin (voir section suivante).
En effet, l’une des particularités de RPG Maker depuis la version XP (celle qui a précédé VX) est d’embarquer une librairie de programmation basée sur le langage RUBY : le RGSS 2 (la première version était dans XP). Avant ces versions, le paysage était bien différent.
Ci contre : article parlant de la création amateur de jeu vidéo
(cliquer pour agrandir dans une nouvelle fenêtre)
Ce vieil article scanné du magazine « Console Max » en décembre 2003 (numéro de janvier 2004) résume maladroitement l’état de la scène du jeu vidéo amateur (les indépendants n’existaient pas vraiment à l’époque) et montre que Koruldia avait déjà une présence sur la scène.
Cependant à cette époque le projet était très amateur et basé sur la franchise Pokémon (aujourd’hui uniquement basé sur quelques points de son game-design qui seront abordés dans la suite de cette section ).
Avant la version XP sortie en 2005, RPG Maker (versions 95, 2000/2003) fonctionnait sur le principe d’un jeu (la notion de licence n’existait pas, le CD faisait office de licence tout comme un jeu sur console), amélioré par la suite avec la sortie de la version 2000, bien plus riche et enfin largement paramétrable.
Toutefois, l’intérêt semblait davantage lié au fait de jouer à créer plutôt que de faire quelque chose de concret (à l’image des éditeurs de circuits dans certains jeux de course); et le système s’avère bancal dès lors qu’on tente d’aller plus loin techniquement (résolution SuperNes, codage des couleurs par couches de 8 bits, programmation uniquement événementielle difficilement gérable sur la durée, etc.).
Extraits de la Démo Remix de Koruldia (Noël 2004)Cela dit, cet outil (RPG Maker version 2000/2003) n’en restait pas moins pour l’époque un des seuls outils de création accessible à tous. Il peut parfois encore être utilisé par la scène du RPG amateur mais abandonné par les indépendants. En effet, cette version n’est que vaguement légale étant donné qu’il faut posséder le disque en guise de licence, disque qui n’a jamais quitté le Japon. Les vieilles versions de « l’ère ASCII » (95/2000/et 2003 par extension) sont toujours considérées comme des jeux au Japon néanmoins, on les trouve au rayon jeux vidéo (d’occasion et très rarement, a Akihabara par exemple et assez chers).
Avec la reprise du projet par Enterbrain (l’outil était jusqu'à présent édité par ASCII), d'excellentes versions ont été mises en vente (XP/VX) et les anciennes (95/2000) réedités avec le nouveau label sous forme de pack collector « Value ». A noter que la version 2003, première version éditée par Enterbrain n'est qu'une update de la 2000 avec un petit lifting du système de combat, plus à la mode de l’époque. Mais comme pour marquer le changement d'ère et d'éditeur, les nouveaux outils côtoient désormais Photoshop au rayon logiciels de création au Japon et ne sont plus réservées aux magasins spécialisés.
Pendant une courte période, le code source de la version 2000 était disponible sur le site d’ASCII. Mais suite au rachat par Enterbrain, ces ressources ont été retirées, l’outil redevenant tout à coup lucratif : la générosité n’était plus de mise. Ce fut néanmoins suffisant pour enrichir Koruldia avec de nombreuses heures passées par Kayser sur l'amélioration du code... heures qui finalement ne serviront à rien avec la sortie de la version XP, qui proposait directement la plupart des améliorations si longues à développer. XP était donc devenu taboo dans l'équipe : il était hors de question d'effectuer un portage dessus ! Par chance VX est arrivé, ce qui a permis de stopper notre bricolage désespéré, qui commençait sérieusement à ressembler à la 32X de Sega : une navrante tentative de maintient en vie d’un outil à l’agonie (voir vidéo).
Pour résumer, ces vieux outils (RM2000 surtout) ont été une grande source d’apprentissage et d’évolution pour Koruldia. A l’époque le projet portait certes ce nom, mais n'avait pas la même ambition ni les mêmes idées/concepts. Il s’agissait tout au plus de s’entraîner pour prendre du plaisir à créer (l’aboutissement de cette période est mesurable dans ce vieux teaser vidéo).
C’est dans ce contexte que le projet « Koruldia » (le nom n’ayant pas changé par la suite par hommage) commençait déjà à voir le jour, sur RPG Maker 2000 dès 2002 après une présence de KaYsEr sur la scène primitive dès 1999, scène composée de simples forums désertiques et éphémères quand l'Internet était lent et rationné.
Après avoir apporté de nombreuses idées pour améliorer l'outil pendant quelques années de bricolage (en tant qu’adolescent passionné), voici le résultat obtenu :
Extraits de la Démo Remix de Koruldia (Noël 2004)Cependant la version XP est rapidement arrivée, et bien que ce ne fut pas encore parfait, le vent avait changé de direction et on pouvait deviner que l’avenir serait aux modules greffables sur une base bien rôdée. Il n’y a qu’à voir le nombre de jeux modernes faits avec le même moteur Unreal Engine 3 : de Batman Arkham Asylum à Bioshock, en passant par un style très différent comme Borderland et son cell-shading, et le tout sous un langage de script « middleware », de la même façon que procède VX avec RGSS².
Enterbrain s’est désormais positionné sur le jeu vidéo indépendant et plus seulement amateur. Il a pourtant fallu attendre la version suivante, RPG Maker VX, pour obtenir un business model mature. Cette version va jusqu’à être utilisée dans les écoles de game-design japonaises (l’outil peut être vendu en pack de 10 licences dites académiques).
Pourtant, à première vue on pourrait croire que cette version est moins aboutie car son interface est plus sobre. Hors c’est ici que se trouve tout l’intérêt de VX.
Pourquoi VX déjà ? XP signifiait de toute évidence EXPERT, mais que veut donc bien vouloir dire VX ? C’est un peu plus culturellement localisé cette fois, une ancienne voiture tout terrain assez culte au Japon a eu pour nom de code VX. C’était une voiture capable de basculer en mode 4 roues motrices sur un terrain accidenté ou en 2 roues motrices une fois en milieu urbain. Et c’est là tout l’intérêt de RPG Maker VX également, aucune fioriture dans l’interface de base si un néophyte s’y colle afin de ne pas le faire fuir : un simple éditeur de chipset (décors découpés par blocs) très basique spécialement conçu pour réaliser des jeux « rétro », une certaine limitation dans les ressources, et une programmation événementielle rappelant celle des RPG Maker ayant précédés la version XP.
Le mode d’utilisation précédemment évoqué peut s’apparenter au mode 2 roues motrices de la voiture : inutile de gâcher du carburant sans raison et de s’embrouiller avec des fonctions inutiles si c’est pour faire un Dragon Quest « old school » tel que nous suggèrent les ressources fournies par défaut avec VX.
Seulement voilà, l’outil est également fourni avec un système de programmation RUBY... Voici donc notre fameux passage en mode 4 roues motrices. Le mode expert.
Celui là même qui permet de déplacer son personnage au pixel par pixel et non plus par gros blocs par exemple, tout en permettant d’aller en diagonale alors qu’à l’origine seules 4 directions étaient disponibles. Toutes ces choses ajoutées le sont donc par l’intermédiaire de petits modules que l’on nomme « scripts » de façon plus courante dans le milieu. L’organisation se fait en toute transparence, il est donc plus aisé d’y faire une maintenance ou diverses évolutions.
C’est dans ce contexte qu’est né le module Jiritsu...
Jiritsu est un système. Il est épaulé d’un module sous forme de script et reste avant tout une méthodologie ainsi qu’une idée conceptuelle ingénieuse, basée sur le désir d’afficher un résultat à l’écran qui ne puisse pas accuser le poids du temps de façon trop flagrante ou au sens péjoratif du terme.
L’idée est donc d’utiliser de la technique pour s’affranchir de la technique.
Le mot « Jiritsu » signifie littéralement « indépendance » et c’est clairement ce qu’il offre… Ce nom est donc utilisé systématiquement lorsqu’un aspect lui tourne autour de façon fondamentale, par exemple le système de combat « Jiritsu Fight System » car il en fait massivement appel. C’est lui qui permet d’afficher des attaques dont les effets spéciaux peuvent par exemple illuminer dynamiquement toute la map (boule de glace qui reflète les décors, feu qui perturbe l’aspect des textures, shaders très évolués, etc.).
Plus généralement, c'est ce système qui permet pour certaines scènes d’avoir une caméra mobile sur 360° en plein jeu ou encore la gestion des particules massives et certains effets spéciaux : brume ou feu, bloom (lueur diffuse), dark-glow, intempéries, lucioles/petites créatures, flou de mouvement, morphing, scintillement, zoom in/out, bullet-time, mises en ambiance diverses, etc. Ce système permet également un rapprochement de caméra (jouable) selon certaines situations qui le nécessitent, comme par exemple un intérieur de maison assez petit, afin que la surface soit bien occupée.
Exemple de basculement de caméraLors du basculement 360° de la caméra avec ce système, la base de données du jeu reste accessible ; il ne s’agit pas d’une vidéo en lecture, il est donc possible de vérifier l’appui des touches à tout moment - ce qui permet la création de QTE (quick time event) ou encore le fait d’afficher une boite de dialogue par dessus, et bien entendu une éventuelle séquence de touches aléatoires qu’on demanderait de taper ou bien une barre d’énergie, etc. Le tout sous un affichage sans réelles limites, mis à part la résolution de travail native qui est elle-même étudiée afin d’être affichable en taille X2 (voir davantage). Le rendu reste précis au pixel et donc enrichissable d’un filtre type « super eagle » ou « HQ2Xsai » et autres vectorielisations... De par sa nature même.
Autre point important de ce système : les performances.
La mise en mémoire des données se fait sans chargement ou gel de l’action (il est donc possible d’y synchroniser une musique ou effet sonore programmé ; que serait un bon QTE sans un retour sonore de la réussite ou ratage de l’appui des touches), le débit reste fluide sur des machines assez moyennes mais toutefois une bonne RAM est nécessaire (2GO sont à préconiser).
Le résultat n’en demeure pas moins impressionnant si l’on considère la puissance requise et l’absence d’exigences concernant la carte graphique. Koruldia ne se sert « que » du couple CPU+RAM.
Cependant il ne s'agit pas de développer des fonctionnalités creuses et sans buts, le principal a toujours été d'adapter la programmation aux besoins scénaristiques et au game-design. En cela de nombreux outils ont été développés pour donner davantage de profondeur au jeu. Ceci n'a rien à voir avec un feu d'artifices d'effets gratuits visant à ne donner pour finir qu'un simple jeu technique, car de toute manière il ne faut pas se leurrer : un jeu amateur/indépendant n'ayant pas les mêmes moyens que les grands studios de développement a tout intérêt à miser sur autre chose que la technique pour se faire remarquer.
Toutefois, une bonne technique reste un « minimum vital » et c'est pourquoi un maximum d'efforts est fourni pour Koruldia : l'indépendance offerte par les ajouts au moteur de base, les astuces, l'ingéniosité, ou encore les ajouts C++ développés aux cotés du moteur (dll) donnent suffisamment de potentiel au jeu pour qu'il soit possible d'aller de l'avant dans d'autres domaines !
Grâce à Jiritsu, le développement du jeu est plus efficace tout en permettant un niveau d’affichage techniquement impossible sous le moteur d’origine, tout comme sur bon nombre d’autres. Rappelons tout de même que RPG Maker VX est un outil à la licence d’une cinquantaine d'euros, ne réclamant pas de royalties et un achat unique. Nous sommes très loin d’un Unreal Engine 3 (UDK) ; comparons ce qui est comparable, le but est d’avoir un projet viable.
La méthodologie développée pour Koruldia considérant ses besoins en affichage et par exemple pour la gestion de créatures en combat, fait du moteur d’origine un choix judicieux dans la mesure où (d’une manière certes détournée) il est possible d’afficher n’importe quoi. Le secret tient à une partie du calcul générée sur une machine ultra-puissante et réinjectée dans le jeu sans perdre son potentiel interactif. On n’est pas sur Mega CD ou sur CDI (voir au commencement des 32bits). De toute manière le problème était plus dans la mentalité des développeurs que dans les capacités machine, une période sombre.
Plus ou moins à la même époque, Donkey Kong Country sur SuperNes a montré que l’ont peut faire ainsi (graphismes pré-calculés sur machines très puissantes) et tenir tête à des systèmes+software bien plus récents. Rise of the Robots à montré qu’on peut également avoir la même méthodologie tout en se plantant (à cause de son gameplay). C’est un tout et il faut une harmonie. Les pré-calculs générés sur station graphique peuvent prendre parfois une heure de calcul pour une seule frame. Le véritable challenge est ensuite de réinjecter ça dans le jeu par Jiritsu, sans que le doute ne soit permis concernant l’intégration. C’est ainsi que tout se fait sans coupures, sans césures, et surtout sous un minimum d’hétérogénéité.
1 frame pour 60 minutes de calculs, alors qu’un jeu récent sur console (ou un pc bien plus modeste) doit tourner en temps réel de 40 à 60 frames par seconde. Voilà qui permet de se rendre compte de la précision du travail réalisé en termes d’affichage (VX permet lui aussi de tourner à 60 images par seconde, avec un mode double buffer et la syncro verticale de l’écran ; ce qui se traduit par une grande fluidité et stabilité d’image ainsi qu’un lissage des mouvements que les vidéos publiées ne peuvent retranscrire).
Cette méthodologie part du même principe de limitation que les créateurs de Donkey Kong ont eu à affronter (la SuperNes ne pouvait plus tenir tête aux nouvelles concurrentes 32bits [psx/saturn] et Nintendo tardait à sortir sa nouvelle machine [N64] car pris de vitesse).
Ce qui parait à première vue décourageant peut s’avérer stimulant une fois qu’on sait exactement comment s’en servir pour s’affranchir de la technique et la dépasser. Un système astucieux pèsera toujours plus lourd que la technique brute utilisée sans ingéniosité.
Koruldia a su trouver ses propres moyens de stimulation et tout comme pour sa vision de l’esthétisme, la programmation est quelque peu atypique dans son appréhension courante (hors modules). Ce serait d’autant plus flagrant en abordant les méthodes de mise au point de l’IA/combats ou la gestion événementielle d’un bon nombre de choses en totale intégration avec la programmation plus traditionnelle. De quoi résonner avec l’aspect graphique lui-même très hybride techniquement, ou encore l’aspect musicale lui aussi partageant cette idée de dualité en cumulant une instrumentalisation moderne avec des sons issues d’anciennes puces sonores (Megadrive, Commodore 64...).
Les autres sections vous donneront davantage de précision concernant ces sujets.
     |
Keywords : pokemon koruldia rpg making pokémon rpg-maker vx rgss game-making pocket monsters
Conditions d'utilisation du site | Nous contacter | FAQ | Plan du site
