JeuWeb - Crée ton jeu par navigateur
VariiSpace, le MMO de l'espace! - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Les réalisations de la communauté (https://jeuweb.org/forumdisplay.php?fid=39)
+--- Forum : Jeux jouables (https://jeuweb.org/forumdisplay.php?fid=52)
+--- Sujet : VariiSpace, le MMO de l'espace! (/showthread.php?tid=7644)

Pages : 1 2 3 4 5 6 7 8


RE: VariiSpace [Reboot] - Xenos - 19-11-2018

Salutations!

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

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 Smile
Je vous attends sur le Discord de Variispace pour les screens et des infos plus régulières


RE: VariiSpace [Reboot] - Ter Rowan - 19-11-2018

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 " ?


RE: VariiSpace [Reboot] - Xenos - 20-11-2018

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à.


RE: VariiSpace [Reboot] - Xenos - 14-01-2019

Salutations,

Quelques nouvelles?! Ca fait un sacré bail que je n'en ai pas postées ici Smile

Pour rappel, les nouvelles sont plus régulières sur le Discord du projet: https://discord.gg/7npjyfr

Mais pour ceux n'ayant pas Discord, voici quelques grandes lignes:
• La création des molécules et des plans de vaisseaux est pleinement opérationnelle

• Quand un joueur n'a pas de vaisseau (comme c'est le cas au début du jeu), il est libre de choisir où commencer la partie (sur quelle planète/Lune/Astéroïde voire étoile), à condition que cet objet céleste respecte quelques règles: sur ces objets célestes, un gros bouton "démarrer la partie" est affiché, donc cela devrait être intuitif Smile

• Le jeu donne alors un vaisseau (qui est mis dans une "flotte") au joueur, en orbite autour de cet objet

• Le joueur peut se servir de cette flotte pour: extraire des ressources de l'objet céleste (via ses points d'action), construire de nouveaux vaisseaux (instantané, parce que c'est chiant de poireauter sinon) ou se déplacer instantanément [là encore, c'est chiant d'attendre sinon] d'une orbite à l'autre (les orbites n'ont pas les mêmes propriétés: les plus proches de l'objet céleste [de la planète] rapportent plus de points d'action, mais requièrent d'être plus souvent connecté pour les "dépenser" [leur "stock max" de points d'action est plus faible])

• Le joueur peut également déplacer sa flotte vers un autre objet céleste de la galaxie, accessible depuis là où il est (si je suis en orbite autour d'une planète, je peux "remonter" vers son étoile, "descendre" vers ses Lunes, ou me rendre vers les autres planètes de ce système stellaire, mais je ne peux pas aller directement vers une autre étoile, ni vers une Lune d'une autre planète du système). Cela permettra de créer des systèmes de "blocus": si je mets une grosse flotte en orbite autour d'une étoile, alors aucun vaisseau ne pourra quitter/entrer dans ce système stellaire sans devoir passer d'abord par ma flotte. De plus, pour quitter un objet céleste, il faut être sur l'orbite la plus "externe" (la plus loin de cet objet): cela permet là aussi de faire des blocus. Si je place ma flotte sur cette orbite externe, alors personne ne peut venir sur cet objet céleste sans devoir d'abord m'affronter, et personne ne peut en partir non plus sans devoir d'abord m'affronter pour accéder à cette orbite externe. J'en attends beaucoup niveau gameplay de ces deux éléments Smile

• On peut "casser" une flotte en deux, et répartir les vaisseaux et les ressources entre ces deux flottes. De même, on peut fusionner des flottes.

• La recherche est également en place. Elle fonctionne ainsi: les plans des vaisseaux ont des "modules de recherche", qui déterminent la puissance de recherche du plan de vaisseau. Quand je construis ce vaisseau, j'ai alors un vaisseau avec une puissance de recherche. Comme ce vaisseau est dans une flotte qui m'appartient, la flotte a donc elle aussi une puissance de recherche. Et comme je peux avoir plusieurs flottes, j'ai donc une puissance de recherche globale. A partir de cette puissance, je calcule un nombre de "points de recherche". Je peux alors "dépenser" ces points pour monter d'1 niveau une recherche que je veux.
Si mes vaisseaux sont détruits, je perds instantanément ma puissance de recherche, et donc, je perds les points *non dépensés*. Si j'avais dépensé tous mes points, alors je ne perds rien (on ne perd pas les niveaux de recherche déjà débloqués). De même, si je construis des vaisseaux, je gagne *immédiatement* de la puissance de recherche, donc des points de recherche, que je peux sois dépenser quand je veux (immédiatement, ou plus tard, en espérant ne pas me faire péter).
De cette manière, on peut faire de la recherche sans devoir poireauter devant un compteur (c'est souvent le cas de la plupart des jeux!) et on a quand même des notions de choix fortes: est-ce que je dépense mon point tout de suite, quitte à le dépenser mal? Est-ce que j'attends un peu avant de le dépenser, au risque de me faire péter? Mais alors, dans quelle recherche le dépenser? Est-ce que j'avance un peu chaque recherche, ou est-ce que je pousse une seule recherche à fond?

• Un tableau de Mendeleiev permet au joueur de voir les atomes qu'il a débloqués, et donc, les ressources qu'il peut extraire des objets célestes et les atomes qu'il peut utiliser pour créer ses propres matériaux

• Les vaisseaux ont chacun une "vitesse orbitale maximale", vitesse max à laquelle le vaisseau peut aller quand il est en orbite autour d'un objet céleste, et chaque orbite a une "vitesse orbitale", vitesse requise pour pouvoir rester sur cette orbite. Les formules sont assez réalistes. Cela signifie que plus on va près d'un objet céleste, plus on doit aller vite pour rester en orbite. Donc, on y sera plus en "sécurité", puisque les gros vaisseaux auront du mal à atteindre ces vitesses

• L'ensemble du jeu est visitable et même "amorçable" sans inscription: vous pouvez faire le tour de la galaxie, voir les compositions atomiques des planètes, les flottes en déplacement, etc sans être inscrit. Vous pouvez même créer votre premier matériau ou votre premier vaisseau sans inscription (mais pour le sauvegarder, il vous faudra un pseudo & un mot de passe). Cela devrait booster un max le taux de conversion du jeu en évitant les "effets murs"

• Il n'y a pas d'état "nouveau joueur" dans ce jeu. Si un joueur a 0 vaisseau, alors il peut en faire "apparaitre" un sur une planète valide, mais cet état "0 vaisseau" peut venir doit d'un nouveau joueur, soit d'un joueur qui s'est fait détruire toute ses flottes. Donc, je ne fais pas de distingo entre les deux. Cela veut dire pas de tuto obligatoire à faire avant de commencer à jouer, et une interface plutôt intuitive et robuste.

Voilà, je pense avoir fait le tour. Il me reste encore, comme gros chantiers:
• Les combats
• Le profil de l'utilisateur
• Les classements
• L'ajout de ressources dans l'objet céleste (on balance des atomes dans une planète pour la déstabiliser)
• La collision entre objets célestes
• Les limites d'orbites (quid si nos vaisseaux ne sont plus assez rapides pour rester en obite? ou trop lourds? etc)
• L'auto-génération d'images (vaisseaux et objets célestes)
• L'échange de ressources entre joueurs
• Les alliances
• L'abandon et la capture de vaisseaux
• Le recyclage de ressources en orbite
• L'espionnage/la furtivité des vaisseaux
• Toute la partie communautaire (Forum, blog, tchat, etc)

Y'a encore du taff Smile


RE: VariiSpace [Reboot] - Xenos - 18-12-2019

Bon....

Je laisse vraiment filer trop de temps entre deux nouvelles du jeu ! Devinez-vous pourquoi?

En fait, depuis que j'ai lancé ECLERD cet été, je pense savoir pourquoi: j'attends trop avant de faire une première release! J'ia un MVP trop massif...
Donc, je vais tâcher d'alléger drastiquement tout ça!

Dans l'idée, je vire... tout! (boum!) et je ne garde que:
• La colonisation de Planètes
• La conception de matériaux
• La messagerie et l'aspect communautaire (car je la plante toujours!)

Bye bye donc:
• Combats (le début sera pacifique!)
• Recherche (parce que... lourd!)
• Conception de vaisseaux (ooooh :c mais en fait, concevoir matériaux ET vaisseaux, c'est lourd au possible... Donc, j'espère ne garder que les matériaux, et proposer plein de types de vaisseauxa ainsi "customizables"; en les rjaoutant 1 à 1 au fil du temps, cela donnera un aspect progressif au jeu)
• Colonisation d'étoiles, de Lunes, d'astéroïdes, etc (je rajouterai ces types d'objets célestes au fil du temps, ce qui me permettra de mettre des règles spécifiques à chacun)
• Multiples orbites autour d'un objet céleste (car l'idée est bien, mais complexe à mettre en place et à jouer, je l'intègrerai donc après)

Cela me permettra, j'espère, de sortir le jeu ! Smile
Au passage, j'ai viré le Forum et le Bug tracker: ils ne sont pas utilisés, et demande de la maintenance/mise à jour qui me pèse... :/


RE: VariiSpace [Reboot] - Thêta Tau Tau - 18-12-2019

(18-12-2019, 12:07 PM)Xenos a écrit : j'attends trop avant de faire une première release! J'ia un MVP trop massif...

T'es pas le seul. Mais toi au moins tu sort des trucs.


RE: VariiSpace [Reboot] - Xenos - 04-01-2020

J'ai surtout sorti des minis-jeux sans inscription ni rien Smile ECLERD, à part notre petite communauté de créateurs de jeux, je ne l'ai jamais vraiment fait décoller (probablement car il faudrait, encore une fois, que je le simplifie à mort dans ses mécanismes de gameplay avant de le diffuser... donc, que je passe du temps à supprimer des trucs sur lesquels j'ai déjà passé du temps!)


Sinon, côté Variispace, quelles nouvelles? Ben.. J'ai tout refondu et tout remoulé... :/

Côté gameplay
Carte galactique
D'abord, j'ai dégagé la grosse carte centrale:

[Image: variispace-2020-01-03-3.jpg]

Pourquoi? Parce qu'elle squattait toute la place de l'écran, rendant très difficile la possibilité d'afficher des informations supplémentaires (comme la taille des planètes, la masse, les flottes dessus, ou autre info qui sera nécessaire après). J'ai donc choisi de revenir à une disposition bien plus "tabulaire" des données. Alors, oui, certains trouveront peut-être que ça va faire un "jeu à formulaire", mais en pratique, je trouve que le formulaire (et les tableaux) n'existent pas sans raison: ce sont d'excellentes (si ce n'est souvent la meilleure!) façon de présenter aux gens des données complexes, et de recueuillir d'autres données (entrées) complexes. Donc, si je veux un jeu avec un peu de richesse, je ne m'étonne pas de voir apparaitre ces éléments tabulaires/formulaires (sur les minis-jeux, c'était différent: la faiblesse du gameplay permet de se passer de ce type d'input/output)

Types d'objets célestes

Ensuite, je vais structures les objets célestes en "types": plutôt que d'avoir un nom générique "objet céleste", j'aurai donc des étoiles, des planètes, et par la suite, des lunes, des astéroïdes, des étoiles à neutron, des trous noirs, etc. Chacun pourra alors avoir ses propres caractéristiques, et sa propre "nature": il ne sera pas possible d'extraire de la matière d'un trou noir par exemple, alors qu'un trou de ver permettrait d'être présent dans plusieurs endroits du jeu *en même temps*. Cela me permettra, au fil du temps, d'ajouter des types d'objets célestes facilement et de rendre le jeu attractif pour les vrais férus d'espace (et de faire découvrir à un peu tout le monde [moi inclus] des types d'objets exotiques!)
Pour le moment, je n'ai donc implémenté que les étoiles (cf ci-dessus) et les planètes (cf ci-dessous):

[Image: variispace-2020-01-03-2.jpg]

Orbite planétaire

Chaque planète aura 2 orbites: une basse, et une haute. Exit donc l'idée d'avoir un nombre d'orbites différents en fonction de la masse de la planète: c'était mon idée initiale, mais elle apporte au final plus de complexité (tant au code qu'au gameplay) que d'intérêt pour le gameplay. L'avantage d'avoir 2 orbites serait de dire que l'orbite basse permet d'extraire de la matière de la planète (ce que l'orbite haute ne permet pas), et que l'orbite haute permet de quitter la planète pour aller vers une autre (ce que l'orbite basse ne permet pas). Les joueurs devront donc changer d'orbite avant de faire certaines actions... Vous sentez venir le concept de "blocus", avec une flotte sur l'orbite haute qui empêche celle de l'orbite basse de partir?! Ou l'inverse, une flotte puissante sur l'orbite passe empêchant la flotte de l'orbite haute de venir récupérer des ressources?! Smile Là, je trouve un intérêt de gameplay donc je garde le concept de 2 orbites, que l'on peu voir sur la page des flottes ci-dessous (il faudra que j'affiche ces deux orbites sur la page de la planète ci-dessus ainsi que la présente ou non de flotte sur ces orbites)

[Image: variispace-2020-01-03-1.jpg]

Flottes

Chaque flotte est constitués de vaisseaux, de différents types (bas du tableau), ce qui lui confère des caractéristiques (haut du tableau) que sa position pourra influer: si je suis en orbite haute ou basse, je n'ai pas les mêmes caractéristiques (ni les mêmes possibilités), de même suivant la masse de la planète autour de laquelle j'orbite (ou, plus tard, la masse de l'étoile). Pour l'instant, les actions sur les flottes ne sont pas implémentées (à part renommer la flotte).

[Image: variispace-2020-01-03-8.jpg]

Les vaisseaux

Les vaisseaux de Variispace ne sont pas pré-déterminés par le jeu: le joueur a la possibilité de les "designer" lui-même, et d'en choisir les caractéristiques: matériau de la coque, taille des équipements, composition, etc. En fonction de ces choix, le vaisseau aura des capacités et des propriétés différentes. Ainsi, ce premier vaisseau ci-dessous a la capacité d'extraire des ressources:

[Image: variispace-2020-01-03-7.jpg]

Mais cette capacité n'aura d'intérêt, bien sûr, que si le vaisseau est en orbite basse autour d'une planète! Un autre exemple est ce vaisseau, qui a la capacité de commander d'autres vaisseaux:

[Image: variispace-2020-01-03-6.jpg]

Cette capacité sera, elle, toujours active, et nécessaire si le joueur souhaite donner des ordres à sa flotte (plus exactement, faute de commandement suffisant, les ordres du joueur seront moins bien exécutés, ce qui peut faire de ces vaisseaux une cible privilégiée). Pour le moment, les algos de calcul de ces capacités ne sont pas au point...! Smile
[Image: variispace-2020-01-03-5.jpg]

Je ne travaille pas sur cet équilibrage pour le moment. Aujourd'hui, je m'occupe du sélecteur permettant de choisir le matériau (l'atome) dans lequel faire la coque et les équipements du vaisseau. Exit donc la conception de molécule (je pense la mettre dans un autre jeu à part, un genre de Chimie-Eleusis peut-être?) qui alourdissait trop les choses.

[Image: variispace-2020-01-03-4.jpg]

Restriction des plans

Les plans des vaisseaux ont toutefois quelques restrictions: on ne peut pas les modifier une fois un vaisseau de ce type construit (on peut, bien sûr, construire plusieurs fois le même type de vaisseau: je peux avoir 10 vaisseaux de commandement qui utilisent le plan "vaisseau de commandement" que j'ai designé). De plus, on ne peut pas créer un vaisseau "de zéro": on ne peut que dupliquer les plans! Cette petite restriction, l'air de rien, est géniale car elle empêche un joueur de créer de son propre chef un vaisseau ayant les capacités "extraire ET commander", à moins de fouiller la galaxie pour espérer trouver un vaisseau de ce type (même un très mauvais vaisseau: il pourrait alors tenter de capturer ce vaisseau, ou au moins d'en voler le plan, pour ensuite le dupliquer et l'améliorer!)... Sentez-vous venir le roleplay similaire au vol des plans de l'étoile noire de Star Wars? Moi, oui... Smile

[Image: variispace-2020-01-03-9.jpg]


Côté création
Je dois dire que tout s'est admirablement déroulé pendant ces vacances de fin d'année?! Aucune difficulté technique majeur n'est venue se mettre en travers du développement (franchement, j'ai trouvé ça hyper-reposant par rapport à mon taf... :/ mais je digresse!)

En revanche, côté "création du gameplay", put*** j'en ai chié! La reconstitution de la galaxie a été facile et naturelle: j'ai plusieurs types d'objets célestes, avec des propriétés et des caractéristiques bien différentes, donc, j'ai 1 table par type d'objet céleste et une page web par objet céleste dans la carte. Jusque là, pas de soucis.
Mais côté vaisseau, wow, la m*rde que ce fut...

J'avais tenté une première approche avec 1 table SQL pour tous les plans de vaisseau, et une colonne "type", pour définir si c'est un vaisseau d'extraction, de commandement, de construction, etc... Ce fut la merde... Y'a pas d'autre mot. Parce que la page web d'affichage d'un plan de vaisseau (que j'avais fait unique contrairement aux objets célestes, puisque je n'avais qu'une table SQL cela me semblait naturel) devenait un foutoir sans nom, car elle devait s'adapter aux types de vaisseaux.

J'avais donc ensuite envisagé de faire 1 table par type de vaisseau, et 1 page web... sauf que là encore, ce fut le bordel car les vaisseau doivent aussi partager des caractéristiques communes: si chaque type de vaisseau réagit de manière totalement différente des autres, alors les combats seront bordéliques car il faudra traiter chaque type de vaisseau attaquant chaque autre type de vaisseau... Et niveau joueur, c'était incompréhensible (et terrifiant!) D'autant que pour indiquer combien de vaisseau se trouvent dans chaque flotte, c'était également difficile...

J'avais alors pensé mettre les caractéristiques globales dans une table, et de garder 1 table par type de vaisseau (donc, au total, N+1 tables pour N types de vaisseaux). Cela résout facilement le problème des flottes (la table SQL des flottes fait référence à la table commune des vaisseaux), mais cela pose des soucis pour lier chacune des tables de type de vaisseau avec la table commune... Ca devient un graphe bordélique, et j'ai déjà expérimenté la complexité dans ECLERD: cela finit par 0 (ok, 20) joueurs maxi, et ce n'est finalement pas si fun que ça... Quand une problématique réelle est complexe, que le système pour la résoudre soit complexe ne me dérange pas. Mais pour un jeu, cela ne m'attirait pas...

Et là, hier matin, boum, révélation: je ne vais pas faire des "types" de vaisseaux différents! Je vais plutôt faire 1 seul concept, "spaceship", et lui accrocher des capacités/caractéristiques (coque, commandement, extraction, construction, stockage etc). Un vaisseau aura alors potentiellement plusieurs caractéristiques, mais sera toujours vu comme un seul et même concept de "vaisseau". Et là, tout devient simple?! La table de flotte référence la table "spaceship"; et les tables de caractéristiques référencent la table "spaceship"... Quelle différence par rapport à l'idée précédente? Un vaisseau peut avoir plusieurs caractéristiques (alors que le modèle précédent implique qu'un vaisseau ne peut être que d'un type, donc, n'avoir qu'un bloc de "caractéristiques"). Cela empêchait donc la création de vaisseaux ayant la capacité de commander et d'extraire (or, j'ai envie de rajouter, via des évènements de jeu, ce genre de vaisseau, pour relancer l'intérêt et la curiosité des joueurs).

J'ai donc, après ces multiples essais, fini par arriver à la structure actuelle de jeu, qui me permet de présenter 1 seule page pour modifier le plan de son vaisseau, avec plusieurs "blocs" dans cette page: 1 par caractéristique. La coque est donc une caractéristique (commune à quasiment tous les vaisseaux: je n'exclus pas de permettre la création d'un vaisseau "sans coque", qui serait alors hyper vulnérable mais hyper léger et rapide, typiquement adapté pour les attaques-éclairs ou pour l'espionnage!), l'extraction en est une autre, le commandement aussi, etc... Notez que la caractéristique "commandement" inclus le fait de commander les autres vaisseaux, mais aussi le fait d'être commandé (ou plutôt, d'avoir besoin de l'être)! Je pourrai les séparer au besoin plus tard...

Voilà les péripéties de Variispace jusqu'à maintenant. Smile Merci d'avoir lu, et je serai ravi de vos retours si vous en avez Wink


RE: VariiSpace [Reboot] - Thêta Tau Tau - 04-01-2020

C'est cool tout ça.

J'aime beaucoup le système de craft avec différents matériaux, si un jour jour je fait un jeu avec du craft, cette mécanique sera surement dedans. De plus j'ai déjà vu plusieurs jeux utiliser ce système pour des pièces d'équipement de RPG, mais jamais pour des vaisseaux spatiaux dans un jeu type 4X. Beaucoup de possibilités de stratégie en perspective (build, commerce etc.).

Par contre bonne chance pour équilibrer 112 matériaux différents Wink



PS: il n'y a pas de "e" a épaisseur


RE: VariiSpace [Reboot] - Xenos - 04-01-2020

Merci ! Smile

(J'avais un doute pour "épaisseure... merci : ) )

Oui, l'équilibrage pour 112 matériaux est exactement le point sur lequel je viens de travailler. Initialement, j'étais parti sur le principe de mettre des formules pour chaque composant (ie: les points de structure de la coque, la vitesse d'extraction de la matière, etc) qui utilisent la famille, le n° atomique, la masse atomique etc du matériau (on notera au passage: que des éléments "réels"!) Mais si je pars là dessus, en cas de soucis d'équilibrage, je vais galérer... Modifier une donnée réelle sera compliqué, et si en plus elle intervient dans 4 formules en même temps, ce sera innommable...

Donc, je viens de boucler un petit refacto consistant à donner à chaque matériau une "valeur effective", nombre décimal entre 0 et 1, qui sera utilisée dans une et une seule formule -en tous cas, autant que possible. Par exemple, j'ai 4 valeurs pour chaque atome ("hull_main, hull_second, hull_injected, hull_overlay") et je combinerai ces 4 valeurs pour déterminer les propriétés de la coque (le nombre de points de structure). Si l'équilibre général n'est pas bon, je reviendrai sur la formule en question. Et si un atome est clairement mieux qu'un autre dans plusieurs formules à la fois, je pourrai l'ajuster sans perturber les autres atomes.

Je fixe encore quelques points (par exemple, n'afficher dans le sélecteur de matériau que les matériaux autorisés, par exemple le matériau principal de la coque sera nécessairement un métal de transition [les atomes oranges au milieu du tableau]) puis je m'attaque à la gestion des flottes Smile


RE: VariiSpace [Reboot] - Ter Rowan - 06-01-2020

(04-01-2020, 01:26 PM)Xenos a écrit : Et là, hier matin, boum, révélation: je ne vais pas faire des "types" de vaisseaux différents! Je vais plutôt faire 1 seul concept, "spaceship", et lui accrocher des capacités/caractéristiques (coque, commandement, extraction, construction, stockage etc). Un vaisseau aura alors potentiellement plusieurs caractéristiques, mais sera toujours vu comme un seul et même concept de "vaisseau". Et là, tout devient simple?! La table de flotte référence la table "spaceship"; et les tables de caractéristiques référencent la table "spaceship"... Quelle différence par rapport à l'idée précédente? Un vaisseau peut avoir plusieurs caractéristiques (alors que le modèle précédent implique qu'un vaisseau ne peut être que d'un type, donc, n'avoir qu'un bloc de "caractéristiques"). Cela empêchait donc la création de vaisseaux ayant la capacité de commander et d'extraire (or, j'ai envie de rajouter, via des évènements de jeu, ce genre de vaisseau, pour relancer l'intérêt et la curiosité des joueurs).

T'aurais du me demander :p je ne sais faire que cette modélisation ^^

Sinon, c'est bien, le concept de molécule me paraissait aussi être une étape fastidieuse.

Je suis aussi intéressé par ton système de craft, mais plus en terme d'ergonomie que de modélisation
==> comment rendre simple convivial et riche l'interface de création