Non, en fait le projet n'a pas encore été baptisé. Lorsque j'ai commencé à le programmer c'est comme ça que j'ai nommé le projet Dev-C++ pour m'y retrouver dans tous mes fichiers, et puis le temps a passé et je n'ai pas trouvé de nom qui m'ait fait vibrer. Quand j'ai décidé de faire ce site, j'ai écrit RPG Engine partout parce que depuis quelques mois c'est par ce nom que je désignais le projet quand j'en parlais avec des amis programmeurs. Quoiqu'il en soit, ce brouillon ne restera pas, je veux un nom évocateur (vague...), affaire à suivre...

Vous vous souvenez de Final Fantasy IX? Si vous ecrivez juste la situation initiale du scénario, ça donne quelque chose du genre: "Un bande de voleurs veut enlever la princesse, qui elle-même veut s'échapper du château. Parallèlement, la reine avide de pouvoir mène la guerre à tous ses voisins." Rien de très original jusque là, et si ce n'était pas Square Soft (maintenant Square Enix), on ne donnerait pas cher du reste. Pourtant, après quatre fois cinquante heures de jeu, le scénario paraît toujours aussi complexe, tellement ... parfait! Si vous ne connaissez pas le jeu ou si vous ne l'avez pas terminé, ruez-vous dessus, c'est une expérience qui marque :-) Personne ici n'a la prétention d'écrire un scénario à la hauteur de FF IX, mais il est évident que publier l'introduction ne pourrait être qu'une erreur.

Tout d'abord, il faut bien faire la différence entre le développement du moteur de jeu (ce que je suis entrain de faire) et la création d'un jeu à proprement parler qui exploite ce moteur (en scriptant le scénario, créant les textures etc...)

Pour le moteur, dès le début je me suis donné un an. Quand j'écris ces lignes j'en suis à cinq mois, et j'ai un TileEngine (moteur graphique), un ScriptEngine (moteur de langage de script) et tout ce qui est nécessaire pour permettre l'évolution de ce qui est déjà établi. Ce ne sont que deux moteurs mais pourtant le plus gros du travail est déjà accompli.

Il reste encore à coder un SoundEngine (très rapide ça), un BattleEngine (moteur de combat, je ne sais pas encore pour quel type je vais opter) et un système de jeu (compétences).

Une fois que le GameEngine (l'ensemble des moteurs) sera achevé, on pourra commencer à créer un jeu en tant que tel (avec le scénariste, le ou les graphistes etc). Là c'est encore une aventure de plusieurs mois, mais plus seul.

Autrement dit, ne consultez pas cette page tous les jours dans l'espoir de télécharger le jeu ;-)

Avant toute chose, il faut définir le "projet" impossible par excellence: "Je veux créer mon propre RPG, je vais faire ça avec tous mes copains (on sera une trentaine), il y aura 50-60h de scénario, 10 persos jouables et le système de jeu sera du jamais vu, avec des dizaines de critères pour la gestion des combats etc. Il me manque juste un programmeur pour commencer".

Si un élément au moins fait partie de la réalité de votre projet, plusieurs choix sont possibles:
- redescendre sur Terre (devenir raisonnable)
- abandonner définitivement (sic)

Vous direz ce que vous voudrez, et "on" va jaser parce que je prêche pour ma chapelle, mais sans programmeur il n'y a pas de jeu, alors qu'un programmeur seul peut tout à fait créer un jeu vidéo (moche, mais fonctionnel ;-)). Regardez John Carmack, créateur de Doom! J'ai vu des dizaines de projets de jeu sans programmeur, ou bien qui réservent une place secondaire à ce membre de l'équipe: ce n'est pas réaliste.

Si vous êtes motivé pour la création d'un RPG (à la racine, pas avec RPG Maker...), alors vous devez apprendre à programmer. Ça peut se faire dans beaucoup de langages: le C++ (bien sûr ^^) mais aussi en Python (très populaire), en Visual Basic (pour ceux que ça ne dérange pas), en C (pour les sportifs), en GOTO++ (euh, non, ça c'est pas vrai, demandez à Funto), en Java (éventuellement)... même en une sorte de Basic qu'on appelle le DarkBasic, orienté jeu. Si vous êtes débrouillard, vous devriez pouvoir apprendre n'importe lequel de ces langages: programmer n'est pas difficile! La seule règle est: découvrez seul. La plupart des programmeurs amateurs n'achètent un livre que très longtemps après leurs débuts: comprenez bien que c'est l'empire de la débrouille, l'autodidacte est roi ici. Il y a assez de tutoriaux pour chaque langage pour vous faire lire jusqu'à votre septième réincarnation. Le plus souvent, si vous avez un ami "qui sait" sous la main, vous lui poserez des questions auxquelles Google a la réponse et ça va passablement l'énerver. Evitez...

Une fois que vous maîtriserez un langage (je me permettrai de vous déconseiller de considérer ce point comme accompli après avoir programmé votre convertisseur euro (et tant que j'y suis, ne le postez pas sur cppfrance.com, vous êtes gentil ;-)), apprenez à utiliser une librairie graphique.

Créer un jeu (scénarisé tout particulièrement) demande une bonne maîtrise des particularités du langage que vous aurez choisi. Si vous avez opté pour le C++ par exemple (c'est mon cas), apprenez la programmation orientée objet (POO) et les allocations dynamiques de mémoire. Utilisez la STD et la STL, etc... Quand vous pourrez lire un programme écrit par quelqu'un d'autre sans commentaire à propos de la syntaxe mais simplement à propos de la logique du programme (ce qu'il fait) en le comprenant, vous aurez déjà une connaissance active du langage.

Les librairies graphiques sont nombreuses. Toutes ne sont pas portables (càd "compatibles" avec différents systèmes d'exploitation (OS) tels que Linux, xxxBSD, Mac, KeliOS (;)) etc...), mais en cherchant un brin vous trouverez tout ce qu'il faut en la matière. Un exemple est la SDL (C/C++), monument du genre, mais il y en a d'autres, tentez! Personnellement, j'utilise l'OpenGL en mode 2D pour ce projet-ci, mais ce n'est probablement pas le meilleur choix. Jetez un coup d'oeil du côté d'Allegro, c'est une librairie très attrayante!

A partir de maintenant, il ne vous reste "plus qu'" à lire des dizaines de documents (si vous ne comprenez pas l'anglais, ce n'est pas vraiment la peine d'essayer, je le crains pour vous) traitant de la création d'un moteur graphique pour RPG. Vous vous rendrez compte des différents styles possibles: 2D pure, isométrique (vue plongeante: plusieurs variantes (losanges, hexagones...)), 3D (courage!),... Faites votre choix en fonction de vos goûts et de vos capacités (pensez à l'aspect graphismes: dessiner des tiles (cases) en 2D est plus aisé que de dessiner des tiles en perspective). Moi j'ai de la chance, j'aime le style rétro et c'est le plus simple à coder et à dessiner ;-).

J'ai un dernier message pour vous: j'ai dû lire des dizaines de documents avant que quelques uns ne me signifient l'importance d'un Script Engine (càd la création de son propre interpréteur de langage de script). Il est indispensable et doit être évolué! Pensez-y.

Le code source sera entièrement distribué (gratuitement et librement, cela va de soi) une fois le projet achevé (dans sa première version complètement fonctionnelle du moins). Jusque là (et ça peut durer un moment :/), il reste bien gentiment sur mon disque dur, et sur quelques disques de relations. La raison est toute bête: je ne veux pas montrer un travail inachevé. C'est comme distribuer le brouillon d'une dissertation, ça rend forcément une mauvaise image du travail global. (C'est pas que le travail global soit bon dans mon cas, vous noterez ^^).

Je reconnais que moi-même je ne sais plus... Cela fait plusieurs mois que je n'ai plus même ouvert le projet, certains aspects du code me sont devenus insupportables; c'est vraiment dur de devoir assumer les erreurs de conception de sa jeunesse. Si au moins je ne m'en rendais pas compte, sgnif. Le système de menus prendrait des siècles à développer avec le système actuel, et le Battle Engine devient franchement pénible à intégrer. J'hésite (et pense sérieusement) à tout reprendre depuis le début, sur de nouvelles bases. j'ai rempli plus d'un cahier de notes pendant tout le développement par rapport à la conception entre autre, et dès lors le travail devrait pouvoir avancer plus vite. Dans cette optique, j'ai commencé des librairies parallèles: OGLKL (pour la gestion de menus sous OpenGL) et DS++ (script engine plus évolué), ainsi que la reprise à mon compte de K2DEngine, wrapper autour de SDL/OpenGL orienté développement de jeux en 2D, initié par CyberKeirua.

Pour tout vous dire, j'aime toujours autant les RPG, et arriver au bout reste un de mes objectifs, mais ça va prendre longtemps; très longtemps.

Pour l'instant, il revoit la nuit, et c'est déjà un bon gage pour la suite :). Le code de REborn prend vite de l'ampleur, il y a déjà beaucoup de choses en place lorsque j'écris ces lignes (mi-novembre 2005), et j'ai les idées plus claires qu'avant en ce qui concerne "ce qui doit être codé et comment". Je préfère ne pas spéculer sur le temps que ça va prendre par contre. Au point de vue des "features" du jeu, rien ne change ou presque: toujours de la 2D à la vieil FF, le style de "game logics" reste le même. Globalement, c'est uniquement une énorme amélioration de la propreté et de l'évolutivité du code, qui va demander un peu de temps c'est vrai, mais de toute manière, il n'était plus possible de coder sur une telle saleté ^_^. Je vous laisse, j'ai cours d'informatique maintenant, c'est trop de la blague :D. On fait du java tout pourri. J'ai confiance en la viabilité de REborn.