bloquer une liste d'ip dynamique apache2 ? - Version imprimable +- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org) +-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38) +--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51) +--- Sujet : bloquer une liste d'ip dynamique apache2 ? (/showthread.php?tid=7295) |
RE: bloquer une liste d'ip dynamique apache2 ? - Xenos - 07-01-2015 Pas d'accord, car bloquer les interaction sur les mêmes IPs va bloquer les personnes qui jouent: • A plusieurs, avec un même routeur (cas très très courant, où on a 3 personnes de la famille par exemple qui jouent au jeu depuis la même connexion internet) • Via le même proxy (cas des résidences étudiantes par exemple) • En LAN (ben oui, supposons qu'on invite ses 20 copains à une IRL et qu'on joue tous au jeu, on aura 20 comptes avec la même IP...temporairement ok, mais 20 comptes quand même) Perso, je préfère lâcher du leste, et laisser les joueurs faire du multi s'ils le souhaitent. Mieux vaut un gameplay où le multi-compte n'avantage pas (car ce sont des gameplays plus rares, donc plus originaux et donc sur lesquels un indépendant peut facilement se démarquer). Pourquoi favoriser le blocage des multi-comptes, au risque de se retrouver avec des serveurs de 2000 comptes et 10% de joueurs actifs (soient 200 joueurs avec 200 comptes actifs), au lieu de favoriser la création d'un "garbage collector" et de laisser libre court au multi (et avoir ainsi 1000 comptes gérés par ces mêmes 200 joueurs)? Cette dernière solution crée des serveurs plus actifs, et augmente les chances d'achat de la part d'un joueur (ben oui, si le joueur veut +10% de production sur les mines de chacun de ses 5 comptes, il doit payer 5 fois!) RE: bloquer une liste d'ip dynamique apache2 ? - Max72 - 07-01-2015 Pour les familles/les potes j'y avait déjà pensé, mais pas de plus grosses infrastructures en effet :/ Sinon lorsque je parle de limiter les interactions, ça ne signifie pas 'aucune interaction'. Par exemple, les échanges avec un taux non équitable (donc destiné à enrichir un compte) seraient impossible, ou la possibilité d'investir plus que de raison dans la ville voisine, ... Je sais que cela amoindrirait le plaisir de pouvoir jouer en famille sur un même jeu, mais comme dit, si les multis sont un vrai fléau et que je n'ai pas su en limiter le profit via le gameplay, c'est (pour le moment) la solution que je mettrai en place. Elle a ses défauts, comme toutes, mais il faut bien faire un choix Dans l'idéal, je préfèrerai de loin à ne pas avoir à implémenter de telles restrictions, soyez en sûr.. RE: bloquer une liste d'ip dynamique apache2 ? - Xenos - 07-01-2015 Perso, je déporterai la restriction sur le gameplay: interdiction de sur-pusher un compte. Par exemple, un compte A n'a pas le droit de donner au compte B (sans contrepartie) plus de 1000 unités de ressources par jour. Ainsi, on limite l'intérêt du multi-compte sans pour autant casser l'immersion du jeu: la règle interdit de donner trop de ressource à l'autre, point barre (d'ailleurs, là, j'ai dit "par jour", mais cela pourrait être une limite absolue, qu'on ne peut remettre à 0 qu'en déplaçant des ressources de B à A ou en payant des euros). C'est simple à réaliser, facile à comprendre, efficace, et cela ne casse aucunement l'immersion du jeu (pas de pop-up 'multi compte interdit'). RE: bloquer une liste d'ip dynamique apache2 ? - Max72 - 08-01-2015 C'est aussi ce que je vise. Par exemple, il n'y a aucun don possible, que des échanges en respectant certains taux, de façon à ce qu'il soit impossible (ou alors il faudra faire preuve de patience pour un résultat minime) de privilégier un joueur (compte) au détriment d'un autre. Pour le gameplay, ça passe plutôt bien, dans le sens où chaque chef de cité ne veut voir sa cité vampirisée au profit d'une autre. Puisque tu parles d'euros, j'aimerai mettre quelques options payantes sur le jeu, mais aucune d'entre-elles ne permettraient de pusher un compte, uniquement de booster la cité de celui qui paye. Ainsi même en payant le multi n'est pas rentable Edit : je crois qu'on a un peu dérivé de la question d'Argorate, désolé mais c'est intéressant, non ? RE: bloquer une liste d'ip dynamique apache2 ? - Xenos - 08-01-2015 Ca méritera un petit résumé :p RE: bloquer une liste d'ip dynamique apache2 ? - Argorate - 08-01-2015 (07-01-2015, 11:07 PM)Xenos a écrit : Perso, je préfère lâcher du leste, et laisser les joueurs faire du multi s'ils le souhaitent.Au moins c'est clair. ^^ Moi c'est le contraire. Donc chacun on va défendre ce pourquoi on le fait, le problème c'est que tu défends un comportement laxiste selon moi, alors que moi je défend un comportement d'équité et de justice. Rien n'est parfait. Tu dis que je pourrais jamais empêcher 100% des triches? Oui, tu as raison. Un préservatif c'est pas 100% non plus, c'est 99.99%. Et alors? ça ne doit pas m’empêcher de faire au mieux. En fait, tout dans la vie marche à base de se que j'appel "seuils d'acceptabilité". Quand tu vas acheté un truc, tu as un seuil d'acceptabilité du prix, qui varie selon les personnes, et au delà du quel tu vas te dire "non j'achète pas, c'est de l'arnaque". Même chose dans chaque prise de risque, sur quelque sujet que ce soit. La différence entre nous n'a donc rien d'original, elle existe depuis que le monde et monde. C'est une simple différence de seuil d'acceptabilité. En l’occurrence, ton seuil d'acceptabilité de la triche dans ton jeu web semble largement supérieur au mien. Si je devais le quantifié, je dirais que pour un jeu amateur avec 1000 joueurs actif (chaque jour), ce qui est pas mal, serait du 0.1% de tricheur acceptable. Allez, soyons gentil, peut être 0.2%... 2 tricheurs sur mes 1000 joueurs maximum. J'avoue ne pas savoir a quel seuil tu t’arrêtes, mais peut importe, chacun son seuil. Je pense juste qu'il vaut mieux tendre vers la perfection, même si on ne l'atteint jamais, que de s'en éloigné sous prétexte qu'elle est inatteignable. Pour l'argument : "vu que je peux pas empêcher à 100% la triche, je vais donc tenter de rendre la triche inutile", c'est une idée. Je pense personnellement que ça peut être une technique de plus, mais qui là aussi aura des limites, puisque à tout jeu multijoueur, on trouve fatalement tôt ou tard un intérêt à être plusieurs, sinon c'est qu'effectivement le jeu est pousser avec une extrême exactitude de sorte que tout compte reste parallèle sans gain supplémentaire et rend le jeu très limité à mon sens. Ensuite cela pose un problème de fond. Faire un jeu en dictant ses lois (son gameplay) par la peur de la triche et donc par des "contres" me semble pas saint à la base. Je suis créateur, je n'aime pas trop les limites autres que celle de mon imagination. Mais pour le coup c'est sans doute une position philosophique. Bien que techniquement ça ai de grosse incidence, puisque tu limites le type d'action et d'interaction de ton jeu et de tes joueurs. Hors, si tu veux faire un jeu qui prône une idée, un message, moi c'est souvent : la coopération. Alors par définition, il y a avantage à jouer à plusieurs, et donc aux multicomptes. S’empêcher ou limiter son gameplay d'échange par exemple (puisque tu en parles), je trouve ça dommage. Si je suis dans le cadre d'un jeu de simulation de l'Union Européenne avec une monnaie commune qui a un PEG de 1 pour 1, sans limite ni controle de mouvement de capitaux, ça signifie que mes joueurs doivent pouvoir échanger de manière illimité en nombre et en quantité leur richesse. Mais là on tombe dans un sacré problème vis à vis de la triche. Mais le problème c'est pas le gameplay du jeu, puisque par définition je veux simuler ce qu'il se fait en réel, donc les règles du jeu sont forcement correct, c'est bien la triche le problème... PS: pour TOR, la liste des IP que je compte ban, c'est uniquement la liste des proxy lié à tor, ce ne sont pas les IP des gens. EDIT: on oublis ici aussi de parler d'un autre aspect, c'est que lorsqu'on souhaite faire de cette activité un moyen de "gagner sa vie", alors l'aspect moral (plus important pour moi) se combine alors avec l'aspect financier. Si un joueur développe un moyen d'obtenir gratuitement des choses normalement payante, et en plus fait tourner le truc, cela peut nuire à l'activité... RE: bloquer une liste d'ip dynamique apache2 ? - niahoo - 08-01-2015 (xenons, si le type fait expres de devenir uneproxy de sortie, et donc fait expres de se mettre dans la liste des IP qui seront bannies, on s'en fout. non ce n'est pas ce que ferait un tricheur, c'est ce que ferait un idiot) Argorate, un jeu qui permettrait de faire des échanges de capitaux comme dans l'union européenne et qui ne permettrait pas de tricher ne serait pas du tout réaliste voyons ... RE: bloquer une liste d'ip dynamique apache2 ? - Max72 - 08-01-2015 Je me lance, désolé de vous couper Citation :La différence entre nous n'a donc rien d'original, elle existe depuis que le monde et monde. C'est une simple différence de seuil d'acceptabilité. Là où tu vois seuil d'acceptabilité, je vois ratio utilité/boulot : Par exemple pour bloquer les utilisateurs de Tor, tu vas devoir développer et mettre en place certaines choses (conf apache, crons, affichage de messages disant que Tor est banni, contrôler les IP, ..). Avec tout ça, combien de tricheurs vas-tu repousser ? Partons dans l'idée où 60 millions de français naviguent sur internet. Parmi eux, environ 100 000 utilisent Tor, et encore. Si tu as 1000 joueurs sur ton jeu, la proportionnalité pousse à dire que tu auras environ : 100 000 / 60 000 000 * 1000 = 1.6 utilisateurs de Tor sur ton jeu. Évidemment, ce n'est pas vrai car Mme Michu est moins intéressée par les jeux que (j'imagine) les Torusers. Donc autant de boulot pour bloquer 2 ou 3 mecs, ce n'est pas assez pour moi. De plus, ceux qui utilisent Tor et veulent vraiment faire du multi y arriveront (proxy tout ça, c'est en théorie dans leurs compétences). Ensuite, tu sous-entends que limiter le sur-push d'un joueur nuit forcément au gameplay/réalisme : Mon jeu vise, comme le tien si je comprends bien, à devoir coopérer pour avancer plus vite que les autres. Ce n'est pas pour autant qu'accepter tous les dons/échanges entre joueurs rend le gameplay/réalisme meilleur. Pour reprendre ton exemple, dans le cas d'un jeu de simulation de l'UE, j'autoriserai les échanges (voire même les dons), mais toujours en avantageant le pays le plus pauvre, ou que le plus riche ne devienne encore plus riche. Dans ce cas, tu annules le fait de pouvoir pusher un compte (tu ne peux pas donner à un pays plus riche que le tien). Niveau réalisme, je pense que ça se tient également : Qui aurait envie de couler son pays au profit d'un autre ? A ce que je sache, la Grèce ne donne pas de subventions à la France ^^ Mettre en place des idées IG est long également, faut chercher, coder, tester, niveler, ... mais mon ratio utilité/boulot est bien meilleur que celui du blocage de Tor, car je vise tous les multis, pas 0.16% des joueurs. Admettons que tu as bloqué les utilisateurs de Tor, que tu bloques tous ceux qui passent par n'importe quel proxy etc etc. TU n'as donc plus aucun multi compte dans ton jeu. Qu'est-ce qui m'empêche de dire à mon collègue de boulot, fan de JV, de se connecter à ton jeu tous les jours et de pusher MON pays ? On peut très bien imaginer un échange, moi je push son compte sur un autre jeu admettons.. Tu ne peux pas trouver de parade pour cela (autre qu'in-game), et pour l'avoir vu, ça existe vraiment Enfin, Citation :Si un joueur développe un moyen d'obtenir gratuitement des choses normalement payante, et en plus fait tourner le truc, cela peut nuire à l'activité...Si cela arrive, c'est que le jeu est mal pensé/codé.. Les outils développés par les joueurs ça existe,je sais, mais si ils arrivent à avoir des options payantes gratuitement, c'est que tu as loupé quelque chose, soit dans la conception soit une faille.. RE: bloquer une liste d'ip dynamique apache2 ? - SorenS - 08-01-2015 (08-01-2015, 03:52 AM)Argorate a écrit : Si un joueur développe un moyen d'obtenir gratuitement des choses normalement payante, et en plus fait tourner le truc, cela peut nuire à l'activité... On parle de 2 choses différentes la du coup. Bien sûr qu'il faut sécuriser les achats, protéger les failles etc... Pour les autres triches, du genre multi-compte etc... Je trouve que le mieux est effectivement de penser le jeu de façon à que ça ne soit pas profitable en ajoutant des règles in-games plutôt que des contrôles qui deviendrons vite obsolètes (a la façon adblock). L'une des solutions que j'aime bien c'est de mettre en place une surveillance des échanges. Imaginons qu'un type fasse une transaction d'un joueur à un autre d'un moment énorme sans avoir échangé un seul mp auparavant. Cela te lève une alerte en admin avec un rapport du genre : x argent échangée, 0 mp échangé, et listes des connexion/déconnexion sur la dernière semaine. Si tu t'aperçois par exemple que le compte A se déconnecte à 14h58 et que le compte B se connect à 14h59 et qu'ils ne sont jamais connectés ensemble ou au contraire tout le temps connecté ensemble tu es sûr (ou presque) d'avoir affaire à un tricheur. Ce genre de système là est quand même bien moins lourd à coder/maintenir à mon avis. RE: bloquer une liste d'ip dynamique apache2 ? - Xenos - 08-01-2015 Wow, ce pavé! tu défends un comportement laxiste selon moi, alors que moi je défend un comportement d'équité et de justice Ca pose clairement qui est le gentil et qui est le méchant :p Bon, je redeviens sérieux... Non, je ne remettrai pas en question ta vision des choses tant qu'elle touche tes jeux (c'est ton point de vue, ton domaine), c'est seulement que si je ne m'y plait pas, je n'irai pas. Oui, d'accord avec le "seuil d'acceptabilité" qu'on étend en pratique au ratio risque/récompense. Mais ici, ce n'est pas une différence de seuil, mais de définition: Ton approche est: 1) Le multi, c'est de la triche. 2) Je veux bloquer la triche donc je bloque le multi. Mon approche est: 1) Le multi ne permet pas de tricher dans mon gameplay 2) Je veux bloquer la triche donc je ne bloque pas le multi Egalement, la différence se situe sur les effets collatéraux: tu préfères fermer le système au plus de tricheurs possibles, quitte à bloquer des utilisateurs légitimes. Je préfère laisser le système ouvert, et réagir plus tard si les tricheurs gênent les joueurs. C'est plus AGILE comme approche, et cela oblige dès le départ à faire des codes extensibles, ce qui sera toujours bénéfique pour la durée de vie du projet (n'oublions pas que le projet n'existe, pour les joueurs, qu'une fois sorti en ligne). D'ailleurs, plus tu accepteras les effets collatéraux type bloquer 100% de TOR car 70% d'entre eux tricheraient plus tu bloqueras des utilisateurs légitimes, donc moins tu auras de joueurs (à la fois tricheurs et à la fois légitimes). Vaut-il mieux un jeu de 100 joueurs dont 2 tricheurs car trop de gens (tricheurs & légitimes) sont bloqués, ou un jeu de 1000 joueurs avec 50 tricheurs, sachant qu'on réagira après la sortie du jeu pour le corriger si besoin? Oui, mais jouer du multi-compte, est-ce vraiment de la triche au fond? Pour moi, la triche c'est violer les règles du jeu, mais dans ce qui nous préoccupe, je dirai plutôt que la triche c'est autoriser quelqu'un à faire quelque chose que les autres ne pourraient pas faire. Plus tu mets de mesure anti-multi-compte, plus il faut être expert pour tricher, et donc la triche favorise clairement un petit groupe de joueurs (les experts). Si le multi est ouvertement autorisé, alors tout le monde (même Maman) peut s'ouvrir plusieurs comptes et jouer avec ces comptes. En un sens, 0 contrôle permet alors d'avoir un jeu plus juste (100% des gens peuvent faire du multi) qu'un amas de contraintes qui feront que 97% des joueurs ne sauront pas faire de multi, alors que 3% sauront. En fait, en voulant faire régner la justice, tu finis par créer de l'injustice... Si le jeu est avantagé par la coopération, alors le multi-compte n'est pas si utile que cela si: • La coopération se fait en temps réel (dur de jouer en temps réel sur 10 comptes: ce serait comme jouer à 10 FPS en même temps) • Les coopérant font eux-même du multi compte: 10 joueurs avec chacun 10 comptes battront 1 joueur avec 20 comptes Donc même un jeu favorisant la coopération ne sera pas déterrioré si le multi est ouvertement et totalement autorisé. Pour ton exemple de simulation de l'UE, on pourrait imaginer qu'une personne soit présidente de deux pays (avec la double nationalité). En pratique, cela n'existe pas. Pas parce qu'on a un Dieu qui a mis des parades anti-multi-compte, mais parce que gérer deux pays de front, c'est irréaliste... D'où les fusions par mariage durant le Moyen-Age. Si un jeu de simulation de l'UE, j'autoriserai pour ma part le multi, en considérant qu'on ait une grande quantité de pays disponibles pour chaque serveur... Quoique même si je fais une simulation 100% réaliste (avec une 30taine de pays), j'autoriserai quand même le multi: si la personne veut contrôler tous les pays pour jouer toute seule, je la laisse faire. Plus on laisse de libertés, plus on permet l'émergence de nouvelles façons d'utiliser le jeu, ce qui lui offre la possibilité d'évoluer, et de survivre très longtemps. Pour l'aspect économique, c'est un soucis de business plan pour moi. Je considère personnellement que tout ce qui peut se monétiser, c'est ce qui est interne au serveur et n'en sort pas (car si cela sort du serveur, c'est la "propriété", en terme de droit moral et non de droit d'auteur, de l'utilisateur). Donc un joueur avec un multi, je préfère le voir comme quelqu'un qui devra payer 10x plutôt que comme quelqu'un qui aurait dû payer. D'ailleurs, si la personne préfère le multi au paiement d'une option, peut-être cela signifie-t-il que l'option payante n'est pas assez intéressante? Au fond, je préfère dire les gens n'achètent pas, donc j'améliore le truc que je veux vendre pour qu'ils l'achètent quand tu pars sur les gens n'achètent pas, donc j'ajoute des contraintes pour les faire acheter, comme si tu plombais ton produit gratuit au lieu d'améliorer le produit payant... Et si l'option se situe sur l'interface, ton business plan est voué à l'échec... Ce serait comme dire mon site est sécurisé car avant d'envoyer le formulaire, je vérifie en javascript que la valeur entrée est un nombre. Non. On ne sécurise un formulaire que coté serveur, en vérifiant que ce qu'il reçoit est bien un nombre. Le coté client, c'est un bonus d'ergonomie, un glaçage sur un gâteau. Tu peux vendre des options d'interface si tu veux, mais tu auras les mêmes problèmes alors que le piratage en général: les gens vont se passer le code Javascript au lieu de le re-payer. Note que la règle je refuse l'échange de A vers B si B est plus riche que A permet le sur-push: • B est plus riche que A, donc A ne peut donner à B • B donne tout à A (car B est plus riche, donc l'échange est autorisé) • A a tout reçu de B, donc A est devenu plus riche que B • A donne tout à B (car A est devenu plus riche que B donc A peut donner à B) • B a donc reçu ce que A possède tout en gardant ce qu'il possédait au départ. La règle à employer est A ne peut donner à B qu'au plus la différence de richesse d=A-B: si A est plus riche, d>0 donc a peut donner à B mais A ne peut pas donner plus que A-B, aka B ne pourra pas devenir plus riche que A. A ce moment-là, on ne pourra qu'avancer de front les 2 comptes, au lieu d'en sur-pusher un. Parfaitement d'accord avec l'exemple du collègue de bureau de Max: on n'a pas accès à qui est derrière l'écran (on ne sait même pas s'il existe), et encore moins à qui donne les ordres à celui qui est derrière l'écran... L'anti-multi semble voué à l'échec. L'idée d'une alerte en cas d'échange disproportionné, pourquoi pas. Mais dans ce cas, selon moi, la règle n'est pas multi interdit! mais échange disproportionné sans MP préalable interdit, ce qui me semble mal venu comme règle: les joueurs ont peut-être échangé par Skype. Ou bien le joueur qui a payé s'est fait piraté (et tu bloque donc le pirate et sa victime qui n'avait rien fait). Ou bien le joueur a juste voulu quitter le jeu sur un beau geste. Ou bien les deux jouent dans la même pièce depuis des années (même famille) et n'échangent pas par MP, mais oralement... |