I. Préambule

Premier dev blog officiel sur Crypto.Inc et on attaque avec du lourd avec une feature du jeu qui est ma foi plus qu’importante puisqu’il s’agit du clic manuel.

II. Une fonctionnalité simple à créer mais difficile à équilibrer

Cette feature pourtant très simple m’a donné du fil à retordre non pas sur l’aspect code ou programmation, mais plutôt sur l’aspect de l’équilibrage.

Le système d’origine était que le rendement du clic était totalement indépendant du rendement des bâtiments. Le problème est que, malgré les upgrades du rendement, on se retrouve vite avec ces deux situations :

– Soit le clic donne beaucoup plus que ce que donne le rendement global et dans ce cas-là ça le rend beaucoup trop cheaté.

– Soit le clic donne une somme ridicule par rapport au prix des différents bâtiments/upgrades.
J’ai donc dans un premier temps décidé de donner un pourcentage du revenu global pour chaque clic.
Le résultat était satisfaisant, car le clic avait un réel impact sur le revenu gagné. Seulement, cela soulevait un problème déjà présent mais que j’avais ignoré jusque là : les tricheurs, ces petits malins qui utilisent des logiciels de triche souvent utilisés dans le monde des « clickers », les « auto clickers ». Ces petits logiciels qui permettent de simuler le clic de la souris (ou le tapotement de l’écran d’un téléphone) et qui permettent donc d’abuser du clic au point qu’il est très facile de finir le jeu.

GIF

Mon premier choix est de faire un système simple qui calcule le nombre de clics en 1 seconde et si celui-ci dépasse un certain seuil je bloque la possibilité de cliquer pendant x minutes.
Choix très naïf ! Imaginez que vous publiez la mise à jour avec votre anti-cliker tout neuf et quelque temps plus tard, un joueur légitime vous dit que votre anti-clicker l’a détecté comme tricheur parce qu’il a cliqué trop vite et sans tricher. Et c’est très difficile de trouver un juste milieu à la limite de CPS (nombre de clics par seconde).

Finalement, il m’est venu une dernière idée. Sur un autre clicker auquel j’ai beaucoup joué pendant ma période de veille : Egg. Inc (on y reviendra dans un futur article). Sur ce jeu où le principe est de créer le plus d’œufs possible, cliquer permet d’ajouter des poules dans les enclos. Et ce clic est limité dans le temps, c’est-à-dire qu’on peut cliquer sans s’arrêter pendant 15s maximum, il faut ensuite attendre que la barre se recharge un minimum pour pouvoir recommencer à cliquer.

J’ai donc rajouté cette fonctionnalité au jeu.

III. Signes et feedbacks

Ce qui est très important dans un jeu en plus d’avoir des boucles de gameplay satisfaisants, ce sont les « signes et feedbacks« .

<Moment wikipédia> 

Les signes et les feedbacks sont des informations qui permettent aux joueurs de comprendre ce qu’il se passe autour d’eux, ce qu’ils doivent faire, ne pas faire et ce qu’ils peuvent faire.

</Moment wikipédia> 

Il fallait donc trouver quelque chose pour indiquer au joueur que le temps de clic est limité. Vu l’interface du jeu et son thème, j’ai tout de suite pensé à un système de surchauffe avec un thermomètre dont la jauge monte lorsque l’on approche du temps de clic maximum possible.

 

Seulement, ajouter un thermomètre rend un peu lourd l’interface et c’est un joueur qui m’a proposé de garder l’idée de la surchauffe mais de l’adapter pour qu’elle fonctionne sur le bouton représenté par une pièce. La pièce change petit à petit de couleur avec de la fumée qui s’en dégage en même temps.

Le résultat est plutôt cool :

C’est tout pour ce premier dev blog ! Si vous l’avez aimé, n’hésitez pas à laisser un commentaire ! Et si vous voulez essayer en exclusivité Crypto. Inc , vous pouvez me contacter par mail gatitostudio@gmail.com en me renseignant l’adresse mail que vous utilisez sur votre téléphone android pour le google play store.

 

Catégories : DevBlog

0 commentaire

Laisser un commentaire

Avatar placeholder

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *