0

En sortant votre jeu web, vous vous exposez à son rétro-engineering (les joueurs étudient votre jeu pour essayer d’en comprendre les mécanismes internes). Est-ce un problème? Faut-il lutter contre ce phénomène?

Le rétro-engineering peut-il tuer un jeu?

Non. Par exemple, le jeu d’échec et le jeu de go sont des jeux dont on connait parfaitement les règles (ils ont été “rétro-engineerés” en totalité), mais pour autant ces jeux ne sont pas morts et les bons joueurs de go battent la machine sans difficulté. Ce n’est donc pas parce que les joueurs ont rétro-analysé un jeu et qu’ils en connaissent toutes les règles et toutes les formules qu’ils pourront le gagner à tous les coups.

On peut parler de “rétro-engineering” dès l’instant où les joueurs essaient de comprendre les règles d’un jeu (et donc, de s’y intéresser) pour en tirer le meilleur parti (donc pour gagner).

Parallèle avec la sécurité

J’aime faire le parallèle entre la rétro-ingénierie d’un jeu et la rétro-ingénierie d’un système de sécurité: les systèmes de sécurité open source sont intégralement connus de tous (leurs sources sont connues de tous), mais cela n’a pas diminué leur niveau de sécurité (au contraire même, les systèmes de sécurité open-source sont réputés plus sûrs car connus de plus de monde, donc les failles sont plus vite trouvées). Le principe s’applique aussi sur un jeu web: la connaissance complète de ses mécanismes et formules devrait le rendre plus solide, plus riche et plus équilibré.

Ne tentez pas d’obfusquer votre jeu pour éviter le rétro-engineering: vous introduirez des bogues, vous ne pourrez plus vous relire, et votre jeu sera trop compliqué pour que les joueurs s’y intéressent.

Conséquences du rétro-engineering

Le rétro-engineering attire un nouveau public

Le rétro-engineering attire des joueurs-analystes qui viennent pour étudier le jeu plutôt que pour y jouer. Comme ces analystes aiment publier leurs résultats, le jeu gagnera en notoriété. Ce phénomène attire donc de nouveaux joueurs, venant de nouveaux horizons, et ayant donc un réseau d’amis différent des joueurs usuels: le champ des joueurs potentiels s’élargit, le nombre d’inscrits et l’activité du jeu augmentent alors.

Cela permet aux joueurs de s’approprier le jeu

S’ils s’approprient les mécanismes d’un jeu, alors les joueurs pourront mieux le comprendre, et leur expérience de jeu sera meilleure. Ils pourront aussi pousser les possibilités stratégiques d’un jeu le plus loin possible. Ils pourront alors proposer plus facilement de nouvelles idées (cohérente avec le mécanisme présent du jeu), et ils feront la promotion de ce jeu puisqu’ils ont participé à sa création en amenant leurs idées.

Des joueurs pratiquant le rétro-engineering sur votre jeu montrent que votre jeu les intéresse. Plus votre jeu sera riche, plus ces joueurs se passionneront pour son étude et son rétro-engineering.

Cela allège le travail de développement

Enfin, la rétro-ingénierie vous allège d’une partie de votre travail de créateur de jeu: inutile de faire vous-même des tests lourds pour savoir si le gameplay est équilibré, car les rétro-ingénieurs vont publier leurs résultats et leurs simulations. Vous aurez alors parfois des analyses très poussées d’un jeu, démontrant que tel ou tel point de gameplay génère tels impacts sur l’équilibre du jeu. En tant que créateur de ce jeu, vous pourrez alors vous appuyer sur ces analyses pour vérifier que le jeu est équilibré.

Conclusion

Non, le rétro-engineering d’un jeu n’est pas un problème, car c’est une composante de jeu qui permet d’amener de bonnes choses dans un jeu web. Je n’ai donc aucune difficulté à accepter le retro-engineering dans mes jeux, car je trouve que cela les enrichit. Si vous avez peur que le rétro-engineering tue votre jeu, revoyez votre gameplay pour l’enrichir au lieu de l’interdire, et attendez que les premières analyses voient le jour avant de tout verrouiller dans les conditions d’utilisation (voire dans vos codes).

Un jeu n’est pas tué par la rétro-ingénierie, mais par la pauvreté de son gameplay.

0