Bonjour,

Je souhaite réaliser un petit projet pour monitorer les joueurs sur un serveur de jeu fps pour repérer des comportements qui indiquent l'utilisation d'un aimbot ( http://en.wikipedia.org/wiki/Aimbot ).

A la base, il y a une instance de classe qui permet de modifier le fonctionnement d'une partie (ServerMonitor). A partir de là, une instance (PlayerSelector) va observer les joueurs et renvoyer une référence vers l'un deux si un comportement précis est décelé. Une troisième instance (PlayerChecker) pourra être lancée en utilisant cette référence pour effectuer des vérifications plus précises et éventuellement enregistrer des données dans un log.

La classe qui représente un joueur ne peut être altérée alors un pattern observer n'est pas possible mais la plupart des attributs de cette classe sont en accès public.

Et c'est là que je m'embrouille les pinceaux. Est-ce que je devrais centraliser les référence vers chacune des classes "modules" dans ServerMonitor ou y aurait-il une manière plus élégante de procéder ?

Voici un diagramme de classes pour représenter cela.

Salut,

Pas de réactions à ce sujet ? J'ai hésité avant de poster cette question car tout ce qui concerne les jeux vidéos ça ne semble pas être pris au sérieux (du moins c'est l'impréssion que j'ai et j'hésite franchement à le mentionner sur mon cv).

En clair, l'alternative est d'avoir une référence d'un PlayerChecker dans PlayerSelector. Avec cette approche, c'est le module PlayerSelector qui coordonera le tout et le ServerMonitor servira de simple classe Main ou point d'entrée. Toutefois, certains appels devrons tout de même passer par ServerMonitor pour communiquer avec le jeu.

Heuuu...
Disons que je connais bien quelques membres éminents de ce forum et là, comme ça, je ne vois pas qui dans le groupe des habitué pourrait aider dans ce domaine précis.

Tu remarqueras que personne n'est venu te dire "on s'en fout des jeux vidéo". Il y a juste qu'on ne sait pas aider dans ce domaine là.

Un visiteur de passage aura peut-être une réponse, mais du coup, c'est moins rapide comme réaction.

Merci pour ton intervention. C'est vrai que la communauté est plus réduite que sur un site comme developpez.com. L'avantage, par contre, c'est qu'on peut discuter sur des termes plus familiers.

Puis, peut être que je me casse la tête pour pas grand chose . J'ai juste ce soucis d'appliquer des bonnes pratiques dans tout ce que je fais histoire que cela devienne un réflexe comme dans ce cas où j'ai pris la peine de réaliser un schéma.

Pour les aprioris concernant les jeux vidéos, c'est juste une impréssion personelle. Je vais demander certains contacts ce qu'ils en pensent. C'est pourtant ça qui m'a orienté vers le Java vu les similitudes dans le langage.

C'est sûr, on est pas sur dvp, mais on m'a déjà soufflé dans l'oreille que l'ambiance n'y est plus vraiment parfaite, leadership foireux toussa. Enfin soit

Les bonnes pratiques, après 10 ans c'est tellement loin que bon... pas les bonnes pratiques, mais la terminologie et le fait de passer 10j à faire un diagramme parfait alors qu'en pratique en 1 journée ton programme était fini... ça oui
Parce qu'on a l'habitude de te forcer à l'école à faire ça pour tout alors que dans la pratique parfois c'est contre productif et de "chier" un code en 1j pour le montrer au client et discuter autour du prototype est tellement plus intuitif que ça.

Enfin, loin de moi l'idée de te décourager de le faire hein, juste qu'il faut voir le positif de chaque méthode et essayer de prendre un peu de recul

Pour le domaine des jeux vidéos, la moyenne d'âge est un rien plus élevée pour le moment ici, mais les gamers sont bienvenus, tant qu'ils sont plus évolués que "kikoo lol", tout le monde qui parle d'IT et assimilé est bienvenu

Le dev de jeux vidéo est un domaine extrêmement pointu, donc moi perso je verrais ça d'un très bon oeil sur un CV C'est pas comme si tu mentionnais "joue à wow" dans tes loisirs

Bah, c'est surtout que pour 6 classes, dont visiblement une est déjà fournis par le jeu, je ne vois pas vraiment l'intérêt d'un tel diagramme. Soit il a tout un tas de logique qui va s'ajouter en dehors et ça maque du contexte pour pouvoir répondre réellement, soit y a tout l'info là, et faire 2-3 prototypes aurait déjà donné la solution naturelle.

Tu as raison. Tout dépend de la logique. J'hésitais car je partait du principe que la classe centrale a un rôle directeur par rapport à des classes satellites. Si ça semble vague, imagines un aggrégateur RSS écrit en Java qui lance des threads pour récupérer des XML sur des sites distants. En fait, la classe centrale peut tout simplement servir de point d'entrée sans qu'on y trouve la moindre logique de contrôle.