je voudrais savoir pour un jeu multijoueurs si il vaut mieu créer un socket par joueur dans le programme serveur ou si il vaut mieu en faire un seul en utilisant accept(); a chaque fois pour changer

ça dépend de ce que tu veux faire : il n´y a pas de formule magique, en réseau, c´est tout au cas par cas.
Pour ma part, pour ne pas m´embeter, je crée, en TCP, une socket d´écoute, et je fais des accept pour assigner une socket différente a chaque client.
Je m´en contente, mais ça se discute

ca risque pas de prendre enormément de puissance de créer un socket par joueur(max 10 a 20)? sinon, je ferai ca, ca sera beaucoup plus simple.

En fait il me semble que les sockets sont réutilisables donc il doit y avoir moyen d´en gagner à ce niveau la

oui mais si je demande au niveau de la puissance, c´est parce que en utilisant la technique que disait jyy ( et que j´utilisait quand je faisait mais petits programmes pour apprendre a utiliser les socket) mais je n´ai jamais tester plus de 3 connections socket en meme temps et j´ai peur que ca prenne toute la puissance du pc.
sinon, on peut utiliser un meme socket mais c´est plein de compliquation pour savoir de 1 quel joueur m´envoit les données, de 2 le programme hote devra attendre que le programme client le contacte pour lui envoyer les données,...

Je ne suis pas sur que ça ralentisse tant que ça : bien que, moi aussi, je n´ai pas ouvert des milliers de sockets d´un coup encore ( un jour j´essaierai)
Bon, si tu ouvres autant de socket que de clients, l´idéal est de faire autant de threads différents, indépendants.
Tu vas me dire : oula ! mais ça ralenti tout ça ?
Et la je répondrais non, car les threads, 99% du temps ( meme +) seront en attente dans le read.
Et il faut savoir qu´un read ne bloque pas le CPU, s´il n´y a rien, il reschedule.

ok, je le ferai avec les thread, c´est sans probleme, donc je peux programmer la partie multijoueurs de mon jeu video