31-07-2017, 04:49 PM
Citation :si les anciens joueurs voient qu'il y a beaucoup moins de contenu qu'auparavant, ils ne resteront pasOrf, je sais pas trop ça... Perso, si je vois un vieux jeu qui réapparait, je serai content d'en voir les démarrages. Ok, y'a pas tout dès le début, mais au "pire", j'entendrais parler du projet, j'irai voir, je m'inscrirai éventuellement, puis je laisserai mon compte "pourrir" jusqu'à ce que les features s'étoffent. En tant que créateur, dans cette situation, tu n'as alors plus qu'à faire de la relance lors de la sortie de la "vraie" version "finale". Mais bon, on va pas refaire le passé Disons que sur Oban, c'était certes pas du vieux jeu (mais une série TV), mais on avait des gens intéressés dès l'idée même d'en faire un fan game. Si on avait attendu de sortir une version fiable pour que cela puisse se propager... Ben, rien ne serait passé vu qu'on n'a pas sorti de version beta =P
Non, je pense que ce sera plus simple qu'un process de tuto car dans le masquage, tu te bases purement et uniquement sur l'état du joueur: il a des troupes? Non => Masquer les menus d'attaque. Peu importe qu'il ait déjà lancé une attaque ou non. Avec un process de tuto, tu es plus dans l'optique "est-ce la 1ere fois qu'il ouvre ce menu? Est-ce qu'il a déjà commencé le tuto? Où en est-il?" et je trouve cette approche (un peu "procédurale") chiante à gérer. D'ailleurs, dans ce genre de cas, on essaie souvent de retomber sur un système d'état, avec des dizaines de colonnes type "has_done_this_part_of_the_tuto" (ou une table SQL indiquant des paires [joueur, tuto réalisé]).
Ouais, je pense que le soucis vient du fait que le compte de test, par nature, est déjà "avancé dans le jeu", ce qui fait que l'utilisateur qui s'en sers n'est pas en phase avec l'état du compte. A la limite, pour éviter cela, il faudrait le "réinitialiser" toutes les heures (ou un truc du genre), mais cela amène plein plein d'emmerdes supplémentaires... D'où ma position actuelle: le compte de test, c'est finalement bidon et inutile niveau joueurs. Ca sert juste, éventuellement, aux devs pour faire quelques essais (mais bon, essayer en prod, c'est mal )
Pour la carte, tu peux créer un SVG, l'embarquer dans la page, et afficher l'image raster de la carte directement dedans. Tu places ensuite des "zones cliquables", sous la forme de paths par exemple (avec un CSS "fill:transparent" et un CSS :hover "fill: yellow" par exemple) et chacun de ces paths peut aller dans une ancre "a" (avec la différence que c'est un "a xlink:href='...'" et qu'il faut déclarer le namespace xlink dans le tag svg "xmlns:xlink='http://www.w3.org/1999/xlink'").
Ce n'est pas interactif avec la BDD (ie: la carte ne reflète pas encore le contenu du jeu), mais cela te donnera une base de travail. Après, les "path" cliquables pourront être générés à la volée.
Hésite pas à aller voir les tutos du MDN sur le SVG, ou à ouvrir un peu les sources des différents mini-jeux que j'ai sur https://reinom.com. Tu y trouveras quelques exemples pratiques de SVG. Idem, sur le blog https://toile.reinom.com tu as un article avec toute une liste d'exemples en SVG, dont la plupart ont des sources accessibles.