28-04-2014, 04:26 PM
TL;DR
• Une interface pour créer son propre robot pourrait être une façon de monétiser ces derniers
• Le gameplay pourrait autoriser les robots (récompense du plus futé)
• L'analyse des comportements de jeu permet de repérer les bots.
Monétiser les bots
A voir, car le gameplay pourrait intégrer la possibilité, pour les joueurs, de se créer des bots. Par exemple, une option (payante ^^) permettrait l'accès à une API et à une interface permettant de créer son propre "robot", sur la base de jeux de règles. Cela déporte le jeu de l'action "point & click" vers la réflexion et la planification (comprendre le jeu suffisamment pour être capable d'établir ses règles de bot).
Contrer sur le gameplay plutôt que contrer directement le bot
Ici, à mes oreilles, c'est comme si Renault râlait que d'autres garages pouvaient réparer leurs voitures. On peut se dire "c'est chiant, je perd du chiffre d'affaire!" et faire comme Apple (tout verrouiller), ou se dire "c'est cool, j'ai un super argument de vente: en cas de pépin, on pourra réparer sa voiture n'importe où!".
Revoir son modèle économique plutôt que de cracher sur les robots peut donc être une option envisageable. D'autant que les "bouts de scotch" techniques, aka les pseudo-sécurités, seront toujours passables un jour ou l'autre par des robots, alors qu'un modèle économique peut supprimer les problèmes que causeraient les robots.
C'est un peu comme ceux qui avancent le captcha comme anti-spam: les robots spamment automatiquement les forums, le captcha interdit les robots, donc le captcha interdit le spam. C'est un paralogisme. Ce qu'on cherche à faire, c'est empêcher le spam, pas bloquer les robots.
Ici, cherche-t-on vraiment à empêcher les robots? ou cherche-t-on plutôt à rendre le jeu équitable pour tous, peu importe ses compétences? Il me semble qu'on est plutôt dans la seconde option (d'ailleurs, je ne suis pas d'accord avec cette approche, mais bon).
Bloquer les robots
Si je centre sur le problème "empêcher les robots", au vu de la construction du web, il est impossible de se baser sur les requêtes reçues. C'est comme si on voulait empêcher une class "Bar" d'utiliser une classe "Foo" simplement en se basant sur ce que la classe "Foo" reçoit comme message.
• Le nombre de requêtes par seconde est intéressant, mais si on a un jeu à multi-onglets (autorisant les joueurs à ouvrir plusieurs onglets sur le jeu, ce qui est d'ailleurs une excellente possibilité car plus le nombre d'onglets ouverts est grand, plus le joueur sera marqué par l'expérience de jeu) alors la limite s'élève (on peut sauter d'un onglet à l'autre, et les ordres/requêtes fusent vite).
J'aime bien l'ancien système de youtube (l'ont-ils toujours, je n'en sais rien, car grâce à Google+ je n'arrive même plus à commenter/liker une vidéo): si le nombre de commentaires dans un intervalle de temps est important, un captcha apparait. Cela permet de limiter en partie la robotisation, sans emmerder les utilisateurs lambdas (qui ne verront jamais ou rarement le captacha apparaitre; d'ailleurs, cela peut être satisfaisant de se dire "eh, je joue tellement vite qu'on dirait une machine!").
• Le changement de méthode ne doit pas se traduire par un changement d'interface pour les joueurs: ils en auront vite marre de perdre de vue les boutons. D'ailleurs, ce genre de système sera facilement contourné avec une lecture du code source par le créateur du robot.
• Egalement, la comparaison des habitudes de jeu sera un outil très puissant. Le principe mathématique consisterait à construire un espace à N dimensions où les données des joueurs seraient représentés. Ensuite, un opérateur de comparaison et des opérateurs de moyennes permettraient de synthétiser la probabilité qu'un joueur soit un robot.
En terme plus pragmatique, cela reviendrait à prendre un certain nombre de paramètres, et à chercher les joueurs dont les profils sortent du lot. Ces joueurs seront peut-être des robots, ou alors, ils partageront peut-être leur compte avec d'autres (exemple: en moyenne, les joueurs passent entre 30 et 40 minutes par jour sur le jeu, mais un des joueurs passent 15h/jour: c'est peut-être un robot, ou un super accroc; un autre joueur passe 24h/24 sur le jeu, c'est donc surement un robot).
Le gameplay pour humain
Une dernière piste est de constituer un jeu dont la complexité n'est pas adaptée aux machines. Par exemple, on a conçu depuis longtemps (1997) des robots capables de battre l'humain aux échecs. En revanche, pour le jeu de Go, aucun robot n'écrase les bons joueurs. Il faut peut-être creuser de ce coté-là, et offrir un gameplay suffisamment riche pour ne pas être facilement mis en équations simples, avec une combinatoire (nombre de possibilités) importante.
• Une interface pour créer son propre robot pourrait être une façon de monétiser ces derniers
• Le gameplay pourrait autoriser les robots (récompense du plus futé)
• L'analyse des comportements de jeu permet de repérer les bots.
Monétiser les bots
Citation :chose qui bien sûr est totalement abusif
A voir, car le gameplay pourrait intégrer la possibilité, pour les joueurs, de se créer des bots. Par exemple, une option (payante ^^) permettrait l'accès à une API et à une interface permettant de créer son propre "robot", sur la base de jeux de règles. Cela déporte le jeu de l'action "point & click" vers la réflexion et la planification (comprendre le jeu suffisamment pour être capable d'établir ses règles de bot).
Contrer sur le gameplay plutôt que contrer directement le bot
Citation :qui est même de la fraude si on concidère que la plus part du temps, on vend l'automatisation de certaines taches, les robots sont donc une plaie à tout point de vu.Légalement, ce ne serait pas une fraude (le robot est plutôt un concurrent), mais c'est vrai que certains jeux vendent ce genre de "raccourcis". Mais si le jeu se fait marcher dessus par ces "créateurs de robots", alors le jeu ne vend pas un morceau du jeu: le jeu vend quelque chose que n'importe qui d'autre serait en mesure de faire.
Ici, à mes oreilles, c'est comme si Renault râlait que d'autres garages pouvaient réparer leurs voitures. On peut se dire "c'est chiant, je perd du chiffre d'affaire!" et faire comme Apple (tout verrouiller), ou se dire "c'est cool, j'ai un super argument de vente: en cas de pépin, on pourra réparer sa voiture n'importe où!".
Revoir son modèle économique plutôt que de cracher sur les robots peut donc être une option envisageable. D'autant que les "bouts de scotch" techniques, aka les pseudo-sécurités, seront toujours passables un jour ou l'autre par des robots, alors qu'un modèle économique peut supprimer les problèmes que causeraient les robots.
C'est un peu comme ceux qui avancent le captcha comme anti-spam: les robots spamment automatiquement les forums, le captcha interdit les robots, donc le captcha interdit le spam. C'est un paralogisme. Ce qu'on cherche à faire, c'est empêcher le spam, pas bloquer les robots.
Ici, cherche-t-on vraiment à empêcher les robots? ou cherche-t-on plutôt à rendre le jeu équitable pour tous, peu importe ses compétences? Il me semble qu'on est plutôt dans la seconde option (d'ailleurs, je ne suis pas d'accord avec cette approche, mais bon).
Bloquer les robots
Si je centre sur le problème "empêcher les robots", au vu de la construction du web, il est impossible de se baser sur les requêtes reçues. C'est comme si on voulait empêcher une class "Bar" d'utiliser une classe "Foo" simplement en se basant sur ce que la classe "Foo" reçoit comme message.
• Le nombre de requêtes par seconde est intéressant, mais si on a un jeu à multi-onglets (autorisant les joueurs à ouvrir plusieurs onglets sur le jeu, ce qui est d'ailleurs une excellente possibilité car plus le nombre d'onglets ouverts est grand, plus le joueur sera marqué par l'expérience de jeu) alors la limite s'élève (on peut sauter d'un onglet à l'autre, et les ordres/requêtes fusent vite).
J'aime bien l'ancien système de youtube (l'ont-ils toujours, je n'en sais rien, car grâce à Google+ je n'arrive même plus à commenter/liker une vidéo): si le nombre de commentaires dans un intervalle de temps est important, un captcha apparait. Cela permet de limiter en partie la robotisation, sans emmerder les utilisateurs lambdas (qui ne verront jamais ou rarement le captacha apparaitre; d'ailleurs, cela peut être satisfaisant de se dire "eh, je joue tellement vite qu'on dirait une machine!").
• Le changement de méthode ne doit pas se traduire par un changement d'interface pour les joueurs: ils en auront vite marre de perdre de vue les boutons. D'ailleurs, ce genre de système sera facilement contourné avec une lecture du code source par le créateur du robot.
• Egalement, la comparaison des habitudes de jeu sera un outil très puissant. Le principe mathématique consisterait à construire un espace à N dimensions où les données des joueurs seraient représentés. Ensuite, un opérateur de comparaison et des opérateurs de moyennes permettraient de synthétiser la probabilité qu'un joueur soit un robot.
En terme plus pragmatique, cela reviendrait à prendre un certain nombre de paramètres, et à chercher les joueurs dont les profils sortent du lot. Ces joueurs seront peut-être des robots, ou alors, ils partageront peut-être leur compte avec d'autres (exemple: en moyenne, les joueurs passent entre 30 et 40 minutes par jour sur le jeu, mais un des joueurs passent 15h/jour: c'est peut-être un robot, ou un super accroc; un autre joueur passe 24h/24 sur le jeu, c'est donc surement un robot).
Le gameplay pour humain
Une dernière piste est de constituer un jeu dont la complexité n'est pas adaptée aux machines. Par exemple, on a conçu depuis longtemps (1997) des robots capables de battre l'humain aux échecs. En revanche, pour le jeu de Go, aucun robot n'écrase les bons joueurs. Il faut peut-être creuser de ce coté-là, et offrir un gameplay suffisamment riche pour ne pas être facilement mis en équations simples, avec une combinatoire (nombre de possibilités) importante.