Published 2011-07-12 - Updated 2016-06-05

Tower of Ordal, ou la création d’un RPG (Postmortem)

Il est toujours plus facile de voir ses erreurs avec du recul. Ce qui ne veut pas dire que ce soit simple, bien que ce soit toujours enrichissant. Un an après la sortie de mon RPG Tower of Ordal sur Windows Phone, je reviens sur ses origines, sa conception et son développement en détail. Une belle occasion de partager avec vous les obstacles rencontrés lors de la création d'un RPG et une des nombreuses manières d'y faire face.

Le contexte

En octobre 2009, deux amis et moi avons traversés l'Atlantique pour continuer nos études à Montréal, ville des caribous et du jeu vidéo. Bien décidés à vivre notre rêve, nous avons créé notre studio indépendant : D2P Games. Nos moult aventures ont été récompensées par une victoire : la sortie de notre premier jeu commercial, Reckless Squad. Épuisés par un développement bien plus long que prévu et devant accommoder le retour en France de l'un d'entre nous, nous avons opté pour nos nouveaux projets de faire trois jeux modestes pour la nouvelle plateforme Windows Phone 7, un par personne.

Ma première tentative a été Tactically Reckless, un RPG tactique dans la veine de la série Fire Emblem qui reprenait les personnages de Reckless Squad.

Tactically Reckless
Tactically Reckless

A l'époque je n'avais pas encore de Windows Phone. Je développais et testais le jeu sur mon PC, avec l'émulateur. Mon seul contact avec la bête avait été lors d'une session de tests de notre jeu Pouing dans les locaux montréalais de Microsoft, à une époque où Tactically Reckless n'existait pas encore.

Quelle surprise j'ai eu en faisant tourner pour la première fois Tactically Reckless sur mon Omnia 7 : c'était injouable.

Premièrement, l’écran était trop petit. Toucher du doigt les unités ou les cases se révélait beaucoup trop difficile et entrainait de nombreuses fausses manipulations. Pire encore, pour déplacer la caméra il fallait déplacer deux doigts en même temps sur l’écran, une manœuvre trop hasardeuse pour être acceptable.

L’autre souci, j'aurais dû le prévoir. Le concept n’était absolument pas adapté à la plate-forme et à son public. T-RPG oblige, une partie pouvait durer plusieurs heures, ce qui est incompatible avec l’utilisation typique d'un smartphone. Il était bien sûr possible d’arrêter et de reprendre une partie à n’importe quel moment... à condition de pouvoir se remettre dans le contexte et de se souvenir de sa stratégie.

Bref, Tactically Reckless n'était pas un jeu adapté à un téléphone, si bien que je l'ai rangé sur l'étagère en me promettant de revenir vers lui un jour. Ce que je n'ai pas fait, le projet l'ayant succédé ayant capturé mon imagination : Tower of Ordal.

La vision initiale

Après avoir euthanasié Tactically Reckless en février 2011, j'ai passé un bon mois à essayer plusieurs pistes. J'ai entre autre réalisé un moteur de jeu d'aventures 2D avec son éditeur, inspiré par les sorties mensuelles de Tales of Monkey Island de Telltale Games. Finalement, c'est vers le genre de mon enfance et de mes rêves que je me suis une fois de plus tourné : le RPG.

J'ai commencé à développer des RPG à l'age de 10 ans avec RPG Maker 2000. Cette fois, soucieux de ne pas répéter les erreurs de mes tentatives précédentes, j'ai volontairement visé bas. C'est en m'inspirant d'Etrian Odyssey sur DS que j'ai posé la formule d'un RPG simplifié qui allait devenir Tower of Ordal.

Etrian Odyssey (à gauche) et la première version jouable de Tower of Ordal (à droite)
Etrian Odyssey (à gauche) et la première version jouable de Tower of Ordal (à droite)

Conformément à la formule du dungeon crawler, le joueur est un aventurier qui progresse dans un labyrinthe, découvre des trésors et affronte des monstres. Mon plan était de réaliser plusieurs épisodes utilisant le même moteur de jeu mais mettant en scène des labyrinthes et des monstres différents.

Le concept se prête bien à de courtes sessions de jeu, les contrôles sont adaptés au tactile et il n’y a pas une tonne de texte à lire. J’ai fait particulièrement attention à ne pas répéter les même erreurs qu’avec Tactically Reckless et ai développé le jeu de A à Z avec un vrai téléphone en main.

La navigation - Quitter la troisième dimension

Dans la première version, les environnements étaient réalisés en 3D et le joueur se déplaçait en utilisant les gestures : faire glisser le doigt de haut en bas permettait d’avancer, le faire glisser de droite à gauche de se tourner à 90° vers la gauche, etc. Une utilisation du tactile intéressante et intuitive qui s'est malheureusement révélée laborieuse et éprouvante à la longue.

J'ai donc décidé de revoir l'interface : le téléphone serait désormais tenu en mode paysage et des boutons seraient proposés pour les déplacements.

Et c'est à ce moment là, pris d'une frénésie critique au beau milieu de la nuit, que j'ai réalisé que la 3D devait disparaitre.

Si la représentation du labyrinthe en 3D me tenait à cœur pour le challenge technique et artistique que cela présentait, force m'a été d'accepter qu’elle était entièrement superflue et ne contribuait en rien au gameplay. La décision de la supprimer a été difficile mais nécessaire.

L'alternative m'est venue du mode Maître d'Arme du jeu de combat Soul Calibur 2 :

Soul Calibur 2
Soul Calibur 2

Le labyrinthe serait présenté sous forme de cases 2D, ces cases pouvant contenir un combat contre un monstre, un coffre, un point de sauvegarde ou une porte fermée. C'était déjà comme ça que fonctionnait le labyrinthe en 3D, j'ai uniquement changé la présentation et la navigation.

La vue première personne laisse désormais place à une icône marquant la position du joueur sur la carte. J'ai piqué ce marqueur à Google Maps : c'est depuis longtemps un standard pour évoquer la localisation. Dans l'ensemble, les joueurs comprennent intuitivement sa signification. Le fait de toucher du doigt la case sur laquelle on veut se rendre est aussi évident. Ce qui l'est moins en revanche est le fait de ne pouvoir se déplacer que sur les cases adjacentes. Elles ont beau être en surbrillances, la plupart des joueurs s'attendent à ce que le marqueur se déplace automatiquement vers une case déjà visitée lorsqu'elle est touchée, sans avoir à se déplacer laborieusement tout le long du chemin. En rétrospective, je ne vois aucune raison de ne pas avoir implémenté du pathfinding pour le faire.

Le résultat final dans Tower of Ordal est très similaire à la présentation utilisée par Soul Calibur :

Tower of Ordal
Tower of Ordal

Le système de combat

De même, le système de combat a été entièrement revu afin de simplifier au maximum l’interface.

Quand le jeu était en mode portrait et vu à la 1ère personne, je n'avais pas assez de place à l'écran pour afficher plus d'un monstre :

Gare au Testomon, le monstre de test
Gare au Testomon, le monstre de test

Le fait de passer en mode paysage m'a donné assez d’espace pour enfin avoir plus d'un monstre en même temps. De même, toutes les attaques et compétences utilisables sont devenues accessibles directement depuis une simple pression sur l’écran tactile. Plus de menu, plus de sous-menus, juste des icônes :

Ce système de combat est resté inchangé dans la version finale.

Mon plus gros regret est sa lenteur. La jauge ATB piquée à la saga Final Fantasy ne contribue en rien au gameplay, elle ne fait que ralentir le rythme des combats. J'ai essayé de mitiger ce manque d'intérêt et de compenser l'inutilité des attaques normales passé un certain cap (un travers commun à beaucoup de RPG) en rendant ces attaques plus rapides : quand le joueur attaque avec l'épée, l'ATB est rechargée de moitié, ce qui lui permet d'attaquer plus souvent.

Cependant ce changement de dernière minute n'est mentionné nulle part dans le jeu et n'a que très peu d'influence. La stratégie dominante dans Tower of Ordal consiste à recourir au poison (c'est un effet stackable) tout en maintenant sa barre de magie alimentée grâce au sort Yggdrasil.

Pour pimenter un peu les affrontements, j'ai attribué à certains monstres une force élémentaire au hasard. Par exemple, sur la capture d'écran ci-dessous, la flamme à côté du nom du faucon signifie qu'il est de type feu et que les attaques d'eau seront particulièrement efficace sur lui. Elles infligent plus de dégâts et ce fait est visible grâce au nombre de points d'exclamation ponctuant la phrase résumant l'action. Cet indicateur subtil me vient de Golden Sun. Sauf qu'il est trop subtil. Comme le rechargement de l'ATB lors d'un coup d'épée, cet ajout s'est fait tardivement et aucun des Ghosts ne le mentionne : c'est au joueur d'expérimenter et de le découvrir.

En ajoutant ce mécanisme, j'ai aussi attribué aléatoirement une subtile altération de couleur aux sprites des monstres. L'effet est discret et pourtant j'ai trouvé qu'il agissait positivement sur le joueur, aidant à différencier les ennemis lorsqu'ils sont en groupe et donnant à chaque combat un caractère unique. C'est une jolie preuve qu'un peu de procédural peut contribuer grandement à la fraicheur des situations.

Reste que mettre au point un système de combat stratégique et intéressant est un exercice difficile que je n'ai pas encore maîtrisé.

Tower of Ordal
Tower of Ordal

Les animations de combat

Toujours en parlant des combats et de leur lenteur, la transition quand la vue change pour montrer le joueur recevant des dégâts est trop lente. Pire encore, quand deux ennemis attaquent successivement, la vue fait des vas-et-viens entre les ennemis et le joueur, ce qui est deux fois plus lent que nécessaire.

J'ai toujours vu ça comme un problème et la solution a toujours été claire : l'idéal aurait été afficher le portrait du joueur sur le même écran que les ennemis et jouer les animations de combat sur ce portrait. Malheureusement je n'ai pas réussi à l'intégrer dans l'interface existante de façon satisfaisante et j'étais trop occupé par le reste du jeu pour la revoir entièrement.

L'éditeur d'animation réalisé pour l'occasion
L'éditeur d'animation réalisé pour l'occasion

Autre difficulté : les animations de combat. Les réaliser a toujours été une corvée pour moi. Tower of Ordal utilise les animations vendues avec RPG Maker XP, ce qui est déjà une épine hors de mon pied. Cependant il a fallut les animer, et pour ça j'ai réalisé un petit logiciel qui aura demandé pas mal de temps et d'effort pour ne servir qu'une fois. Ces animations de combat sont des planches de sprites assez volumineuses, au format PNG, qui constituent 40% des 8 méga-octets du jeu. Ça peut paraitre peu, mais il faut garder à l'esprit que Tower of Ordal est un jeu mobile qui peut être téléchargé depuis une connexion 3G.

Une alternative aurait été d'implémenter un moteur de particules. Mais même aujourd'hui je n'ai ni le temps ni l'envie de le faire. A vrai dire, je compte me passer complètement des animations de combat pour mes prochains jeux. Je pense que secouer les monstres, les faire flasher d'une couleur spécifique et afficher les dégâts reçus sera largement suffisant. Si le temps ainsi gagné permet d'inclure plus de sorts dans le jeu, ça me parait être un compromis plus que satisfaisant.

Game Design - Bâtir la Tour, étage après étage

L'idée de la tour et le nom du jeu sont bien entendu des hommages à Tower of Druaga, un jeu d'arcade célèbre pour sa difficulté injuste. Le nom Ordal est une déformation d'ordeal, le mot anglais pour ordalie (une tâche extrêmement difficile et douloureuse) : c'était une façon de montrer que dans la tour, on ne rigole pas. Il est intéressant de noter que le mot ordal existe aussi en vieil anglais et qu'il signifie jugement. Un nom approprié pour le boss de fin du jeu.

J'avais d'abord planifié une vertical-slice du jeu : c'est à dire un échantillon complet, comme le premier niveau. J'imaginais faire quatre étages de la Tour, le premier étant les jardins à l'entrée, puis les sous-sols menant à un combat contre le premier boss : Kerberos, le gardien de la Tour. A cela j'ajoutais une caverne gelée et une autre enflammée avec deux boss optionnels qui octroyaient un nouveau pouvoir au joueur une fois vaincu. Ces pouvoirs en poche, il pouvait affronter Kerberos plus sereinement. Une façon de récompenser l'exploration.

Dans la version 3D, les boss étaient visibles dans le labyrinthe. Ici, Kerberos.
Dans la version 3D, les boss étaient visibles dans le labyrinthe. Ici, Kerberos.

Il reste quelques reliques de cette idée dans le jeu final. Vu la charge de travail représentée par ce que je voyais comme étant le tout début du jeu (peut-être la version d'essai), j'ai décidé de rendre les boss de glace et de feu obligatoires. Dans la version finale, Kerberos est situé à la moitié du jeu et garde la partie émergé de la Tour.

C'est à ce moment là que j'ai décidé de planifier à l'avance tout le contenu du jeu, grâce à un tableau :

Le seul **Game Design Document** de Tower of Ordal
Le seul **Game Design Document** de Tower of Ordal

Je me suis arrêté sur 15 étages, allant par pairs. Chaque pair se déroulerait dans un environnement différent de la Tour. Le premier étage de la pair renfermerait un trésor comme une nouvelle arme ou armure alors que le second serait ponctué par un boss. Chaque étage introduit également un nouveau monstre et se voit affecter un niveau optimal.

L'équilibrage

Comme pour tout RPG, le système de combat de Tower of Ordal repose sur des formules mathématiques. S’assurer de l’équilibre du jeu (balancing) n’est pas une mince affaire. J'ai toujours redouté cette tâche, ne sachant pas trop comment m'y prendre.

Mon fidèle acolyte, le Sancho de ma quête, a été le fameux logiciel Excel de la suite Office.

Pour chaque étage du labyrinthe, mon tableau renseigne une colonne niveau du joueur optimal. En comptant le nombre de cases à franchir entre l'entrée de l'étage et sa sortie et en appliquant le pourcentage de rencontres aléatoires, j'ai pu déterminer le nombre de combats que le joueur aurait à faire. J'ai ensuite affiné cette donnée par type d'ennemi. A ce moment là, déterminer le nombre de points d’expérience octroyé par ennemi est une simple division. Ça a plutôt bien marché au final. En jouant naturellement, sans faire de grinding, on arrive plus ou moins au niveau optimal que j'ai déterminé.

La feuille Excel contenant les stats des monstres
La feuille Excel contenant les stats des monstres

Ensuite, les stats de chaque monstre, comme ses points de vie, son attaque ou sa défense sont déterminées à partir de deux sources :

  • Les stats du joueur au niveau équivalent

  • Des « modificateurs » permettant d’augmenter ou diminuer les nombres en fonction de la « personnalité » du monstre.

Concrètement, chaque stat de chaque monstre est notée de 1 à 5. Si la défense d’un monstre vaut 3, cela signifie qu’elle est identique à la défense du joueur. Moins de 3 et le monstre est moins résistant. Plus de 3 et il est plus résistant.

En procédant de cette façon, j’ai pu déterminer un bon point de départ que j’ai ensuite affiné en testant le jeu encore et encore et en modifiant légèrement les nombres.

Afin de me faciliter la tâche, j’ai réalisé un petit utilitaire permettant d’exporter une section d’un tableau Excel vers un fichier texte ou binaire, qui peut être directement importé dans le jeu.

J'ai été plutôt surpris de m'en tirer à si bon compte sur l'équilibrage, même si j’admets volontiers que les mécanismes du jeu sont assez simples.

Les NPCs - Briser la Solitude

Lorsque j'ai décidé de simplifier au maximum la formule d'un RPG/Dungeon Crawler, j'ai aussi retiré les NPCs. Chose regrettable puisque c'est l'un des éléments que j'aime le plus dans un RPG. C'est en me demandant comment j'allais expliquer les mécanismes du jeu au joueur que j'ai eu l'idée d'incorporer des cases d'aide dans le labyrinthe. Chacune de ces cases donnerait un indice.

Un très bon conseil.
Un très bon conseil.

Très vite, j'ai détourné la fonctionnalité pour donner plus de vie au jeu. J'ai remplacé les vulgaires panneaux par des créatures mystérieuses qui aident parfois le joueur, dévoilent des infos sur l'univers quasi-inexistant du jeu et - bien entendu - apportent une dimension comique :

Les Ghosts ont apportés un peu de vie au développement du jeu
Les Ghosts ont apportés un peu de vie au développement du jeu

D'une façon générale, les Ghosts ont deux fonction : servir de tutoriel et briser la solitude du joueur.

Le mystère de leur nature en tant que seuls habitants de la Tour m'a très vite mis sur la piste du premier plot twist d'un jeu qui était parti pour n'avoir aucun scénario. Leur trahison à la fin du jeu, alors qu'ils guident le joueur devant Ordal pour le combat final aurait été plus efficace si j'avais implémenté dans le code la possibilité de changer leurs dialogues pour refléter les progrès du joueur. Malheureusement, j'ai fait ça à la fin du développement, épuisé et pressé par le temps et ce système reste très sommaire. Mais même sans véritable mise en scène, cela suffit à évoquer un semblant de scénario.

Leur inspiration vient avant tout des Garo, des ninja mort-vivants dans Zelda Majora's Mask qui, une fois vaincus, offrent des conseils au joueur. Ils ressemblaient déjà pas mal aux Jawa de Star Wars, mais j'ai accentué ce fait en insistant sur leur petite taille et leur robe. J'aime bien le côté créature à priori inoffensive, un peu fourbe, vivant en milieu hostile. Après tout, s'ils survivent en milieu hostile, c'est qu'ils ne sont pas si inoffensifs que ça, ce qui est prouvé dans Tower of Ordal lors de leur transition d'alliés à ennemis qui doivent être vaincus.

Jawa + Garo = Ghost
Jawa + Garo = Ghost

Le Boss Bonus - De l'autre coté du miroir

Le second plot-twist est l'étage bonus du jeu où le joueur - ayant prouvé sur supériorité sur la Tour - doit affronter son reflet. Bien entendu, le combat n'est pas du tout équitable. Mirror est bien plus puissant que le joueur et les rencontres aléatoires menant jusqu'à lui réutilisent les différents boss en les regroupant ensembles.

Sur le coup, la difficulté insurmontable ne m'a pas dérangé puisque j'ai toujours vu cet étage pour ce qu'il était : un bonus. Un challenge pour occuper ceux qui veulent continuer à jouer après la fin du jeu.

Même le sort **Debug** qui inflige des dégâts faramineux ne suffit pas à le tuer
Même le sort **Debug** qui inflige des dégâts faramineux ne suffit pas à le tuer

Seul problème : il n'y pas de générique de fin. Ça n'a jamais été prévu, et l'idée est un peu ridicule vu que seul mon nom figurerait dans les crédits (J'ai absolument tout fait, sauf la musique. C'est pour ça qu'il n'y en a pas.)

Du coup, certains joueurs ont pensés qu'il s'agissait de la vrai fin du jeu et ont regrettés l'explosion de difficulté, surmontable uniquement par des heures de grind. Le joueur peut apprendre le sort ultime (Dark Matter) au niveau 50... sachant qu'Ordal est prévu pour être battu au niveau 20. Pas cool.

Célébrer la victoire du joueur contre Ordal avec un écran de fin (peut être même une simple illustration ?) aurait fait passé le message et évité cette frustration. Mais comme pour les Ghosts, ça a été fait vers la fin et je n'avais plus le temps de revenir sur le code.

La technique

Outre la nature même de la plateforme (petit écran, transportable, etc), développer sur téléphone mobile présente quelques challenges techniques bien particuliers.

Par exemple, la gestion du tombstoning a été un soucis permanent. Dû au fait que les smartphones limitent ou interdisent le multi-tâche, lorsque l’utilisateur reçoit un appel ou lance une autre application, le jeu est quitté. Malgré tout, l’utilisateur a la possibilité de revenir au jeu rapidement et s’attend à retrouver sa partie là où il l’a quittée.

Pour le développeur, cela se traduit par la sauvegarde de toutes les données, persistantes comme temporaires, dans un fichier avant de les recharger et de s’en servir pour réhydrater l’application.

Il s’agit là d’un problème d’organisation et d’architecture, dans la mesure où tout le code doit être pensé pour cette fonctionnalité. Pour cela, la state machine de Tower of Ordal repose sur des états pré-déclarés et pré-instanciés, identifiés par des ID uniques plutôt qu’une state stack classique, plus difficile à reconstruire au chargement.

Le paradigme de la programmation orientée objet est connu pour ne pas être réellement adapté aux jeux vidéo, et c'est dans ce genre de situations que l'on s'en rend bien compte. Gérer le tombstoning en POO aurait demandé d'inclure de la sérialisation sur tous les objets composant le gameplay, ce qui se serait rapidement révélé un calvaire (et bonjour les dégâts lorsque leur définition change d'une update à l'autre).

J'ai donc privilégié une approche plus orientée données (Data Oriented Programming). Concrètement cela consiste à séparer le code de la façon suivante :

  • Les données immuables, chargées au lancement de l’application et qui ne peuvent être modifiées

  • Les données mutables, notamment la sauvegarde du joueur ou les différentes attributs des objets

  • Le code traitant ces données, à savoir des ensembles de fonctions

Lors de la sauvegarde de la partie ou du tombstoning, toutes les données mutables sont enregistrées dans un unique fichier binaire qui peut être rechargé à tout moment.

Les données immuables quant à elles sont chargées au démarrage du jeu à partir d’un autre fichier binaire présent dans le package de l’application. Ces données ne sont jamais modifiées durant l’exécution.

Enfin le code utilise principalement des classes statiques ou pré-instanciées qui ne comportent aucune variables membres. Les données et le code les transformant ont été entièrement séparés. Ainsi, une fois les données du jeu rechargées, le code peut redémarrer de n'importe quel point.

Les outils

Outre l'éditeur d'animation présenté plus haut qui a été développé spécialement pour l'occasion, mon outil principal dans la création du jeu a été Blacksmith. Il s'agit d'un éditeur de maps basé sur des tiles que j'ai développé il y a quelques années et que je continue de maintenir. Il a notamment été utilisé pour la création des scénarios dans Reckless Squad, c'est dire s'il est flexible.

Les maps sont définies grâce à deux couches. La première représente la forme du labyrinthe, la deuxième le type d'évènement présent sur chaque case (M veut dire monstre, C veut dire coffre, S veut dire sauvegarder, etc.) Enfin, chaque case peut être complétée par une chaine de caractère qui sert de paramètre au type d'évènement. Une case de type coffre avec la chaîne iron_sword attachée permettra de trouver l'épée de fer dans un coffre.

Pour tout le reste, j'ai principalement mis les mains dans le cambouis en utilisant des fichiers textes pour définir les différents items, armes, environnements, monstres, etc. Ces fichiers textes sont ensuite convertis en fichiers binaires lors de la compilation, pour être plus efficace au runtime.

Blacksmith, l'éditeur de niveaux
Blacksmith, l'éditeur de niveaux

Windows Phone 7 oblige, Tower of Ordal a été développé en C# avec XNA.

L'ensemble XNA Game Studio comprend le Content Pipeline, un ensemble d'outils permettant de gérer les ressources du jeu. Dans l'ensemble, c'est une super fonctionnalité, très pratique. Malheureusement, la méthode recommandée pour ajouter une ressource au projet est de le faire via l'interface de Visual Studio.

Or dans un RPG beaucoup de contenu est amené à changer régulièrement. J'ajoutais, renommais et supprimais sans cesse de nouveaux fichiers, si bien que garder le content project synchronisé dans Visual Studio aurait été un cauchemar. Du coup j'ai complètement mis le Content Pipeline de côté (à part pour les sprite fonts).

En remplacement, j'ai écrit une suite de scripts surveillant le dossier contenant les ressources pour les ajouter automatiquement au jeu. Les applications Windows Phone 7 sont distribuées sous la forme de fichier XAP, qui sont en réalité des archives ZIP renommées. En appelant le logiciel 7zip en ligne de commande et en ajoutant mes scripts aux Build Events de Visual Studio, j'ai pu remplacer complètement le Content Pipeline.

Cependant, j'en ai payé le prix. Mes scripts ne vérifiaient pas les modifications apportées aux ressources avant de les compiler et de les joindre au package. Du coup les 8Mo de ressources étaient compilées et archivées à chaque fois que je modifiais le code, même quand ça n'était pas nécessaire. La compilation devenue très lente, le cycle d'itération s'en est aussi retrouvé ralentis.

J'ai radicalement simplifié mon approche pour mes nouveaux projets. Les fichiers projets de Visual Studio n'étant que des fichiers XML, j'ai écrit un script qui injecte automatiquement les ressources au content project. Ne me demandez pas pourquoi je n'y avais pas pensé plus tôt...

La Release et le Marketplace

Tower of Ordal a finalement vu le jour sur le Windows Phone Marketplace le 5 novembre 2011, soit plus d'un an après la sortie de Reckless Squad. Au temps pour les projets plus modestes et l'itération plus courte...

Originellement, le jeu était disponible pour 1.99 USD, sans version d'essai gratuite. C'était encore une chose qui ne faisait pas partie de mes priorités durant le développement et qui n'a donc pas été implémentée. Lorsque le jeu a passé la certification de Microsoft et a été mis en ligne, j'ai posté une news sur le site de la D2P et pondu un tweet. Mon effort marketing s'arrête là.

Certes j'étais pris par le temps, mais je pense que j'étais surtout découragé par mes incessantes tentatives de joindre la presse pour Reckless Squad. Le souvenir désagréable était encore trop récent pour que je m'y replonge. Peut être aussi que j'avais moins foi dans le produit, vu que ce n'était qu'un jeu mobile. Sur Windows Phone en plus, alors que la presse est spécialisée iOS.

Quoi qu'il en soit, et même avec ce manquement de ma part, Tower of Ordal m'a agréablement surpris. Même sans version d'essai, les premiers mois qui ont suivis la sortie du titre ont écoulés presque autant de copies que Reckless Squad en un an. Pas au même prix, certes, mais ça reste encourageant. Le jeu bénéficie également de bonnes reviews, à part pour les rares personnes qui s'attendaient à trouver Legend of Grimrock au prix d'un café.

L'absence du mode d'essai gratuit étant un tort trop gros pour être ignoré, je l'ai implémenté en même temps qu'une modification permettant de quitter le jeu pendant un combat et de le reprendre au même endroit. Cependant, cette modification entrainant un changement de le système de sauvegarde, je voulais la tester de fond en comble avant de la publier. Je n'ai jamais trouvé le temps de le faire. Au final, j'ai publié la nouvelle version en juin, sans avoir fait les tests nécessaires. Heureusement, ça marchait...

Si cette version d'essai a ravivé les statistiques de téléchargement, les ventes n'ont pas augmentées. Le taux de conversion est abyssal.

Je pense que le principal problème est le Syndrome Wild-Rat, nommé en l’honneur du seul ennemi qui apparait dans le premier niveau et qui le rend répétitif et ennuyeux. C’est d’autant plus rageant qu’il y a 22 types d’ennemis, allant du gobelin au dragon, avec huit environnements uniques. Beaucoup de travail qui n'est pas apparent pour ceux qui essaient la version gratuite. J'ai essayé de mitiger ce problème en changeant les captures d'écran sur la page du Marketplace du jeu, pour dévoiler le plus d'environnements et d'ennemis possible.

Je pense que ça joue en la faveur des téléchargements, mais comme le début du jeu reste inchangé, ça n'a pas d'effet sur le taux de conversion. C'est un problème de conception qui ne disparaitra pas aussi aisément.

Je savais que le placement était important sur un store digital, mais ce n'est que quand Tower of Ordal s'est retrouvé côte à côte avec Final Fantasy que je l'ai réalisé. Pendant quelques jours, le nombre de téléchargement depuis le marketplace français a explosé. Malgré ça, le taux de conversion étant ce qu'il est, ça n'a eu que peu d'impact au final.

Bref, Tower of Ordal n'est pas un succès commercial.

Childe Dri to the Tower of Ordal came.