Salutations!
Profitant des ponts de la semaine, j'ai rebooté le jeu Variispace.
Back-office (créateurs)
Je laisse tomber l'idée de faire un jeu complet fonctionnel d'un coup, et de le skinner plus tard (comme je l'ai tenté dans le premier lancement de projet).
Je me tourne plutôt vers le même cycle de développement que Eclerd v0:
• Prendre une vingtaine de minutes et un papier pour définir un composant du jeu, dans son intégralité: fonctionnement, apparence de base, intégration à l'existant. Cela permet d'avoir un but à atteindre quand on attaquera le code
• Prendre 10 minutes de plus pour imaginer ce que sera la suite du jeu et les éventuels impacts de ce composant sur les autres composants qui n'existent pas encore (= j'ai définit le composant "concevoir son vaisseau spatial", et je prends ces 10 minutes pour imaginer comment on construira réellement les vaisseaux, mais sans rien noter). Cela motive pour voir plus loin que le bout de son nez
• Attaquer l'implémentation du composant en question, de manière "finale": code propre, composant optimisé (en gros) et esthétisme proche d'une version "finale". Cela permet de solidifier l'état du jeu pour que le prochain composant parte sur des bases propres et stables.
• Au fil de l'eau, quand le besoin se fait sentir, reskiner ou retravailler un peu certains éléments
Ca m'a l'air de plutôt bien marcher jusqu'ici, puisque j'ai maintenant une carte spatiale, dynamique, avec des objets célestes composés de matière (qui constituera la ressource du jeu), et un début de process d'inscription.
Architecture de page web
Aaaaah c'est là où j'ai perdu du temps hésité un moment! Initialement, je comptais décomposer la plupart de mes parts en "modules élémentaires" (iframes) et les faire communiquer entre eux. Par exemple, un module "carte" permet de se déplacer dans l'espace. Quand on change d'emplacement, le module "informations" se met à jour pour montrer les données de l'étoile/planète/autre sur laquelle on est. Mais finalement, c'est hyper-lourd à gérer tant côté serveur que client, c'est pas très fiable (glitches entre les chargements) et c'est très mal extensible (dur de changer un bout de navigation dans le mic-mac ainsi créé).
Du coup, je change d'idée et je part bêtement sur du classique "multi-page": 1 page = 1 ensemble de données unique, avec un template récurrent d'une page à l'autre. Au besoin, s'il faut faire des "sous-éléments" (= des popups) j'aviserai (window.open ou iframe dans la page). Ca peut sembler bête, mais cela m'a bouffé 1 journée entière (plein temps!) à hésiter entre 3-4 méthodes différentes avant de retomber sur celle là (cool de voir que, étant la plus basique, standard et préférée depuis des années, je finis par revenir dessus même après avoir essayé des alternatives).
Front (joueurs)
Pour ce qui est du front, je ne change pas le principe du jeu: le joueur est à la tête d'une flotte de vaisseaux spatiaux qu'il a lui-même conçu. Il va donc designer ses propres vaisseaux spatiaux, puis les construire en orbite autour d'un objet céleste (planète, lune, astéroïde, mais aussi étoile ou trou noir!).
![[Image: 5.png]](https://xenos.reinom.com/jeuweb/variispace/5.png)
La carte spatiale, accessible sans inscription, permet de visualiser ces objets céleste (ici, une étoile). On peut alors avoir accès aux informations comme sa masse ou sa zone d'influence gravitationnelle: un objet céleste ne peut orbiter autour de l'étoile actuellement visible que si cet objet céleste se trouve entre la limite de Roche et le rayon de Hill. en deçà (trop près), l'objet céleste s'écrase sur l'étoile (et leurs compositions s'additionneront). Au delà, l'objet céleste sera éjecté du système et partira dans l'espace (en pratique, il sera considéré comme "orbitant autour du même objet céleste [ici: trou noir "BH"] que l'étoile").
![[Image: 1.png]](https://xenos.reinom.com/jeuweb/variispace/1.png)
![[Image: 2.png]](https://xenos.reinom.com/jeuweb/variispace/2.png)
La carte est dynamique: ici, on observe une Lune dont l'un des satellite (un astéroïde) a bougé. Les deux screens sont espacés (en gros) d'une minute. Bien sûr, plus un astéroïde orbite près d'une Lune, plus il tourne vite (de même avec une planète autour d'une étoile, une étoile autour d'un trou noir, etc). L'intérêt pour le gameplay? La distance entre les objets célestes varie au fil du temps! Il sera donc possible d'aller s'installer sur une planète quand elle nous est proche, d'y rester pour l'exploiter, puis d'en partir quand cette planète se sera rapprochée d'une autre planète intéressante (vive les "sauts de puce"!)
Inscription
Pour ce jeu, j'aimerai éviter la barrière de l'inscription: j'ai donc un mode "spectateur" dans lequel on peut se balader dans le jeu sans être connecté ni rien. Mais pour jouer (concevoir et assembler ses vaisseaux, exploiter les étoiles, etc), il faut s'inscrire. J'ai donc essayé de rendre cela le plus "progressif" possible.
![[Image: 3.png]](https://xenos.reinom.com/jeuweb/variispace/3.png)
D'abord, un petit choix sur le type d'objet céleste sur lequel on veut démarrer. Cela me semble pertinent car je peux alors exposer au joueur la différence entre ces objets célestes (assez simple à comprendre, mais intéressante à souligner) et quelles sont les propriétés de chacun.
J'ai essayé d'utiliser des termes parlants pour les boutons d'action, en bas de chaque possibilité de choix.
![[Image: 4.jpg]](https://xenos.reinom.com/jeuweb/variispace/4.jpg)
Une fois l'objet céleste de départ choisi, le joueur devra concevoir son premier vaisseau spatial (j'en suis là). Le principe sera de lui présenter à peu près la même vue que celle in-game, avec simplement moins d'options car moins de modules (moins de "morceaux de vaisseaux à assembler") qu'un joueur déjà en jeu depuis longtemps. Je tâcherai de rendre cette conception progressive.
Voilà pour cette nouvelle mouture! Vos avis? Cette présentation est-elle compréhensible pour les joueurs? Est-ce que l'effet "progressif" de l'inscription vous semble bon?
Profitant des ponts de la semaine, j'ai rebooté le jeu Variispace.
Back-office (créateurs)
Je laisse tomber l'idée de faire un jeu complet fonctionnel d'un coup, et de le skinner plus tard (comme je l'ai tenté dans le premier lancement de projet).
Je me tourne plutôt vers le même cycle de développement que Eclerd v0:
• Prendre une vingtaine de minutes et un papier pour définir un composant du jeu, dans son intégralité: fonctionnement, apparence de base, intégration à l'existant. Cela permet d'avoir un but à atteindre quand on attaquera le code
• Prendre 10 minutes de plus pour imaginer ce que sera la suite du jeu et les éventuels impacts de ce composant sur les autres composants qui n'existent pas encore (= j'ai définit le composant "concevoir son vaisseau spatial", et je prends ces 10 minutes pour imaginer comment on construira réellement les vaisseaux, mais sans rien noter). Cela motive pour voir plus loin que le bout de son nez
• Attaquer l'implémentation du composant en question, de manière "finale": code propre, composant optimisé (en gros) et esthétisme proche d'une version "finale". Cela permet de solidifier l'état du jeu pour que le prochain composant parte sur des bases propres et stables.
• Au fil de l'eau, quand le besoin se fait sentir, reskiner ou retravailler un peu certains éléments
Ca m'a l'air de plutôt bien marcher jusqu'ici, puisque j'ai maintenant une carte spatiale, dynamique, avec des objets célestes composés de matière (qui constituera la ressource du jeu), et un début de process d'inscription.
Architecture de page web
Aaaaah c'est là où j'ai perdu du temps hésité un moment! Initialement, je comptais décomposer la plupart de mes parts en "modules élémentaires" (iframes) et les faire communiquer entre eux. Par exemple, un module "carte" permet de se déplacer dans l'espace. Quand on change d'emplacement, le module "informations" se met à jour pour montrer les données de l'étoile/planète/autre sur laquelle on est. Mais finalement, c'est hyper-lourd à gérer tant côté serveur que client, c'est pas très fiable (glitches entre les chargements) et c'est très mal extensible (dur de changer un bout de navigation dans le mic-mac ainsi créé).
Du coup, je change d'idée et je part bêtement sur du classique "multi-page": 1 page = 1 ensemble de données unique, avec un template récurrent d'une page à l'autre. Au besoin, s'il faut faire des "sous-éléments" (= des popups) j'aviserai (window.open ou iframe dans la page). Ca peut sembler bête, mais cela m'a bouffé 1 journée entière (plein temps!) à hésiter entre 3-4 méthodes différentes avant de retomber sur celle là (cool de voir que, étant la plus basique, standard et préférée depuis des années, je finis par revenir dessus même après avoir essayé des alternatives).
Front (joueurs)
Pour ce qui est du front, je ne change pas le principe du jeu: le joueur est à la tête d'une flotte de vaisseaux spatiaux qu'il a lui-même conçu. Il va donc designer ses propres vaisseaux spatiaux, puis les construire en orbite autour d'un objet céleste (planète, lune, astéroïde, mais aussi étoile ou trou noir!).
La carte spatiale, accessible sans inscription, permet de visualiser ces objets céleste (ici, une étoile). On peut alors avoir accès aux informations comme sa masse ou sa zone d'influence gravitationnelle: un objet céleste ne peut orbiter autour de l'étoile actuellement visible que si cet objet céleste se trouve entre la limite de Roche et le rayon de Hill. en deçà (trop près), l'objet céleste s'écrase sur l'étoile (et leurs compositions s'additionneront). Au delà, l'objet céleste sera éjecté du système et partira dans l'espace (en pratique, il sera considéré comme "orbitant autour du même objet céleste [ici: trou noir "BH"] que l'étoile").
La carte est dynamique: ici, on observe une Lune dont l'un des satellite (un astéroïde) a bougé. Les deux screens sont espacés (en gros) d'une minute. Bien sûr, plus un astéroïde orbite près d'une Lune, plus il tourne vite (de même avec une planète autour d'une étoile, une étoile autour d'un trou noir, etc). L'intérêt pour le gameplay? La distance entre les objets célestes varie au fil du temps! Il sera donc possible d'aller s'installer sur une planète quand elle nous est proche, d'y rester pour l'exploiter, puis d'en partir quand cette planète se sera rapprochée d'une autre planète intéressante (vive les "sauts de puce"!)
Inscription
Pour ce jeu, j'aimerai éviter la barrière de l'inscription: j'ai donc un mode "spectateur" dans lequel on peut se balader dans le jeu sans être connecté ni rien. Mais pour jouer (concevoir et assembler ses vaisseaux, exploiter les étoiles, etc), il faut s'inscrire. J'ai donc essayé de rendre cela le plus "progressif" possible.
D'abord, un petit choix sur le type d'objet céleste sur lequel on veut démarrer. Cela me semble pertinent car je peux alors exposer au joueur la différence entre ces objets célestes (assez simple à comprendre, mais intéressante à souligner) et quelles sont les propriétés de chacun.
J'ai essayé d'utiliser des termes parlants pour les boutons d'action, en bas de chaque possibilité de choix.
Une fois l'objet céleste de départ choisi, le joueur devra concevoir son premier vaisseau spatial (j'en suis là). Le principe sera de lui présenter à peu près la même vue que celle in-game, avec simplement moins d'options car moins de modules (moins de "morceaux de vaisseaux à assembler") qu'un joueur déjà en jeu depuis longtemps. Je tâcherai de rendre cette conception progressive.
Voilà pour cette nouvelle mouture! Vos avis? Cette présentation est-elle compréhensible pour les joueurs? Est-ce que l'effet "progressif" de l'inscription vous semble bon?