VariiSpace [Reboot]
#11
C'est enfin jouable ! 1 ?
"Somewhere, something incredible is waiting to be known..."
Carl Sagan.
Répondre
#12
C'est enfin existant (de là à dire qu'il y a assez de matière pour jouer... 34)
Répondre
#13
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]

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]

[Image: 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]

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]

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?
Répondre
#14
Cool !

Quelle échelle de temps pour les sauts-de-puce par rapport au temps réel ?

Pour l'inscription, ce que je fait dans mes projets c'est que je présente un bouton [Login] et un bouton [Jouer sans inscription], et ce dernier crée un compte automatique et anonyme. Ensuite tu peux supprimer ces comptes automatiques par la suite. ça t'évite de devoir gérer des users inscrits et d'autres non dans tes pages progressives.
Répondre
#15
Dans le cas présent, je serai contre les comptes anonymes car le problème n'est pas tant l'inscription en elle-même que le process de démarrage dans le jeu. En d'autres mots, le but du progressif n'est pas directement "d'éviter" l'inscription, mais surtout de permettre une plongée dans le jeu qui ne soit pas brutale (larguer les joueurs avec un compte anonyme au milieu de l'espace, je pense que cela les fera fuir).
Mais je garde l'idée pour d'éventuels autres projets 16

Pour l'échelle de temps, tout dépend de l'objet céleste (on va dire "le parent") autour duquel l'objet céleste (on va dire "l'enfant") orbite: plus le parent est massif, plus l'enfant met de temps (réel) à en faire le tour. Donc, une étoile fait un tour de galaxie en 7 (pour les plus aux centre) à 180 jours (pour les plus lointaines), une planète fait le tour de son étoile en 1 à 15j (en gros) et une Lune fait le tour de sa planète dans la journée. Une astéroïde fait le tour de la Lune en moins d'une heure. Cela reste des ordres de grandeur.
L'intérêt est d'avoir des échelles différentes: si j'ai une petite flotte, je veux un jeu réactif, donc les astéroïdes autour desquels j'orbite sont rapides. Et pour les grosses flottes de vieux joueurs (qui ne veulent pas tout perdre en 5 minute), les étoiles sont plus lentes (mais, vu qu'elles parcourent plus de distance, le "saut de puce" devient d'autant plus intéressant et stratégique).
Répondre




Utilisateur(s) parcourant ce sujet : 1 visiteur(s)