Dracca RPG [reboot]

[Xenos]

Salutations,

ah, ouais, qu'est ce que j'aime rebooter mes projets Mais là, je veux réellement changer d'approche pour Dracca puisque je voudrai m'orienter vers un truc "moins site web" (pour faire simple) histoire de ne pas péter le Roleplay du jeu.

Du coup... J'ouvre un nouveau topic. Je garde, jusqu'à nouvel ordre, les anciens trucs de Dracca (https://dracca.com) mais je ne pense pas mettre quoique ce soit à jour là dedans.

Et l'adresse de la beta du RPG est alors: https://rpg.dracca.com

Bon, actuellement, je n'ai qu'une "landing page", que j'ai essayé de faire très "accueil de jeu", mais cela va m'obliger/permettre de communiquer tôt sur ce projet. Et d'avoir vos retours tôt aussi (et les retours d'autres gens).

Et voici de quoi respecter le pattern de présentation:

Dracca

Contexte: Un univers de dragons et de créatures fantastiques, totalement détaché du nôtre (pas d'humain prévu du tout)

Type de jeu: RPG
Donc, comptez sur la création de votre personnage (dragon), des quêtes, des dialogues (et autres combats, interactions,...) avec les PNJ & les joueurs, des mini-scénarios, etc

Rythme de jeu: au choix, cela dépendra certainement des joueurs et des "quêtes" qu'ils veulent faire. Certaines pourraient prendre des semaines (car difficiles, ou car nécessitant réellement d'attendre qu'un évènement rare arrive) d'autres quelques minutes (surtout au début)
La durée type d'une session serait probablement d'1h je dirai, même si idéalement, j'aimerai qu'on puisse y passer des heures entières!


Type de public visé et contraintes d'âge: 15 ans et + bien que je ne sache pas encore trop comment intégrer des quêtes 18 (voire 21?)+ ce qui pourrait être une contrainte supplémentaire

Financement du jeu: mes sous, après, si lootbox/dons/abonnements sont pertinents, je m'y pencherai volontiers: j'ai pas mal de frais niveau graphisme, vu que je les commande à des illustratrices

Technologies utilisées: PHP, MySQL, JS, CSS
Membres de l'équipe et leur situation: Moi sur le projet, des ressources royalty free (musiques & dessins) et des commandes à des illustrateurs pour les personnages

Nombre de joueurs: Je pense qu'il faudrait une centaine de joueurs quotidien pour avoir un univers vraiment dynamique. Toutefois, je souhaite donner des "routines" aux PNJ (disons plutôt, des algorithmes, qui donneront des routines de vie différentes suivant le contexte & le perso) ce qui fait que même en dessous, on devrait avoir un univers assez vivant de base



https://rpg.dracca.com

[Xenos]

Bonsoir!

Eh ben, j'ai galéré pour réussir à changer d'optique et d'approche, et avoir un modèle d'architecture qui ne soit plus "server-side avec quelques templates de page génériques à tout le projet" pour basculer sur du "modules indépendants chacun en 'single-page', full client JS, avec des appels d'API"...!

Bon, dans la bataille, je perds une partie de la robustesse de mes inspections d'IDE, que j'avais avant, et qui me permettait de dire "hé, là, ton formulaire HTML, il lui manque des champs!" mais je l'ai troqué pour un test unitaire en PHPUnit qui s'assure que la single-page traite bien toutes les API existantes dans le module, qu'elle n'en "invente" pas, qu'elle n'en "croise" pas entre deux modules, et qu'elle gère toutes les réponses possible de ladite API (sauf les erreurs 500, 404, etc, ça, pour l'instant... j'ai un peu mis sous le tapis, en attendant).

Bon, donc, maintenant, le contenu!

Ah, non... Il reste le template de mail à faire correctement

Mais je pense que le contenu vous intéressera plus. Donc, dans l'idée, voici ce que je me fixe comme objectif de départ:

- Proposer une intro, qui idéalement serait lançable sans inscription, histoire d'avoir un petit synopsis du jeu (c'est facile alors d'ajouter un bouton "introduction" en 1er dans le menu de jeu, et d'envoyer vers l'inscription une fois l'intro en question terminée [faudra juste bien la passer une fois le joueur inscrit)

- Créer la partie un peu "tutoriel" de démarrage dans le jeu. Sur le concept, j'aime beaucoup Oblivion là dessus, puisque tout le début du jeu dans les égouts, c'est finalement le "tutoriel" de jeu avant de déboucher sur l'open world en lui-même. Donc, le concept de démarrer dans un "donjon" (celui du tuto) plutôt que direct dans le monde ouvert, c'est probablement classe.

Je pense reprendre à fond le concept de l'Emancep du gamebook ( https://dracca.com/prototype/frgb/ en bref, on quitte son île natale pour émigrer vers d'autres contrées) car il me parait parfait pour une bonne mise en situation dans l'univers de Dracca:
- il évite d'avoir l'impression d'être sur un univers vide, puisque ledit univers a déjà des traditions, une culture, etc
- il fixe un objectif dès le début au joueur
- il permet de "justifier" le fait d'être dans un monde (Insularyuu, l'île où on arrive) qu'on ne connait pas et où on ne connait initialement personne

Reste la mise en oeuvre... !

[niahoo]

ça consiste en quoi ton test PHPUnit ? Car pour tester une single page app je serais parti sur cypress, ou un truc en JS du moins, non ?

[Xenos]

C'était un test qui:
- Cherche quels dossiers sont des modules (ca se voit car le fichier gnagnaENdpoint.php dans le dossier fait un extends d'une classe spécifique: c'est la "page web" du module)
- Cherche tous les gnagna*Endpoint dans les sous-dossiers de ce module: ce sont les pages d'API du module
- Vérifie que ces pages d'API extends une classe d'API (sinon, ça veut dire que j'ai mis une autre page web dans le module)
- Collecte les réponses possibles de PHP dans ces pages d'API (assez simple: la page return un new ApiResponse('token', data éventuelles): j'ai donc besoin de la liste des tokens possibles pour chaque page d'API)
- Vérifie que chaque page d'API est appelée au moins 1 fois dans le JS de la page web du module, et qu'aucune autre page d'API n'est appelée (d'un autre module ou qui n'existerait pas)
- Vérifie que chacun des tokens apparait 1 fois au moins dans ledit JS aussi (et qu'aucun token "inexistant" n'apparait)

Ca restait assez "magique" dans les deux derniers points niveau validation (regex et pifométrie).
Et surtout, cela m'obligeait à run les tests manuellement pour savoir s'il y a un soucis dans le JS de la page web du module. C'est vite devenu lourd & chiant (je déteste m'interrompre "mentalement" avec ce genre de trucs)

C'est donc devenu une inspection intellij assez similaire:
- Si, dans un JS, on a un const apis = window.dracca.api (en pratique, si un JSStatement du parser JS est un "const definition", avec un nom de variable "apis" qui vaut "window.dracca.api") alors ce JS est le JS d'une page web de module du jeu
- Dans ce cas, on va chercher tous les *Endpoint.php dans les sous-dossier du dossier où ce JS se trouve: ce sont les pages d'API
- L'une des classes de ce PHP (la classe principale en fait) doit extends l'une des classes d'API, sinon, affichage d'une erreur (dans le JS... c'est le seul défaut: comme l'inspection analyse le fichier JS, elle ne peut signaler les erreurs que dans le fichier JS, donc, elle dit dans le fichier JS "le endpoint d'API machinTruc là, il extends pas la classe bidule ou chose" & le "fix" me renvoie vers le fichier PHP correspondant)
- L'inspection collecte alors toute les réponses de cette classe (return new ApiResponse('token',...)) ce qui est aussi moins magique qu'avant vu que je peux utiliser le parser PHP d'intellij (en fait, l'ide a déjà parsé le fichier et je n'ai plus qu'à chercher toutes les NewExpressions qui sont des ClassReference.name = ApiReponse)
- L'inspection génère alors un statement JS, de la forme "const apis = window.dracca.api, URL_DE_LAPI = 'url/de/lapi/', URL_DE_LAPI_AVEC_LE_TOKEN_REPONDU = 'avec le token repondu', URL_DE_LAPI_AVEC_UN_AUTRE_TOKEN_REPONDU = 'avec un autre token repondu',...,URL_DUNE_AUTRE_API = 'url/dune/autre/api/',..."
- L'inspection compare ce statement avec le statement existant pour le "const apis = ....", et s'ils diffère, l'inspection affiche une erreur ("Outdated API list") dont la correction est de remplacer le "const apis=..." existants par le "const apis = ..." généré.

Ainsi, j'ai la liste des URL & tokens répondus en début de fichier JS, qui est nécessairement à jour. Ensuite, c'est l'IDE classique qui va pouvoir dire si toutes ces variables sont bien utilisées 1 fois au moins: si "non", cela signifie que j'ai une API inutile ou un token non géré. Dans le contenu du JS, j'utilise alors ces variables pour appeler/gérer les réponses des APIs. Si un token disparait, la variable disparaitra aussi dans le "consts apis=..." et l'IDE mettra ladite variable en rouge, vu qu'elle n'existe plus.

Ainsi, j'ai les infos nécessaires pour faire une colle potable entre le JS de la page web du module et ses APIs. A voir si, un jour, j'ajoute la partie "data" de cette réponse ou si ce n'est pas franchement critique. Et je pourrai aussi rajouter qu'en faisant ctrl+click sur le nom d'une API ou d'un token, cela me renvoie au fichier PHP de l'api, à la ligne du token.

J'applique déjà ce genre de stratégie de génération de code pour la colle entre la page web & sa procédure SQL: c'est efficace et robuste, donc ça me semble être une bonne approche pour la colle entre le JS de la "single page web" du module et ses APIs (c'est le même principe au fond)

[niahoo]

Ok je vois, merci.

[Xenos]

Bonsoir!

Après avoir débuggé et équilibré VariiSpace, je reprends Dracca
La première scène du jeu est en place (l'archi générale consiste à découper le jeu en "scènes", qui sont en fait des modules de jeu autonomes: cela me permettra de rajouter du contenu au fil de l'eau, sans trop interférer avec l'existant du jeu)



J'ajoute au passage, comme suggéré, la possibilité de démarrer le jeu sans inscription (cf menu principal du jeu, "Jouer"). Cela enquillera le joueur sur la 1ere scène (screenshot ci-dessus), et devrais donc permettre de poser les bases du jeu, en ayant au final déjà un pied dans le jeu (je pense être pas mal niveau "engagement progressif"?)

Niveau architecture, comme dit, je pars sur des "modules" de jeu. Ici, le module pour ce dialogue-là est très spécifique, il a donc sa propre page dédiée (au final, cette scène n'est qu'un PHP vide qui envoie 3 balises et 2 ressources, et derrière, c'est un JS qui présente le dialogue au fil des interactions du joueur). Mais pour d'autres dialogues du jeu, cela pourra être bien plus générique. Par exemple, dans le cadre d'un dialogue PNJ/Joueur dans le jeu, j'aimerai avoir un module de "rumeurs" (oui, là je pompe Oblivion sans vergogne!) dans lequel le PNJ pourra nous dire ce qu'il a entendu (d'autres joueurs ou autres PNJ). Le pattern du module de dialogue pourrait alors être:
- PNJ: Vous êtes déjà allé [COD du nom d'un lieu: à l'auberge du cristal vert; dans les grottes du Tjars]?
- Joueur: au choix, Oui ou Non
- PNJ (si oui): Vraiment? Alors, est-ce que [la nourriture y est aussi affreuse/ce lieu est très dangereux/...]?
- PNJ (si non): [Dommage.../Tant mieux!] Car j'ai entendu dire que [la nourriture y est affreuse/ce lieu est très dangereux/...]!

Et dans le cas du "PNJ si oui", on pourra infirmer ou confirmer la rumeur... Libre au joueur de mentir éventuellement, et là, si le PNJ auquel on parle apprend qu'on fait, on l'a embobiné, alors notre crédibilité pour lui diminuera.

J'attends déjà vos retours sur cette première scène, on verra bien comment j'avancerai le reste du jeu
Prochaine étape: création du personnage... héhé, je sais déjà comment intégrer joliment ça dans le flot du jeu!

Lien du jeu => https://rpg.dracca.com/


PS: bon, allez, je vous spoil...?!
Dans l'idée, une fois réveillé, le joueur se dirigera vers un miroir pour se préparer à son Emancep, ce qui me donne l'occasion parfaite pour faire une interface permettant de définir son personnage. Là, je suis plutôt adepte des Loup Solitaire/Oblivion, avec une fiche certes très "formulaire", mais qui permet d'être complet, clair et de garder le contrôle sur le perso qu'on souhaite réellement (je ne suis finalement pas fan de l'idée "d'inférer" ce que le joueur serait à partir de ses réponses aux dialogues précédents par exemple; je préfère le laisser faire sa fiche de personnage tranquilement et "en toute technique d'arrosage").
A la soumission de cette "feuille d'aventure", ca sera le moment de coincer la connexion/inscription, si le joueur n'est pas déjà loggué.

[Xenos]

Salutations,

bon, ca ne va pas du tout, je laisse ce projet en plan lamentablement pendant des mois... alors, j'y reviens!
Donc, je n'ai pas réussi à trouver quelque chose de potable pour l'interface à coup de miroir... Ce que j'ai actuellement (une vue FPS d'une sortie de grotte), j'ai galéré comme un sac pour le trouver, le post-traiter un peu, et je le trouve naze...

Qu'attend-t-on des premiers tableaux du jeu?
C'est la question que j'ai tenu à me re-poser. Car ces premiers tableaux, j'aimerai ne pas les rater, pour que le joueur accroche bien, et qu'il ne se sente pas roulé au bout du compte. Donc, à cette question, je réponds:
- On doit la "tronche" qu'aura le jeu (sera-ce un RPG façon Zelda? un JDR sur table? un Elder Scrolls?)
- On doit plonger dans son univers (on est qui? où? quand? pour quoi?)
- On doit apprendre les mécaniques de base du jeu

Ca me semble constituer une bonne intro.

Premier tableau: Onar
Le premier tableau (discussion avec Onar) répond bien à ces critères: ces dialogues feront partie intégrante du jeu, et j'aimerai leur donner une grande importance. Idéalement, je souhaiterai en fait que ces dialogues ne soient pas pleinement pré-scénarisés (sauf peut-etre cette intro, mais ça, ce sera de l'implémentation de code). Dans l'idée, si on parle à un personnage (PNJ) de "l'auberge du cristal vert", alors ce PNJ connaitra l'existence de ce lieu. Ensuite, si ce PNJ parle à un autre joueur plus tard, alors il (ce PNJ) pourra lui (au joueur) parler de cette auberge. Ou bien, si le PNJ finit par se rendre à cette auberge, pour je ne sais quelle raison, il pourra dire "Ah, j'ai déjà entendu parler de ce lieu!". J'aimerai donc monter un gros morceau autour de ces dialogues, pour qu'ils donnent une vie à l'univers du jeu, et qu'ils permettent des "interactions indirectes" entre joueurs.

Deuxième tableau: sortie de la grotte
Là, ça chie... J'ai mis des plombes à chercher l'image de fond, je n'arrive pas à trouver un miroir potable et au final, ca me semble être un sacré bordel complexe pour, au bout du compte, se retrouver avec un bête formulaire... Et en plus, on n'apprendra rien des mécaniques de gameplay. Donc, poubelle.

Deuxième tableau de remplacement: TableTop
J'envisage donc de changer d'approche: je vais très certainement caler une grande partie du jeu sur le même principe qu'un "table top" (cf https://2minutetabletop.com/sewer-battle...-stoyanov/ ). L'idée est alors d'avoir une vue de haut du lieu où on se trouve, et d'évoluer dedans. Ensuite, en interagissant avec les objets du lieu, on pourra avoir d'autres interfaces. Par exemple, si je vais vers une table, je pourrai m'y mettre à cuisiner et avoir alors un "mini-jeu" de cuisine. Ou si je vais vers une bibliothèque, je vais bouquiner, et j'ai une frame d'un livre (ou d'un parchemin, suivant ce que je lis) etc.

Ca rend plutôt bien dans Oblivion, ou dans Erentis, donc, ça me semble être une chouette piste. Ca me permettra aussi d'intégrer les minis-jeux dans Dracca (ce qui est un de mes buts principaux aussi, pour fédérer ce que j'ai déjà). Ca explique aussi pourquoi je ne vais pas juste aller piocher dans les tabletop existants: j'ai besoin de pouvoir intégrer d'autres contenus d'autres types (les minis jeux).

Le second tableau va donc être remplacé par un tabletop de la caverne où vit le dragon qu'incarne le joueur. Cela lui permettra de se familiariser avec le jeu en lui-même, ces tabletop étant le 2nd gros morceau du jeu (le 1er, ce sont les dialogues).

Bye bye le formulaire
Le 3e tableau qui suivra sera alors l'Emancep, permettant au joueur de définir son personnage au travers de la cérémonie elle-même. Par exemple, plutôt que d'avoir un formulaire classique de "upload un avatar, une refsheet de ton perso, réparti tes points, blabla", je compte proposer au joueur de charger une image de son personnage, car "la photo [?! là, je pète un peu le lore draconique] de ton parchemin d'inscription n'est pas très ressemblante..." (=> je vais peut-etre transformer ca en "je vais prendre une 'photo' de toi pour ton biller de transport)
Ou encore, le choix de l'élément du joueur pourrait s'intégrer dans les dialogues de la cérémonie.

Motivation par l'argent
Histoire de m'encourager à reprendre le projet, j'ai claqué plus de 100€ dans les tabletops du site linké ci-dessus. Ca me fait un bundle assez large de lieux exploitables, et d'assets de base, avec un style uniforme. Ca devrait aider. Comme je ne prévois pas de commercialiser Dracca, la licence passe (et si je veux commercialiser, je contacterai les créateurs pour s'arranger).

Voilà! Je vais donc reprendre le taff sur ce projet <3
Je vais aussi essayer de m'astreindre à plus de retours réguliers, qui seront donc plus petits et plus digestes! Et puis je suis ouvert aux suggestions, même si c'est peut-etre pas simple vu qu'on est très "early design"