Parceque nous avons une vie réelle, nous ne nous connectons pas 24H/24 à Celestus. Certains le font quelques minutes tous les jours, d’autres une fois tous les 2 jours, bref tout le monde n’est pas connecté en même temps, ni ne consacre le même temps au jeu.
De ce fait nous nous développons différemment, et les interactions entre joueurs d’une même alliance sont freinées par la difficulté de se croiser au bon moment et par les développements disparates de chacun.
L’objectif de ce débat n’est pas de remettre en question le système du nd, ni de mettre au même niveau tous les joueurs.
Au contraire, puisque Celestus est un jeu de groupe où le gameplay est fortement axé sur la coopération, l’intérêt de ce débat résiderait dans les possibilités qu’offrirait un outil promouvant le jeu de groupe à tous les niveaux, de manière transverse à l’intérieur d’une alliance.
- augmenter et faciliter les interactions entre joueurs d’une même alliance.
- Renforcer l’intérêt d’une alliance en lui fournissant un outil pour créer des projets d’alliance directement dans le jeu
- Rendre encore plus attractif le jeu en groupe et le facilité
- Créer un système de financement de projet commun interne à une alliance. Seules les membres peuvent en bénéficier.
- Le système se base sur la création d’un projet de groupe. Celui-ci peut viser un retour à part égal au niveau des participants (ie qu’ils peuvent cotiser différemment mais à la fin reçoive la même chose) ou alors il s’agit d’un projet participatif où on fixe un objectif pour un personne de l’alliance et il est financé en commun. > pb1, pb2
Ex de projet « de retour à part égale » : monter les mines au niveau 40 des participants.
Ex de projet « participatif » : financer un plan pour la flotte de faction de l’alliance.
- Pour éviter de rajouter des calculs sur les montants du projet et facilité l’intégration possible de cette suggestion, le montant envisagé pour le projet serait spécifié au départ par le joueur qui lance le projet. Ce montant sera plafonné (à définir) par le niveau de l’alliance en termes de ND
- Le joueur lance donc le projet en l’intitulant dans les cases fournit à cet effet. A partir de là, celui-ci est publié dans un message du guilde (descriptif / montant / …) (à définir).
Les membres de l’alliance choisissent alors de participer avec le bouton prévu à cet effet. > pb6
- Au bout d’un certain délai (à définir) le projet est ensuite lancé. Celui qui la lancé peut choisir d’exclure certains participants à l’aide du bouton prévu à cet effet.
- Les participants peuvent alors cotiser grâce à des champs comme ceux de la bourse qui existe déjà. Le montant de participation possible seraient limités par 1) leurs nds ; 2) le type de vaisseaux de collecte qu’ils possèdent 3) leur alliance (à définir) .
- Jusqu’à ce que le montant visé de cotisation soit atteint, les ressources ne sont pas envoyées mais comptabilisé. Une fois que la somme requise est atteinte > pb4 les ressources sont envoyées par vaisseaux de collecte des fonds (à définir) jusqu’au vaisseau ?/structure ? (à définir) de rassemblement des fonds que possède le joueur qui a lancé le projet. Néanmoins un certain délai est nécessaire pour que les vaisseaux partent avec leurs cargaisons. >pb3
- Une fois que les ressources ont été récupéré par le lanceur de projet, un rapport sous forme de tableau récapitulatif est publié.
- A charge aux joueurs ensuite de redonner les objectifs de projets. > pb5
-Dans le cas où l’objectif du projet concerne un nd supérieur mais que la collecte a été réalisé par un nd inférieur, un bouton dans le menu flotte envoi de l’objectif du projet permettrait d’envoyer des vaisseaux d’une valeur équivalent au total de la collecte réalisé par le projet. > pb6 En aucun cas néanmoins, l’envoi ne pourrait concerner des ressources brutes.
- Un projet devrait pouvoir être annulé avec un bouton adéquat. Les compteurs seraient alors remis à zéro et un message annonçant l’annulation du projet serait envoyé aux participants. Cela serait possible pour celui qui a lancé le projet où par ceux habilités à la gestion de projet dans une alliance, (case gestion de projet dans les cases de droits des alliances).
=> facilité des projets en commun avec les ressources d’une alliance
=> proposer une alternative aux connections différés des joueurs (puisque les vaisseaux de collectes seraient automatisés)
=> renforcer l’intérêt de son fonctionnement interne
=> renforcer la dimension RP d’une alliance (plus qu’un simple label que partage les gens c’est une structure qui fournit des outils pour travailleur à plusieurs)
=> atténuer les difficultés de coopération inhérente au système des nds
Ex 1 : un technologiste financé (ou pas) par son alliance peut se retrouver à un nd supérieur à ses coéquipiers. Via le système de contrat et un bon paquet de zrc cela ne pose pas de problème. C’est très bien pour la faction mais c’est assez coercitif en pratique pour les joueurs d’une même alliance.
Ex 2 : Prenons deux joueurs d’une même alliance, un nd 10 batisseur producteur de mc mk2 et un nd 9 souhaitant en acquérir. Pour des raisons X, Y Z, le nd 10 est le seul bâtisseur à qui le nd 9 peut s’adresser de manière pratique (heure de co…). Sauf que le nd 10 ne peut avancer ni de zrc ni de ressources au nd 9 qui a pourtant de quoi faire construire ses mc mk2. Le cas inverse est aussi envisageable dans le cas où le nd 10 fournit les ressources au nd9 pour se faire créer un vaisseau couteux, mais le nd9 n’a pas assez de zrc pour lui acheter les ressources. Dès lors le nd 10 peut acheter le vaisseau produit, mais reste finalement déficitaire.
=> permettre aux multi comptes de passer outre la barrière des nds
Remarquons que de toute façon les multi peuvent réaliser des interactions entre eux, quelques soit leurs nds. Il suffit de se débrouiller avec des montants de zrc.
> Pour limiter les abus et rendre cohérent les montants de cotisations, un plafond fournit en fonction du type de vaisseaux de collectes possédés, les nds de chacun et l’alliance pourrait être une solution.
> d’autre part les transactions réalisés par les projets pourraient être enregistré afin de voir si il y a des abus en cas de doute.
=> pb1 : Des participants trichent en participant moins que les autres
Sol1 > Le tableau récapitulatif envoyé à la fin du financement permettra d’avoir de la visibilité et d’exclure ensuite les participants des autres projets.
=> : qui participent ? tous les membres de l’alliance ?
Sol2 : Comme évoquer dans la description, les membres de l’alliance peuvent choisir de participer au projet lors du message de lancement, et être exclu des participants ensuite par celui qui le lance.
=> pb3 : abus de la capacité de stockage du système pour « cacher des ressource » où les faire disparaitre aux yeux d’un attaquant.
Sol3 Mais pour éviter qu’un projet ne soit complété à toute vitesse par un tiers pour soustraire des ressources lors d’une attaque, un certain délai est nécessaire (à définir) pour que les ressources puissent partir.
=> pb4 : La somme requise pour un projet est atteinte. Mais entretemps, un des joueurs s’est fait piller.
Sol4 : introduire dans l’algorithme de comptage le fait que les cotisations peuvent être prélevé aux endroits où se trouve les vaisseaux spécifiques & dans le cas où il n’y aurait plus aucune ressource, le manque serait ajouté à la somme requise. Pour éviter que le joueur qui a été pillé soit celui qui doive recotiser spécifiquement.
=> pb5 : comment savoir si les objectifs du projet ont réellement été réparti ?
Dans tous les cas si les participants du projet sont déçus du retour, ils ne participeront plus.
=> pb6 : Des projets vont être créé juste pour faire transiter des ressources entre les nds et dépasser la limite de cotisation via la création de projet.
Cas du nd 9 vache à lait multi pour le nd 10.
Sol6 : Il faut au moins 4 personnes pour lancer un projet (comme une alliance). On ne peut participer à 2 projets en même temps, et après le lancement du projet, il faut attendre 3 jours (à définir) pour en lancer un nouveau.
Explications : Notre nd 9 est forcément un multi dans la même alliance que son propriétaire (rare) pour participer au projet. S’il ne l’était pas, il ne serait pas tenté d’être une vache à lait et ne choisirait pas de participer au projet, donc de faire transiter des ressources. Une personne qui participe veut sinon forcément y trouver son intérêt. Puisqu’à la fin d’un projet, il n’est pas prévu qu’on puisse envoyer de ressources vers un nds supérieur (mais juste des vaisseaux d’une valeurs équivalentes à la valeur totale du projet) dans le cas où c’est un nd inférieur qui a lancé le projet il ne peut y avoir de retour de ressources en dépensant la limite de cotisation d’un nd spécifique via la création de projet.
=> pb7 : un multi lance les projets dans l’alliance pour la bloquer/un joueur lance un projet et quitte l’alliance.
Sol7 : un projet est automatiquement annulé si la personne part de l’alliance et peut être annulé par les personnes disposant du privilège d’alliance gestion de projet.
- Création d’un onglet projet
- Création d’un Champs « lancement de projet » dans l’onglet avec un endroit pour le titre, un -endroit pour le descriptif pour lancer le projet
- Création d’un message qui annonce le projet aux membres de l’alliance. Des boutons comme ceux du message de don de colonie (oui/non) permettent de participer.
- Création d’un algo qui décompte le temps depuis le lancement du projet et le valide : tant que l’heure « heure de lancement du projet + délai » n’est pas atteinte, compter nombre de participant, si nombre de participant supérieur ou égal à 4, valider le projet.
- Création d’un message qui au bout du décompte publie le nom des participants. Ce message comporte des boutons oui/non dans le message permettent d’exclure certains participants. Un bouton « confirmation : oui / non » permet au lanceur de lancer définitivement le projet.
- Création de champs dans l’onglet projet pour cotiser. Ils seraient similaires à ceux qu’on voit à la bourse.
- Création des vaisseaux de collectes sur un format similaire à ceux des docks boursiers. Les ressources stockées dans ces vaisseaux, où sur les planètes où ils sont basés serait prise en compte dans le décompte des cotisations.
- Création du vaisseau / structure de récupération des ressources au niveau du lanceur de projet : rq elle n’est pas forcément nécessaire car les ressources pourraient être délivré sur la planète mère du lanceur de projet.
- Création d’un tableau de gestion du projet, autant pour le message final (qui récapitule le projet, ceux qui ont cotisés, combien) que pour le suivit des algorithmes qui font le compte. Par exemple ce format :
Participants --- métal---tritium---pps---zrc---total en conversion zrc --- pourcentage de partipation
Participant1
Participant2
Total
- Création dans l’allocation des priviléges des membres de l’alliance de la case « gestion de projet » : si validé elle permet à un membre habilité de l’alliance d’arrêter un projet en cours.
- Création d’un algorithme qui vérifie si une personne de l’alliance participe à un projet. Si oui, elle n’a pas le droit de participer à un autre projet. Quelqu’un qui lance un projet est compté comme participant. Celui-ci vérifie en outre que les délais sont respectés pour pouvoir participer à un nouveau projet.
A définir :
- délai pour que les ressources puissent partir.
- format du message de guilde
- plafond de cotisation en fonction du nd / des vaisseaux de cotisations / de l’alliance
- délai entre 2 participations de projets
Comme un outil permettant de réaliser des projets en alliance, intégré à même le jeu, sans tenir compte des différentes connexions de chacun.