VariiSpace [Reboot]
#21
Salutations!

Wow, je ne pensais pas avoir laissé autant de temps s'écouler depuis les dernières infos du jeu sur ce forum 2

Quoi de neuf alors? Eh bien, dans les grandes lignes:

- Les vaisseaux sont constructibles depuis quelques temps, mais également déplaçables!
Rappel: Ils orbitent autour d'un objet céleste (disons, une planète), et peuvent passer d'une orbite à l'autre. Plus on est près de l'OC, plus on accumule des Chronotons rapidement ("Points d'Action") mais moins on peut stocker de chronotons (les joueurs les plus actifs quotidiennement ou plus seront donc au près de l'OC pour maximiser leurs gains de PA, sans être plafonnés par leur faible stockage)
Le déplacement en plus leur permet de passer d'un OC à l'autre, à condition de partir de l'orbite la plus éloignée de l'OC de départ, et d'arriver sur l'orbite la plus éloignée de l'OC ciblé. Cela permettra de faire un système de "blocus" d'OC, en squattant l'orbite la plus éloignée. Ce genre de stratégie pourra permettre d'assiéger un ennemi, jusqu'à ce qu'il n'ait plus de munitions par exemple (ou que des renforts arrivent pour l'attaquer)

- Les atomes doivent être maintenant "débloqués" pour être utilisés dans une molécule, pour être extraits, échangés, etc. Cela évitera que les nouveaux arrivants ne se coincent trop facilement en extrayant les mauvaises ressources, ou qu'ils ne se perdent dans le nombre impressionnant de ressources du jeu (vu qu'il y a une centaine d'atomes différents, il y a donc une centaine de ressources!)

- La recherche est en place, mais le contenu manque: j'ai implémenté les pages pour la recherche, mais il reste encore à définir quelles recherches proposer aux joueurs, et quels sont leurs effets. Le système d'avancement de la recherche est calqué sur l'une des propositions de Ter Rowan (similaire aux points de compétences des JDR): on a un système de points de recherches (similaire aux XP des JDR) qui, quand on en a une certaine quantité, débloque un "niveau de recherche". Le niveau suivant sera plus coûteux. Ensuite, chacun de ces niveaux de recherche permet d'avancer 1 des recherches de 1 niveau, donnant ainsi un bonus ou débloquant de nouveaux éléments. Plutôt classique, mais efficace.
Par exemple, le joueur démarrera toujours avec 1 niveau de recherche cadeau. Il n'aura, au début, qu'une seule recherche possible: la... recherche! Initialement, niveau "0". Une fois celle-ci niveau 1 (donc, le joueur a compris comment dépenser son niveau de recherche), le module "recherche scientifique" est débloqué, et pourra être rajouté à un plan de vaisseau pour faire un vaisseau capable de générer des points de recherche et de faire avancer la recherche du joueur.

- Je compte enfin mettre en place un mécanisme permettant, en apparence, de "jouer" sans être inscrit. L'idée est de supprimer les pages d'inscriptions, processus lourd et dédié qui n'est plus jamais rencontré par le joueur (donc très peu rentable en terme de travail/utilité) et de les remplacer par... rien! Le visiteur non inscrit aurait alors en fait accès à toutes les pages auxquelles un nouveau joueur (qui n'a pas encore fait d'action de jeu) aurait accès. Il aurait donc la carte galactique, mais aussi la page de ses flottes (vide), de ses plans de vaisseaux (vide), de ses matériaux (vide), de la recherche (avec le niveau-cadeau), la liste des atomes débloqués (aucun jusqu'ici, mais il pourra lire les propriétés de chaque atome et comprendre qu'ils pourra les débloquer), etc.
L'intérêt est multiple: moins de code (puisque pas besoin de pages d'inscription dédiées), plus de transparence (le joueur sait à quoi ressemble le jeu avant de s'inscrire puisqu'il est déjà dans le jeu), plus de conversions et d'inscription (j'espère; parce que le joueur commencera à jouer avant de s'inscrire, faisant tomber la barrière à l'entrée de l'inscription et le poussant à s'inscrire pour ne pas perdre ce qu'il a déjà joué en tant que visiteur), plus besoin de screens de présentations (qui ne sont jamais à jour) et une bien meilleure UX y compris pour les joueurs déjà inscrits (exemple: si je perds tous mes vaisseaux, ma page de flotte est vide [exactement comme si je n'étais pas connecté]: il faut donc gérer ce cas joliment quoi qu'il arrive, donc autant le gérer pour les inscrits et les visiteurs; idem pour les plans de vaisseaux [on peut supprimer son dernier plan, même si c'est pas forcément utile], ou les matériaux).

Voilà pour les nouvelles 2
Je vous attends sur le Discord de Variispace pour les screens et des infos plus régulières
Répondre
#22
hello comment tu gères les échanges serveurs du joueur non inscrit ?
Je veux dire par là :

suppose que deux joueurs non inscrits jouent en même temps comment savoir quelle action est à qui ? quel stock est à qui ?

J'imagine un cookie ou un truc comme ca ? mais du coup si j'empêche les cookies, etc.. Est ce que t'auras un contrôle du type : "impossible de te connaitre, tu ne peux pas jouer " ?
[WIP]projet Rivages
[WIP]projet Arthur (comme si ça suffisait pas d'un...)
Répondre
#23
En fait, tant que le joueur ne fait pas d'action "à sauver" (en gros, que du GET, pas de POST), je ne fais rien. C'est un visiteur tout ce qu'il y a de plus classique, sans même une session PHP puisque je m'en tape de le pister (et que je n'ai pas envie d'avoir 5 millions de sessions ouvertes pour chaque bot qui se ballade).

A partir du moment où le joueur fait un POST, s'il n'a pas de session, alors je lui réponds une page d'inscription / connexion, et je relance ensuite la requête. Dans la pratique:
- Le visiteur est sur une page (la création de vaisseaux par exemple), récupérée en GET donc sans session ni rien
- Il fait son vaisseau, c'est du full-client là, c'est juste de l'interface et de l'UX donc pas de soucis
- Il clic sur "save", un JS prend la main sur la soumission de formulaire et l'envoie en AJAX, sans session
- Le serveur n'a pas de session pour cette requête, il répond donc une exception type "NotLoggedInException", c'est à dire un HTTP 401 + JSON {"exception":"NotLoggedInException"} (un truc du genre, c'est déjà en place ça d'ailleurs) + header "X-Location: page-de-connexion-inscription" (X-Location car si j'utilise Location, le JS va directement la suivre, ce qui me pose soucis: y'a pas de "NoFollow" dans les options AJAX)
- le JS récupère la réponse, voyant qu'il s'agit d'une 401 (et voyant éventuellement le contenu de la réponse), il va chercher la page de connexion (X-Location), soit pour la mettre dans une pop-in (iframe), soit il ouvre direct une popup avec cette page, je ne sais pas trop (j'opte plutôt pour l'iframe jusqu'ici)
- Le joueur entre ses identifiants pour se connecter ou s'inscrire (dans l'iframe ou la popup) et soumet le formulaire
- Le JS AJAX de l'iframe s'enclenche, requête le serveur, le serveur l'inscrit (classique), le JS récupère la réponse, et émet un event
- Le JS AJAX de la page de départ récupère cet event, et renvoie la même requête qu'au tout début
- Le joueur ayant été connecté/inscrit entre temps, la session PHP existe, le serveur reconnait le joueur, et le plan de vaisseau est sauvegardé

Il n'y a donc pas de "jeu" complet sans être loggé, mais on peut commencer son action de jeu sans être loggé (et on doit alors l'être pour la sauver). Cela permettra aux joueurs de voir comment jouer sans être préalablement inscrit, et d'être poussés à s'inscrire pour ne pas perdre le plan qu'ils viennent de concevoir.

PS: si t'empêche les cookies, l'inscription se fera, l'event se triggé, mais l'AJAX de la page de départ ré-échouera après l'inscription car le cookie de session n'aura pas été sauvé (charge à toi de ne pas refuser tous les cookies). Si le JS n'est pas actif sur le client (déjà, niveau UX et interface il va en chier), là, y'aura rien qui se passera... Le serveur lui répondra la page X-Location (avec donc une page HTML classique disant "va voir là"), mais le plan de vaisseau sera perdu puisqu'il n'y aura pas de JS pour relancer la requête. Je peux toujours rajouter un "<noscript>" au template HTML pour ces cas là.
Répondre




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