Discussion :

[onilink_]

Bonjour, ou plutôt bonsoir,

je code actuellement un jeu de plateforme, et j'aimerais bien implémenter la partie réseau avant que le moteur ne soit pas trop avancé (histoire de ne pas avoir trop de choses a revoir).

Je suis novice en programmation réseau, et en threads (mais je maîtrise un minimum les sockets), c'est pour cela que je viens demander conseils avant de me lancer dans le cambouis.

Histoire de commencer pas trop violemment, j'ai programmé un pong deux joueurs, a l'aide de threads pour récupérer les données de l'autre joueur. Le soucis, c'est que j'ai l'impression de m'être planté quelque part car si mon client et mon serveur utilisent chacun un thread, le jeu plante (alors que si j'ai un thread sur soit le client, soit le serveur ça marche, mais du coup seul un joueur peut bouger des deux cotés).

Sachant que je vise un jeu en réseau 4 joueurs (mais si j'y arrive pas 2 joueurs ce serait déjà bien cool), temps réel, quel architecture me conseillerez vous? Suis-je obligé de passer par des threads? (j'ai pas réussi sans a vrai dire).

Pour ce qui est de mon architecture actuelle (sur mon pong) c'est:
Serveur:
Un thread pour récupérer les informations de la batte du joueur 2
Chaque step du jeu j'envoie les coordonnées de la balle et de la batte du joueur 1
Le serveur gère les collisions, le score, etc...

Client:
Un thread pour récupérer les informations de la batte du j2 et de la balle.
Chaque step du jeu il envoie les coordonnées de la batte.

Du coup si je suit cette logique, pour mon jeu 4 joueurs je vais me retrouver avec 3 threads sur le serveur. J'ai vraiment pas l'impression que ce soit le mieux, sachant que j'ai du mal a les bien gérer et que je sais pas trop quand placer des mutex...

Si quelqu'un a un peu de temps a me consacrer je le remercie d'avance, et sur ce bonne soirée a tous!

[imperio]

En general j'aime bien threader les sockets lorsqu'il n'y en a pas beaucoup a gerer (des clients en gros). Par-contre j'utilise select des que le nombre de sockets a gerer devient plus important (donc des serveurs generalement). Dans ton cas il n'y a que 2 joueurs donc ca ne changera pas grand chose.

Histoire de commencer pas trop violemment, j'ai programmé un pong deux joueurs, a l'aide de threads pour récupérer les données de l'autre joueur. Le soucis, c'est que j'ai l'impression de m'être planté quelque part car si mon client et mon serveur utilisent chacun un thread, le jeu plante (alors que si j'ai un thread sur soit le client, soit le serveur ça marche, mais du coup seul un joueur peut bouger des deux cotés).

Ca c'est pas un souci, c'est juste que tu l'as mal code. As-tu regarde les mutex pour eviter des acces concurrents sur tes donnees ?

Pour ton architecture serveur je l'aurais vu comme ca :
- une classe Client avec un id, une position, un score
- une classe Balle avec une position

Apres libre a toi de threader ou non, dans le cas present ca n'a pas une grande importance...

A chaque fois que la balle bouge tu envoies la nouvelle position a tes clients. Par-contre je pense pas que threader l'envoi des donnees soit tres utile...

[onilink_]

Bonjour,
select c'est pour le multiplexage c'est bien ça? De cette façon il n'y aurais donc plus besoin d'utiliser de threads? Je pense que je vais me pencher sur ça, car cela a l'air quand même plus pratique :p
Juste comme ça, ça changerais quelque chose niveau perfs (genre un peu, beaucoup)? Car logiquement sur un dualcore si j'ai un thread en plus ça devrait être plus rapide...

Pour ce qui est des mutex j'en ai bien placé, c'est pour ça que je comprend pas trop ce qui fait freezer :p
A moins que je les ai mal mis... (voila aussi pourquoi j'aimerais me passer de threads).

Sinon oui je n'ai pas utilisé de thread pour envoyer les données donc ça va.

Merci pour les réponses en tout cas :p

[imperio]

Dans le cas present ca ne changera strictement rien au niveau des perfs. Pour voir ou ca coince, utilise un debugger (style gdb).

Les threads sont relativements simples d'utilisation du moment qu'on sait ce que l'on fait si je puis dire.