Logging

[joshua]

Un nouveau débat qui me travaille depuis plusieurs jours, c'est celui du logging dans un jeu.
Beaucoup de monde code s'en gérer cetet partie qu'il revient ensuite d'ajouter par petites touches.
Moi je pense qu'un systeme de trace doit faire aprtie de la conception d'un jeu.
Maintenant, que tracer?

• tracer les actions de certains joueurs selon des listes de "criticité", avec un auto increase en cas de manoeuvre suspecte qui revient a la normale au bout de plusieurs jours?
  
• tracer les accès à la BDD
  
• tracer les connxions au jeu, les erreurs de login
  
• tracer les tranasctions ingame
  
• tracer les messages échangés
  
• tracer les changements de pseudo
  

J'attends vos idées pour etendre cette liste. Une partie de la reflexion peut assi porter sur la méthode de tracage (des bouts de code? une classe de gestion de logging?), et sur l'emplacement du tout (Table spécifique? base spécifique?)

[Sephi-Chan]

Lors ce que j'avais réalisé une petite classe Compte pour m'initier à l'objet, j'avais également créer à côté une classe Logs pour apprendre à utiliser les méthodes statiques. Cette classe, qui était la première à être chargée dans la page, permettait, dans toutes les autres classes, d'appeler Log::add().

Cette méthode me permettait de créer un log XML contenant le compte de l'erreur, l'ip utilisée et un indice de menace, ainsi que l'heure et un commentaire.

Ainsi, lors de la connexion, je faisais quelque chose comme : Log::add(1, 'Connexion'); pour indiquer le niveau de menace (arbitraire) et le commentaire, ici j'indique qu'on log une connexion. Les autres paramètres sont mis automatiquement.

Pour les actions qui génèrent des erreurs comme un caractère invalide dans un nom, l'indice de menace est faible. Quand l'erreur survient sur une action qui ne peut être effectuée avec une navigation normale, l'indice est bien plus haut, et encore plus haut pour des tentatives de détournement de données.

J'avais donc des log sur toutes les actions : à la connexion, à la déconnexion. Ensuite, je pouvais faire en sorte de mettre un niveau du surveillance à chaque membre : Le système n'enregistrait alors que les erreurs dont l'indice était supérieur à l'indice de surveillance du membre.


Sephi-Chan

[Roworll]

si tu souhaites faire des fichiers de log, autant utiliser la méthode la plus rapide possible : de simples fichiers texte.
Inutile de charger le moteur de BDD ou de faire bosser PhP plus que de raison.
Avec les fonction de gestion de fichier, on peut s'en sortir facilement.
De plus, avec un format CSV, tu peux ensuite importer le résultat dans Excel pour une analyse plus détaillée.

Quand à savoir ce qu'il faut mettre dedans, c'est à toi de savoir ce que tu recherche.
Log de connection pour traquer les multicomptes
Log des erreurs de l'application (via une gestion d'erreur potable) pour suivre les plantages divers
Log des tentatives ratées de connexion... très utile pour chopper les types qui tentent de voler les comptes.

etc.

[X-ZoD]

mais comment vous y prenez vous pour tacer ?

[joshua]

Justement, j'ai posté ce débat dans la partie professionnalisation pour que l'on liste ce qui peut etre fait, avant d'ecrre un article a ce sujet sur le wiki.
Je pense que ce genre de débat est plus qu'utile pour gérer un point bien souvent négligé lors du développement...

[X-ZoD]

en effet .. du coup moi je ne vois pas ce que l'on pourait tracer d'autre

[Sephi-Chan]

Ben, tu traces les échanges d'objets/argent/autre entre les joueurs, en faisait quelque chose de plus pointus que ce que je proposais. Genre tu fais un log dédié aux échanges dans laquelle tu indique l'identifiant (et pourquoi pas le nom, pour la lisibilité), les objets (au sens large) de l'échange, les IP et l'heure de l'échange. Avec ça, tu peux détecter des échanges un peu frauduleux, des arnaques, etc.

L'avantage du XML est que tu peux directement faire un renvoi (par XSLT) du fichier, et ordonner comme bon te semble, ne sélectionner que les échanges de tel ou tel joueurs, et tout autre filtre avec un petit Javascript.


Sephi-Chan, et ça c'est cool !

[pascal]

je suis d'accord sur l'ensemble de ce qui est dit, mais attention tout de même :

la meilleure façon de tricher, c'est de respecter les régles.

si on sait ce qui est contrôlé, on respecte scrupuleusement tout ça, et hop, ni vu ni connu on en profite.

c'est utilisé un peu partout :
_ les ados qui ont de bonnes notes, un comportement sociable à l'école, font leurs devoirs, n'ont pas de piercing, ne sont pas gothiques... mais boivent & + le week end quand les parents ont le dos tourné
_ prison break
_ tout ce qui a trait au droit
_ la SG ( mouarf ! )

dès que le montage devient complexe, ça devient difficile de détecter la triche.

je pense qu'il faut :
_ du logging
_ des spécifications, détaillant toutes les régles sur les données
_ un codage de chaque régle dans les fonctions / classes
_ des tests unitaires, pour vérifier ce que font les fonctions / classes, et que c'est fait correctement
_ utiliser des tricheurs : leur dire ce que fait le script, ce qui est vérifié et leur demander d'imaginer des triches possibles
_ éviter GET, pour éviter les lammerz
_ vérifier tout ce qui vient de l'utilisateur
_ tricher sur d'autres jeux

A+

Pascal

[keke]

Perso, j'ai mis un environnement de test, et j'ai lâché des amis, sensibilisé à la triche en leur demandant de foutre cet environnement en l'air.

J'en ai eu pour plusieurs mois de travail pour corriger et blinder le jeu.
Depuis que le jeu s'est étoffé de nouvelles fonctionnalité, je pense que je pourrais recommencer.

Kéké.

[Loetheri]

Je crois que pascaltje a donné un bon indice pour savoir ce qu'il faut vérifier et ce qu'il ne faut pas vérifier, c'est-à-dire tricher sur d'autres jeux.

Personnellement, c'est mon cas. Je n'hésite pas à tricher et à tester de nouvelles solutions. En général, les façons de triche sont relativement limitées mais parfois plus complexes qu'on ne pense ;-)

En théorie, il faut se méfier des joueurs. Si on applique cela à la règle et partout, tout est réglé ^^