+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Gameplay, gamedesign (https://jeuweb.org/forumdisplay.php?fid=48)
+--- Sujet : Rendre le multi-compte inopérant (/showthread.php?tid=7739)
Pages :
1
2
RE: Rendre le multi-compte inopérant - xanthius - 06-01-2017
"Tu as emprunté 100M$ à la banque, donc tu ne peux pas acheter des avions aux autres joueurs (sinon, les autres joueurs gagneraient des ressources, l'argent, apparues magiquement)"
C'est un frein trop important à mon avis. Tant que l'emprunt n'est pas remboursé pas de possibilité d'acheter, sachant que les remboursements sont longs, le marché de l'occasion n'aurait plus d'intérêt d'être car peu de vendeur et d'acheteur.
Ensuite si l'on ne peut pas vendre un appareil pour lequel on a emprunté et qu'à un moment T on a besoin de trésorerie on fait comment ?
Après avec le système actuel on a aussi une autre corde à notre arc, celle de la dénonciation entre joueurs.
Vous voyez le marché de l'occasion est vraiment un gros nid à triche mais quelque chose de très intéressant au final pour les joueurs.
ps: j'avais même pas remarqué le changement de sujet haha !
RE: Rendre le multi-compte inopérant - Xenos - 06-01-2017
@Ter Rowan
Oui, mais le soucis, c'est que le banquier a un cerveau (si si!) qu'il va falloir coder. Là, je suis un peu sceptique quant à la réussite du codage, qui va générer un empilement de règles. Et niveau sécurité en général (donc triche), il suffit qu'une règle soit de travers pour que toute la pile soit vulnérable.
@Xanthius
Ton avion initial (ou autre), tu l'as emprunté à la banque, donc si tu as besoin de trésorerie, tu le "revends" à la banque (tu le lui rends en fait). Si t'as besoin de trésorerie, tu vas directement taper dans la banque (avec un éventuel plafond par joueur si besoin).
L'idée, c'est vraiment de dire "t'as pris des ressources magiques sorties de nulle part, donc tu dois d'abord les rendre avant de commencer vraiment à jouer". Cela ne résoud pas le "problème" d'un sous-compte qui braderait son avion à un compte principal, mais cela supprime le problème du compte principal qui pompe des ressources magiquement générées à un sous-compte.
Et un compte qui brade un avion normal à un autre joueur ne me semble pas être un problème, puisque l'avion a été crafté régulièrement (il n'est pas tombé du ciel parce qu'on s'est juste inscrit).
Sinon, oui, t'as de toute façon la régulation par la communauté, c'est une autre façon de faire ça. J'essayais de trouver des moyens moins "arbitraires" (c'est pas péjoratif hein, un jeu c'est avant tout une communauté humaine, mais plus les méthodes sont objectifs, plus elles peuvent s'automatiser pour laisser le temps de faire d'autres choses).
RE: Rendre le multi-compte inopérant - Ter Rowan - 06-01-2017
(06-01-2017, 07:44 PM)Xenos a écrit : @Ter Rowan
Oui, mais le soucis, c'est que le banquier a un cerveau (si si!) qu'il va falloir coder. Là, je suis un peu sceptique quant à la réussite du codage, qui va générer un empilement de règles. Et niveau sécurité en général (donc triche), il suffit qu'une règle soit de travers pour que toute la pile soit vulnérable.
hum... tu cherches des modèles compliqués :
{
// répond a la tentative de trouver les offres du compte principal
nbDemandes++; if nbDemandes >15 { echo "no"; return;}
// répond à la tentative de multiplier le nombre d'avions qu'on achète
if somme(remboursements[]) < sommes(pret[]) * 0,6 {echo "no"; return;}
echo "oui";
}
le 0,6 et le 15 sont arbitraires
on est sur des assertions unitairement très simples, chacune répondant à une "faille" mais aussi peut introduire un gp plus intéressant (ex : le 0,6 se transforme en une fonction, lié à des seuils de rentabilité, etc... du coup tu veux lancer une opa en empruntant bcp tu dois d abord avoir prouvé que tu as cette capacité, par ton historique, ton ca, etc...)
ces introductions de gp peuvent être complexes mais après c est un choix gp
par contre les controles me paraissent très simples. Après évidemment il y aura des trous dans la raquete mais combien de petits malins multi arriveront a trouver cette faille ? 10 % ? et si la faille est rendue publique, bah... soit ca devient un élément de gp, soit ca permet au dev de trouver un nouveau controle
RE: Rendre le multi-compte inopérant - Xenos - 06-01-2017
Une limite de nombre de demande est, de mon expérience de joueur (et non de créateur) l'une des sources de multi-compte. Dans tous les cas, si on peut emprunter de l'argent à la banque puis le transférer, peu importe comment (y'a surement pas que le marché d'occasion) vers un autre compte, alors ça ouvre clairement la porte au multi.
[edit]
UN autre problème des valeurs arbitraires c'est que bon, là, y'en a 2, ça va, mais plus on en empile, plus il devient difficile d'équilibrer et de maîtriser le jeu. Sur Eclerd (v0), j'ai une floppée de ces valeurs arbitraire. Je me disais "bon, je vais mettre telle valeur, et j'ajusterai après", sauf que y'en a maintenant tellement que le moindre changement d'une valeur altère tout le jeu et l'équilibrage devient impossible :\
Là, y'en n'a que deux, assez décorrélées, mais cela en fait toujours 2 de plus, et d'autres risquent ensuite de suivre.
RE: Rendre le multi-compte inopérant - Ter Rowan - 08-01-2017
(06-01-2017, 10:39 PM)Xenos a écrit : Sur Eclerd (v0), j'ai une floppée de ces valeurs arbitraire. Je me disais "bon, je vais mettre telle valeur, et j'ajusterai après", sauf que y'en a maintenant tellement que le moindre changement d'une valeur altère tout le jeu et l'équilibrage devient impossible :\je pense que tu admettras que ton cas est un peu particulier. Tu as tendance à créer des modèles complexes pour plus de réalisme et du coup parfois tu te perds dans les méandres de ton réseau de neurones. Ca se trouve tu pourrais fournir la même expérience de jeu avec moins de réalisme (donc moins de variables) :p
Là, y'en n'a que deux, assez décorrélées, mais cela en fait toujours 2 de plus, et d'autres risquent ensuite de suivre.
je suis d'accord avec toi, il ne faut pas multiplier les variables pour l'équilibre du jeu, mais là on parle de l'initialisation
et finalement l'espérance de vie d'un jeu c'est aussi le temps qu'on met pour réaliser ses propres objectifs (avoir la plus grosse flotte, le plus de destinations couvertes, blablabla) si on peut acheter 50 avions en une semaine quel serait l'intérêt du jeu ?
donc les limitations qu'on a (et je pense qu'il y en a déjà dans le jeu) servent aussi à faire durer le jeu.
Il y a multi si :
démarrer seul est trop difficile
ou
le joueur veut avoir la plus grosse tout de suite avant les autres y compris par des moyens interdits (dans le cas où le multi ne fait pas partie du gameplay)
l'équilibrage résout le premier, l'anti multi doit résoudre le second
RE: Rendre le multi-compte inopérant - Xenos - 08-01-2017
Je ne suis pas vraiment d'accord, car si le joueur peut "avoir la plus grosse tout de suite avant les autres" en faisant plusieurs comptes alors cela signifie que le jeu est designé pour poser une restriction sur chaque compte, et non sur chaque joueur, restrictions que certains joueurs n'acceptent apparemment pas (sinon, ils ne multieraient pas).
Pour moi, si le jeu a besoin de poser des limites en dur sur chaque compte pour avoir un "intérêt", c'est que le gameplay est juste vide et qu'on pose des restrictions pour ne pas en faire le tour trop vite.
Par exemple, si le jeu consiste juste à mettre le plus d'avions sur le plus de lignes aériennes (ou si cette méthode brutale est un moyen de gagner), alors certains joueurs le feront. En revanche, si le jeu permet de designer ses propres avions (genre Kerbal Space Program) alors le multi ne sera plus utile car 30 comptes ou 1 seul ne changeront rien: on n'aura toujours qu'un cerveau pour penser à ces designs.
Bref, cela limite en effet les joueurs, mais de manière complètement artificielle. Et je ne suis certainement pas le seul à vouloir faire sauter ce genre de barrières quand on me les pose.
Si tu veux luter contre les "j'ai la plus grosse", il suffit de ne pas faire de classement. Les joueurs qui veulent faire sauter les scores le feront dans leur coin, ceux qui veulent juste jouer pour passer le temps quelques minutes le feront sans déprimer devant leur classement à raz de terre. Et tu t'épargneras du code
RE: Rendre le multi-compte inopérant - Argorate - 10-01-2017
Je comprends pas trop ta théorie de la "limitation"...
Oui un jeu limite le compte (<=> 1 joueurs si pas de triche), parce que le delta T est un facteur présent partout...
Prend Factorio par exemple : le jeu si on le résume, consiste juste à transformer des ressources pour construire le bâtiment spécial qui fait terminer la partie...
Si tu ne limites pas, alors le jeu peu se finir 5 secondes après avoir commencer, le temps d'entré dans la console : /give me 99999 from all ressources et voilà...
Donc le fait de limiter c'est pas juste "parce que c'est vide", ça peut faire partie intégrante du GP, mais a te lire j'ai l'impression que tu fais un revirement de main sur ce point sans réel raisonnement.
Après je te rejoins sur des jeux javascript débile où y a juste un timer et où tu dois attendre sans rien faire... Mais sur factorio donc, il y a tellement tjs un truc a faire que tu t’arrêtes jamais ^^
RE: Rendre le multi-compte inopérant - Xenos - 10-01-2017
C'est l'équivalence qui pose soucis: si tu fais du jeu web, tu prends le risque d'avoir des comptes sans joueurs (qui ont abandonné, ou qui ont mis un bot à la place), des comptes joués par plusieurs (qui jouent ensemble derrière l'écran, ou à tour de rôle), des comptes joués par un même joueur, etc. Sinon, mieux vaut simplement se faire un bon vieux jeu de société ou un jeu sur un serveur privé et inviter des amis qu'on connait à une partie privée.
Pour ma part, les jeux qui prennent 1 univers et le partage pour tout le monde (= dans lequel on jeu contre des anonymes) doivent respecter ce choix de l'anonymat, et laisser tomber l'idée de savoir ce/celui qu'il y a derrière le compte.
Les jeux JS ne me dérangent pas, car le but n'est pas de monter son score de suite (on peut le faire si on le veut d'ailleurs), mais de passer du temps en s'amusant. C'est la raison pour laquelle la feuille d'aventure de Dracca n'est pas contraignante: tu peux te donner 10.000 points de vie ou d'habileté si tu veux (bon, le champ est limité à 2 chiffres je crois, par practicité, mais ça se saute cette limite). Le problème, ce sont les jeux qui veulent faire des univers où des joueurs anonymes se rencontrent, sans que tous aient le même but. Certains sont là pour passer une demi-heure après le boulot (ou pendant!) alors que d'autres sont là pour faire péter leur score très vite, ou d'autres encore sont là pour écraser les autres, ou d'autres encore sont là pour tenter de montrer qu'ils sont plus fûtés que les codeurs du jeu. Or, le caractère anonyme des comptes, par définition, empêche toute spéculation sur le lien entre joueurs et comptes (un joueur peut avoir plusieurs comptes, un compte peut être joué par plusieurs joueurs, voire par des bots, etc). Dans un jeu comme cela, on travaille donc uniquement avec le compte: on ne sait pas ce qui est derrière le compte. Et du coup, il faut se monter un gameplay adapté.
Ce n'est encore une fois que mon opinion, mais je trouve que cette approche règle bien des emmerdes. Et si on veut faire un jeu sans "multi-compte", alors il vaut mieux laisser tomber l'anonymat et préférer des jeux où les joueurs créent leur partie, la lance, l'administre, et invitent leurs amis (il y aura toujours anonymat pour le serveur, mais plus pour les joueurs entre eux: ils sauront qui est derrière chaque compte et choisiront ce qu'il convient de faire sinon).
PS: pour revenir à l'histoire de l'incrément, si le seul intérêt du jeu est de monter son compteur, je maintiens que c'est très creux. S'il s'agit de bien gérer ses ressources, c'est différents: t'as beau avoir 99999 dans tes stocks, maintenant, faut les dépenser pour vraiment jouer. Tout dépend donc du type de jeu que tu veux: un jeu d'attente (façon incrémental game) ou un jeu de dépense (où l'attente des ressources est donc une contrainte, et non le véritable intérêt du jeu).