Ça fait un bout de temps qu’on n’a pas posté. Mais le projet est toujours actif. Il a été très ralenti, mais on est toujours là.

Clément a mis ça de côté pour l’instant. Forcement, vu qu’il est toujours en attente sur moi pour pouvoir avancer. Par contre, on partage une vision commune sur le projet et il est toujours actif dans notre cœur !

De mon côté, le projet est devenu un peu plus clair et plus important pour moi. J’ai plein d’idées et j’ai envie de construire quelque chose qui me correspond et qui puisse servir à d’autres. On en discuté plusieurs fois avec Clément et on sait déjà un peu plus où on va. Même si ça part encore un peu dans plusieurs directions.

Le projet a grossi dans notre tête. Il se divise maintenant en deux grandes parties :

• Un moteur qui permette de créer un jeu en prenant l’histoire (le scénario) comme matière première plutôt que le gameplay en lui-même. Le jeu pourra être généré dans plusieurs formats visuels et compatibles avec plusieurs types d’appareils.
• Un jeu basé sur l’histoire et les personnages de Clément. Un jeu qu’on veut bienveillant, éducatif, et fait à la main avec amour.

Je vais détailler dans les prochains articles. Mais en gros voici les nouvelles lignes directrices :

• Le jeu doit être accessible à TOUS.
• Le jeu doit être éducatif.
• Le jeu doit être compatible (même sur de très vieux appareils).
• Le jeu doit être personnalisable pour s’adapter à son joueur.
• Le jeu doit être Libre, Ouvert et gratuit.
• Le jeu doit être extensible.
• Le jeu doit être coopératif.
• Le jeu doit être crafty (IRL).

En gros le principe imaginé, c’est qu’on rédige un scénario avec une syntaxe spéciale. On rédige des éventements, des conditions, des décors, etc.. Et à partir de ça, le moteur sera capable de créer un jeu au format textuel avec des questions à choix multiple.

Ensuite, on peut ajouter un second layer d’informations sur chacun des éléments de l’histoire (des images pour les lieux et les personnages par exemple), et le moteur pourra alors générer un visual novel.

Puis un nouveau layer d’information avec des positions, des animations, des sprites, et on pourrait avoir un jeu en vue isométrique.

etc.

Et d’un autre côté, on ajoute des éléments de game play. Par exemple, un affrontement a lieu. Soit on lance un mini jeu de combat style RPG, soit une puzzle, soit une énigme. Le gameplay sera déterminé par la personnalisation du jeu. Par exemple, un joueur non-voyant ne jouera pas avec le même game play qu’un joueur mal-entendant. Mais tous deux auront accès à la même histoire, les mêmes enjeux, la même connaissance.

L’UI sera également différente d’un joueur à l’autre, mais les éléments d’interface proposés seront finalement les mêmes.

A terme, j’aimerais même que le projet puisse permettre à des spécialistes (par exemple des neuro-psychologues spécialisés dans l’autisme chez les enfants) de proposer à des enfants de jouer à un jeu qui est adapté à leur condition. Le jeu pourrait alors enregistrer quelques informations utiles comme le temps de réaction, la propension à aller à un endroit plutôt qu’à un autre, à faire un choix plutôt qu’un autre, etc.. Ces informations pourraient alors être utilisées par le spécialiste pour mesurer et analyser l’évolution de la condition de l’enfant dans le temps. C’est un domaine que je ne maîtrise pas encore du tout. J’ai juste déjà travaillé sur un petit projet dans ce genre là pour une spécialiste, et je pense (j’espère) que c’est quelque chose qui peut être approfondi et que ce projet pourrait permettre d’apporter une aide dans le diagnostique et/ou le suivi à un moment.

Voilà en gros le rêve. Pour l’instant, j’essaye de faire la toute première étape depuis quelques mois, c’est à dire proposer un jeu textuel hyper basique à partir d’une scène simple.

Dès que ça sera fait, je pourrai enfin proposer à Clément d’avancer sur quelque chose de réel.

Ensuite, on ajoutera les couches une à une (visuels, game play, etc..).

J’ai beaucoup de choses à raconter sur chacun des points ci-dessus. Alors ça va arriver dans les semaines à venir si je trouve un peu de dispo.

Les sources de ce que j’ai commencé à faire sont déjà disponible, bien que ce soit complètement inutilisable pour l’instant.

On a réussi à faire le premier niveau !

Pour commencer, on a préparé la scène dans l’ordinateur en 3D pour imaginer avant de faire au papier. On a decidé ensemble ce qu’on allait mettre dans la scène.

Ensuite Papa a dessiné la scène sur papier.

Crayonné de la maison visible dans la première scène.

Il a peint à l’aquarelle.

Aquarelle avant encrage

Pour le personnage, il a fait à l’ordinateur et tourné sous tous les angles. Il a enregistré chaque angle qu’il a repeint à l’aquarelle.

Le personnage de Stella modélisé dans Blender

La petite animation de marche (verticalement) tournée sous tous les angles (horizontalement)

Dessin de l’animation de Stella en cours…

… et le résultat

Il a repassé les traits à l’encre de chine.

Résultat final papier de la scène001

Pour finir, il a numérisé tout ça en prennant en photo des dessins et il a “nettoyé” les dessins sur l’ordinateur.

D’un autre côté, Pan, papa et moi avons travaillé et discuté sur l’histoire.

C’est super de voir que ça avance comme ça. Désolé de vous avoir fait attendre pour cet article de blog.

Les nouveaux visuels ont été placés dans la version alpha.

Essayez-la maintenant !

Beaucoup d’échanges ont été faits sur le repo du scénario. Pan a beaucoup travaillé sur les premières scènes et ça se présente très bien ! Mais comme d’habitude, vous verez ça directement dans le jeu.

Résultat de la scène001 dans le jeu

Avant de faire les nouveaux visuels, quelques petites améliorations ont été apportées sur la version alpha (déplacement et animations) :

• 05/04/2021
• 06/04/2021

Au moment où nous écrivons ces lignes, ça ressemble à ça :

• 04/04/2021

Et pour vous qui lisez ça dans le futur, ça ressemble désormais à ça :

• Aujourd’hui

Comme d’habitude, les sources sont disponibles.

J’ai continué encore un peu ces derniers jours (du coup j’arrondi à Jour 40). Je ne poste pas à chaque fois que j’avance. Mais vous pouvez suivre l’avancée plus en détail sur le repo directement.

Parmis les grosses nouveatés, la maniabilité de base s’améliore. La caméra suit maintenant le personnage, le scroll est plus clair et plus simple. Les clics sont plus faciles. Le déplacement est plus optimisé. Ca fonctionne mieux sur les devices lents.

Petite nouveauté qui m’a demandé pas mal de révision de trigonométrie, l’ombre artificielle peut maintenant suivre un point fixe. Ca sera utile pour les scènes éclairées par une lumière visible sur la scène. Exemple ici en mettant le rocher en source de lumière.

Et un petit effet parallax sur un calque est maintenant possible (exemple ici avec les roches en premier plan qui donne une petite impression de profondeur).

Si vous voulez, vous pouvez regarder l’avancement ici (à regarder sur un ordinateur) :

• 29/03/2021
• 31/03/2021

Au moment où j’écris ces lignes, ça ressemble à ça :

• 04/04/2021

Et pour vous qui lisez ça dans le futur, ça ressemble désormais à ça :

• Aujourd’hui

Comme d’habitude, les sources sont disponibles.

Et d’autre part, j’ai préparé un canvas d’écriture pour que Clément et Pan puissent travailler de leur côté sur les dialogues. J’ai documenté tout ça sur le repo du scénario. (pas de lien pour ne pas vous spoiler, mais les sources sont aussi disponibles sur le même Gitea).

A très vite pour animer ce petit bonhomme et bientôt refaire complètement le visuel pour quelque chose de plus joli et plus définitif.

Pfiou ! Alors, j’ai beaucoup avancé ces trois derniers jours (c’est pour ça que le compteur est passé de 35 à 38 d’un seul coup). J’ai commencé à développer un moteur graphique avec Three.js. Ca ne va pas se voir du tout, mais c’est un énorme bon en avant pour moi.

Grosso modo, j’ai repris mes images de la dernière fois, sauf que cette fois-ci je ne les ai pas seulement superposées, je les ai intégrées à un monde en 3D pour pouvoir faire beaucoup plus de choses avec.

C’est plus complexe que ce que je n’imaginais, mais ça commence à fonctionner.

Mes principaux objectifs sont :

• avoir un jeu compatible et fluide sur le plus grand nombre de devices
• pouvoir utiliser des calques pré-calculés pour nous laisser un maximum de créativité (on pourrait même jouer dans des dessins par exemple)
• ajouter une couche d’effets de lumière pour rendre les images plus vivantes (une frame qui danse, un éclair de magie, une lampe torche, etc)
• avoir de vraies ombres portées

… Et figurez-vous que j’ai réussi à remplir trois de ces quatres objectifs (le jeu rame encore pas mal sur Firefox, et j’ai des bugs sur mobile, mais ce sont des petites choses, il faut juste que je me penche dessus).

Voici ce que ça donne :

Et vous me direz : “quoi ? Tout ça pour ça ? C’est la même chose que la dernière fois ! Y a juste un truc bleu en plus.”

Oui, et non. Les images utilisées sont les mêmes, mais tout a changé. Et ça m’offre beaucoup plus de possibilités. Les effets proposés ici ne sont que des tests. Rien ne sera comme ça dans le jeu. C’est juste que maintenant, j’ai la possibilité de créer des effets de lumières facilement. Je sais comment faire !

Pour ces effets, j’ai créé plusieurs scènes 3D que j’affiche par dessus mon image. Ces scènes contiennent des boites qui permettent de simuler la présences de mes objets 2D (comme les rochers par exemple) dans l’environnement 3D afin de projeter des ombres.

Une petite lumière simple qui suit la souris et qui ne s’applique qu’au sol. Elle projette une ombre avec mes faux rochers (qui sont en fait deux cubes dans le monde en 3D

Une fois mélangé à l’image (en color-dodge), ça donne ça

Un flash pour tester une lumière plus forte et animée. Elle est de moins bonne qualité pour de meilleures performances, mais ça ne se voit pas au résultat final.

… et un splash de lumière qui apparait par dessus l’ensemble de l’image. Pour simuler un bloom et l’éclarage des objets aux alentours

… En exagérant le flash bleu, ça donne ça. Il ne reste plus qu’à corriger le fait que la lumière au sol dépasse par dessus les rochers.

… Je rajoute donc simpement mon roche par dessus l’effet, and voilà, le roche devient légèrement bleue grâce au bloom. La lumière au sol passe bien derrière. Et j’ai bien mon ombre portée.

La partie qui m’embête le plus pour l’instant, c’est l’ombre ronde sous le personnage. Je ne trouve pas de moyen de la flouter pour qu’elle semble un peu plus réaliste tout en étant compatible avec mon système de calque pour la key light et la fill light. Et en plus c’est assez gourmand en ressources. J’espère que je vais trouver une solution.

Et petite cerise sur le gâteau, l’ensemble est devenu interactif grâce à une vraie grille et un système qui est compatible avec le tactil (zoom à deux doigts, etc). La grille est dans un calque à part posé par dessus mon image mais invisible. Comme ça on peut cliquer sur des objets ou sur une case même quand un arbre est devant par exemple.

Si vous voulez, vous pouvez regarder l’avancement ici (à regarder sur un ordinateur) :

• 24/03/2021
• 26/03/2021
• 27/03/2021

Au moment où j’écris ces lignes, ça ressemble à ça :

• 28/03/2021

Et pour vous qui lisez ça dans le futur, ça ressemble désormais à ça :

• Aujourd’hui

Comme d’habitude, les sources sont disponibles.

En fait on réfléchit à la meilleure méthode pour faire recommencer le joueur en cas d’échec.

Plusieurs méthodes s’offrent à nous :

Pas de sauvegarde

Si on meurt, on reprend du début. C’est punitif, mais ça rend le jeu plus gratifiant quand on réussi. C’est hyper engageant. Dans ces conditions, quand on est en combat, on n’a pas du tout (du tout du tout) envie de perdre.

Cette possibilité n’est pas encore totalement écartée. Surtout qu’une solution pour zapper les conversations et zones d’énigmes est en cours d’élaboration.

Nombre de chances

Si on meurt, on reprend du dernier checkpoint. Mais si on meurt 3 fois par exemple, on perd définitivement et on doit recommencer du tout début.

Retour dans le temps

On peut trouver une raison narrative pour justifier un retour au début (voyage dans le temps, souvenir vécu en boucle, boucle temporelle, etc.). Le joueur revient au début du niveau, mais le personnage aussi. Il peut alors conserver et ramener avec lui au début du niveau des connaissances et compétences.

Dans ce cas, en général, la sauvegarde est automatique. Le joueur reprend une partie exactement là où il s’est arrêté. S’il meurt, sa mort est sauvegardée et il reprend plus tôt.

C’est un peu le principe des Rogue-like. C’est souvent utilisé pour les jeux à petits budget parce que ça permet de réutiliser des dizaine, voir des centaines de fois, une grande partie des décors de façon justifiée par l’histoire.

Mais bon voilà.. on en a vu partout des jeux de type Groundhog Day. Et même si j’adore. Je n’ai pas envie d’ajouter une pierre sur un tas déjà énorme et déjà trop vu.

De plus, notre histoire ne s’y prête pas.

Sauvegarde classique

C’est classique et ça fonctionne. C’est juste que je n’aime pas trop l’idée de ne pas justifier scénaristiquement le retour au début du niveau. C’est vraiment uniquement un élément de game-play qui est complètement détaché de l’histoire. On meurt, on recommence, c’est comme ça, c’est le jeu.

Sauvegarde libre

On laisse le joueur sauvegarder quand il veut et charger quand il veut. S’il meurt, s’il pense qu’il a fait un mauvais choix, ou simplement qu’il veut revoir une partie du jeu qu’il aime bien, alors libre à lui de reprendre sa dernière sauvegarde. Il peut copier ses sauvegardes, et même les partager.

C’est bien parce que :

• C’est un système compréhensible et lisible. Utilisé pour presque tout dans l’informatique. La sauvegarde est un fichier. Si on ne sauvegarde pas, on risque de perdre l’avancée effectuée. C’est valable partout.
• Ça permet de garder plusieurs sauvegardes pour une même partie et de reprendre à un point donné en cas de souci. Ou juste pour le plaisir de rejouer une une section qui nous plaît. Ou encore de tenter plusieurs solutions pour un même problème et de garder la solution la plus efficace.
• Ça permet de partager des sauvegardes avec des amis

C’est moins bien parce que :

• Ça rend le jeu trop facile. Trop exploitable. Il suffit de sauvegarder à tout bout de champs pour devenir immortel et recommencer quelques minutes, voir quelques secondes, avant un passage compliqué. Plus le jeu est facile, et moins il est engageant.
• Si le joueur ne pense pas à sauvegarder, il peut repartir de très loin et être découragé.

Sauvegarde libre et automatique

En gros, c’est la même chose, sauf que toutes les X minutes ou bien à chaque passage important (checkpoint), on créé une “sauvegarde automatique”.

C’est bien parce que :

• On est sûr de reprendre pas trop loin en cas d’échec. Sans avoir à penser à ça.

C’est moins bien parce que :

• Ça rend le jeu encore plus facile. Ou alors, il faut que les sauvegardes automatiques ne soient pas trop rapprochées.

Sauvegarde automatique uniquement

Un système de checkpoint uniquement. (C’est la méthode privilégiée pour l’instant).

C’est bien parce que :

• On est sûr de ne pas reprendre trop loin en cas d’échec. Sans avoir à penser à ça.
• C’est nous, développeurs, qui décidons où le joueur reprend. Et on peut donc rendre une section plus ou moins difficile en espaçant plus ou moins les points de sauvegarde.
• On peut facilement retirer certains checkpoint pour créer un mode “difficile”

On va sans doute conserver des informations acquises même quand le joueur meurt. Par exemple, si le joueur découvre une information sur un monstre, cette info s’ajoute à son codex. Si le joueur meurt et qu’il reprend avant d’avoir rencontré pour la première fois ce monstre, alors, l’info reste malgré tout dans son codex. Ça lui évitera de devoir refaire toutes les conversations avec les NPC en autres en cas d’échec.

Quoi de plus barbant que de devoir relire des conversations qu’on a déjà lues.

Alors voilà. Pour l’instant, on reste sur checkpoints posés à des endroits stratégiques plus ou moins espacés selon la difficulté avec conservation du codex en cas d’échec.

A voir ce que ça donne à l’utilisation.

Sans commentaire particulier. Ca avance doucement.

J’ai décidé de changer un peu de stratégie. Je pense que pour rendre le projet plus concret, on a déjà besoin d’une version alpha du game play et du design. Ça donnera quelque chose de concret pour imaginer le résultat final. Ça sera plus motivant pour nous deux, mais aussi plus engageant pour vous, fidèles lecteurs (je ne suis pas sûr de devoir mettre lecteurs au pluriel lol. Mais allez, soyons fous !)

Je parle donc de générer à la main (rien de procédural ni d’automatisé) :

• Un niveau (sans doute en forêt)
  • une grille de déplacement
  • un layer pour le sol éclairé
  • un layer pour le sol à l’ombre
  • un layer pour les objets sur le sol (herbe, rochers, arbres, etc.)
  • un layer pour les objets en hauteur (oiseaux, abres premier plan, etc.)
• Un personnage (que je multiplie par 4 en changeant simplement sa couleur)
  • Une animation de stand by sous 4 angles
  • Une animation de marche sous 4 angles
  • Une animation d’attaque sous 4 angles
  • Une attaque simple
• Un mini jeu de timing pour la force de l’attaque
• Un mini jeu de précision pour l’esquive
• Un timer pour le tour
• Une mise en valeur de personnage pour indiquer quand c’est notre tour
• Un monstre (que je place une dizaine de fois dans le niveau)
  • monstre simple qui vole et visible sous un seul angle
  • une image fixe pour quand il se déplace
  • une image fixe pour quand il attaque
  • une image fixe pour quand il prend des dégâts
  • une image fixe pour quand il meurt.
• Une conversation avant combat entre deux personnages
• Une conversation après combat qui se déclenche quand on sort de la zone
• Effet de feu
• Effet d’ombre et de lumière (chers à mon cœur)

Ça sera déjà beaucoup de boulot !

J’ai potassé un peu la partie graphique pour avoir une idée plus précise de là où je vais. J’avais commencé à réaliser quelque chose de simple en css/js. Mais je me rend compte que c’est trop limité et pas assez performant. J’ai besoin d’être sûr d’avoir un résultat visuel sympa tout en ayant un jeu fluide. Si je veux que le jeu puisse supporter à long terme des effets visuels (particules, ombres, reflets, etc.), je dois partir dès maintenant sur le bon système de rendu.

Pour l’instant, je me suis fixé sur Three.js. Il semble pouvoir faire tout ce dont j’ai besoin et même bien plus. Il sera même envisageable du coup d’intégrer des éléments 3D dans les plans 2D. Ça ouvre beaucoup de possibles. Je vais continuer de réfléchir à tout ça.

Une des réflexions que j’ai eu pendant ces longues semaines de silence et celle du game-play général. Ces temps-ci avec Clément on joue à Hades (que je vous recommande très très chaudement). C’est un rogue-like très bien fait. Très nerveux ! Plus j’y joue, et plus je me dis qu’il me sera très difficile voir impossible de réaliser un game play en temps réel fluide et maniable par moi-même.

Du coup, je me dis que le turn-based peut être la solution qui répondra à plusieurs problématiques :

• C’est plus simple à programmer d’un point de vue navigation : Il n’est pas question de zone de collision, de vitesse, du gestion du temps et du lag, gestion de la vitesse en fonction de l’angle du mouvement, etc..
• C’est plus simple à gérer d’un point de vue combat (surtout qu’on gère jusqu’à 4 personnages en même temps)
• C’est plus simple à gérer d’un point de vue multi player (cette option est toujours envisagée, en contrôlant 1 à 2 personnages chacun)
• C’est plus simple de programmer une IA qui ne doit pas s’adapter en fonction de plein d’événements qui peuvent se produire en même temps.
• Ca demande moins de ressource processeur pour le joueur (le jeu est jouable sur des plus petits devices)
• Ca demande moins de ressource Internet pour jouer en ligne à plusieurs (un lag voir une déco complète n’est pas du tout problématique dans la mesure où ça temporise simplement le tour en cours. Ca n’empêche même pas les autres de jouer ou regarder ce qu’il se passe en attendant)

En gros, il s’agit de mettre une grille par terre, et de dire au joueur où il peut aller (en fonction de la distance maximum parcourue par tour de son personnage), et sur qui il peut taper. Je pense que je suis capable de programmer ça.

Dans le cadre des scènes hors combat, ça ne change rien (à part qu’on est limité à une grille au sol). Dans le cadre des combats, ça permet de mieux contrôler ce qu’on fait. On prend le temps de choisir les attaques adaptées.

Le problème majeur, c’est que retire une notion d’agilité, de stress que je trouve inintéressante à avoir. Une notion d’urgence. Il peut alors être question de simplement ajouter un timer pour chaque tour (par exemple, on a seulement 5s pour choisir quoi faire, sinon on loupe son tour et l’ennemi peut alors faire deux actions).

Et un problème annexe, c’est qu’en multiplayer, on passe beaucoup de temps à attendre l’autre joueur.

Deux modèles de Turn Based

En ce qui concerne le game-play, j’hésite entre deux modèles :

Le plus naturel, serait que l’UI nous indique quand c’est notre tour et mettant en valeur notre personnage et qu’on puisse se déplacer et/ou attaquer. Au moment où on attaque, qu’on est allé aussi loin qu’on peut aller, ou que le timer est à zéro, alors c’est le tour de l’ennemi. C’est un format agréable je pense si on a un seul personnage à jouer. Mais si on a 4 personnage à jouer, ça veut dire qu’on passe notre temps à déplacer les personnages un par un chacun leur tour. Je ne sais pas à quel point ça peut être un peu longuet à force. Si les 4 personnages sont assez diversifiés et que certain peuvent commencer à attaquer à distance pendant que d’autres se déplacent, ça peut le faire. Dans ce cas, chaque personnage a droit à son tour (idem pour les ennemis du coup)

Le moins naturel (selon moi), c’est le format classique RPG-strategy : Quand c’est notre tour, on déplace tous nos personnages, on les envois attaquer, on peut même leur donner des missions sur plusieurs tours (par exemple un long déplacement), on peut annuler nos actions, et dès qu’on est ok avec ce qu’on a fait, on valide la fin du tour, et c’est alors à l’ennemi de jouer. Dans ce cas, chaque équipe a droit à son tour (le(s) joueur(s) contre les ennemis)

Dans le cadre d’un jeu multiplayer, ce dernier modèle convient tout à fait. Par exemple, si on joue à deux, on peut s’attribuer 2 personnages chacun et jouer avec nos deux persos comme deux petites armées à gérer chacun de son côté. Mais on doit patienter. Beaucoup patienter. Pire encore si on est 4.

Que choisir ?

Mais je me demande si un modèle plus collaboratif peut fonctionner. Un genre de mix entre les deux. Un format dans lequel :

• le tour est lié à l’équipe et non pas au personnage.
• Quand c’est notre tour, on est invité à se déplacer/attaquer avec chaque personnage individuellement chacun leur tour dans un délai court. Chaque joueur peut donc jouer en même temps dans la mesure où chaque joueur est associés avec 1 ou 2 personnages.
• Quand le(s) joueur(s) ont terminé, le tour est automatiquement clôturé et c’est au tour de l’ennemi d’agir (et ça va très vite pour l’ennemi car sa réponse est instantanée)

Et quand il n’y a plus d’ennemi, alors on repasse dans un mode semi-temps réel, dans lequel chaque joueur peut switcher de personnage (s’il gère plusieurs personnages). Quand il n’y a pas d’ennemi, un lag n’a pas d’incidence sur le jeu et peut donc être ignoré).

Conclusion

Mode libre

Il y aurait donc le mode Libre (pas de combat) dans lequel on clique sur le personnage qu’on veut contrôler. Une fois qu’il est activé, on a juste à cliquer là où on veut pour qu’il y aille. Dans le cas d’une manette, il s’agit de faire quelque chose du genre L1/R1 pour switcher parmi les personnages et ensuite de naviguer simplement avec le joystick.

Le fonctionnement serait identique en multijoueur avec une latence acceptable qui peut être ignorée et qui ne sera pas perceptible par le joueur.

Mode combat

Et il y aurait le mode Combat dans lequel le joueur actif nous est imposé, on a quelques secondes pour faire une action avec le personnage, jusqu’à ce que les 4 personnages aient fait une action. Ensuite on regarde l’ennemi bouger ses troupes en réaction à ce qu’on vient de faire.

En multijoueur, ça fonctionne exactement pareil sauf qu’on est invité à ne choisir les actions que du(des) personnage(s) qui nous est(sont) attribué(s). Le tour est donc plus court, mais se passe de la même façon. Et là, il n’est pas question de lag. Quand les deux joueurs ont choisis leurs actions, on attend simplement que l’info soit passée de l’un vers l’autre, et c’est seulement à ce moment là que le tour de l’ennemi commence. Il peut donc arriver qu’il y ait quelques secondes d’attente à la fin de notre tour. Mais ça pourra être déguisé en quelque chose du genre “L’ennemi se prépare à réagir !” ou bien plus sincèrement un message du genre “En attente des autres joueurs”.

Avec ce fonctionnement, on garde l’urgence et le stress. La musique pourra faire son effet et changer en fonction des passages (notre tour, pas notre tour, plein de vie, pas de vie, etc..)

En bonus

Pour pimenter le tout, j’aimerais que le jeu ne soit pas basé uniquement sur la stratégie, mais aussi beaucoup sur l’agilité. En tour par tour, il n’est évidement pas question de ça. Alors je pense qu’en plus de mettre en place un timer, je vais mettre des mini jeux d’agilité qui permettront de définir la performances des attaques ou de donner une chance de faire une esquive par exemple. Des jeux aussi simple que de presser un bouton au bon moment (en fonction d’un timing ou d’un réflexe), mais aussi des combinaisons ou séquences de boutons/touches à faire dans un temps imparti. Je pense que ça permettrait vraiment d’avoir un gameplay qui ressemble à du temps réél, sans en être un.

N’oublions pas que nous sommes surtout là pour raconter une histoire. Mais je tiens à ce que le joueur soit imprégnié de l’histoire par ces séquences de jeu plus ou moins difficiles qui feront vraiment appel à son attention. Et d’un point de vue multiplayer, la collaboration sera du coup très importante et aidera aussi à se plonger dans le jeu.

A réflechir encore un peu, mais je pense que c’est une bonne piste.

Bon.

On a bien du mal à s’y mettre. La vie est très chargée ces temps-ci. Mais le projet est toujours bien présent dans nos têtes. J’y pense tous les jours, j’ai noté plein d’idées.

Je continue de réfléchir la structure générale pour qu’elle puisse vivre après moi. Je cherche surtout à faire quelque chose qui soit utilisable pour d’autres projets. Quelque chose d’extensible et personnalisable. La base doit être commune et basique, afin qu’on puisse y greffer des petites extensions qui correspondent à des petits besoins.

J’ai tout ça bien en tête. Maintenant, j’ai juste besoin d’avoir quelques semaines devant moi pour travailler là-dessus à plein temps. Autant dire que ce n’est pas pour tout de suite. Mais j’y crois !

En plus j’ai plein d’idées pour d’autres jeux qui pourront utiliser le même moteur. Alors j’ai bon espoir de le rentabiliser. Il faut juste que j’arrive à m’y mettre.

Je suis ravi de voir que Clément continue d’avoir un peu de motivation pour ce projet.

Clément a dessiné quelques croquis de Stella, son équipement. Ainsi que de nouveaux enemis et la princesse.