Gestion multijoueur pour un jeu en C

[Gandalf 13]

Bonjour a tous!

Alors voila, je vous expose mon problème: il s’avère que, avec mes amis et dans le cadre de mes études, je suis amené a faire un jeu sous Linux qui comportera un mode multijoueur. Or, je me charge de la gestion réseau du jeu justement. Je n'y connaissais rien au début, cependant, j'ai déjà appris un peu sur les sockets et j'ai réussi a faire se connecter un serveur et un (plusieurs) client(s) sur deux (plusieurs) pc différents pour envoyer un message.
Sauf que maintenant, je ne sais plus comment faire. Pour que les deux joueurs puissent se voir sur le-dit jeu, comment faire? Que dois-je utiliser? On m'a parlé de threads, cependant, je ne vois pas vraiment le rapport... Donc voila, si vous pouviez m'éclairer, ca serait sympa, merci :)
Au passage, le jeu (qui est une sorte de survival pour le moment) est réalisé sous Linux donc, avec la SDL, en C, et est donc un programme fenêtre (normalement, si je ne dis pas de bêtises...). Voila, si vous avez besoins d'autres informations...

Merci d'avance pour vos réponses :)

[Dlzlogic]

Bonjour,
Si j'étais à votre place, je me servirais d'un fichier unique comme intermédiaire.
Chaque joueur peut lire le fichier, donc la situation actuelle est visualisée.
Lorsqu'un joueur agit, son programme envoie un ordre sur le fichier. Donc celui-ci est à jour à tout moment.
Le programme doit contenir une fonction d'écriture, une fonction de lecture, avec un timer éventuellement, et une fonction de nettoyage-rafraichissement.
Ca peut paraitre un peu lourd, il y peut-être d'autres solutions, mais celle là me parait simple à mettre en oeuvre, et certainement très efficace.
La solution de SGBD serait envisageable aussi, mais dans votre contexte, ça me parait plus compliqué et moins intéressant à faire.

[Gandalf 13]

Bonjour,
Si j'étais à votre place, je me servirais d'un fichier unique comme intermédiaire.
Chaque joueur peut lire le fichier, donc la situation actuelle est visualisée.
Lorsqu'un joueur agit, son programme envoie un ordre sur le fichier. Donc celui-ci est à jour à tout moment.
Le programme doit contenir une fonction d'écriture, une fonction de lecture, avec un timer éventuellement, et une fonction de nettoyage-rafraichissement.
Ca peut paraitre un peu lourd, il y peut-être d'autres solutions, mais celle là me parait simple à mettre en oeuvre, et certainement très efficace.

Un fichier unique comme intermédiaire? Ce serait alors le serveur qui ferait tous les calculs ainsi que le reste? Je pensais plutôt que chacun aller lancer le jeu, mais je ne savais pas vraiment comment faire la relation entre tous après...

La solution de SGBD serait envisageable aussi, mais dans votre contexte, ça me parait plus compliqué et moins intéressant à faire.

C'est quoi la solution de SGBD? Je n'en ai jamais entendu parler...

[Dlzlogic]

Voilà comment j'imagine les choses.
Les différentes machines sont en réseau. Il n'y a pas de serveur, d'ailleurs c'est une notion que je connais mal.
Chaque machine possède le programme de jeu, identique pour tout le monde.
Lorsque le premier joueur ouvre son jeu, le programme cherche le fichier commun situé sur une machine, soit toujours allumée, soit sur celle du premier joueur. S'il n'existe pas, il le crée.
Le joueur constate qu'il est le premier, passe un coup de fil à un copain, celui-ci ouvre son jeu. Le programme constate que le fichier a été crée, donc le jeu peut commencer.
Chaque nouveau joueur s'introduit dans le jeu, et utilise le fichier unique.
Sur le fichier, les joueurs sont identifié par un code, le code machine, le numéro d'ordre de participation, tout ce qu'on veut.

Ce genre d'organisation n'est pas difficile à réaliser puisqu'il ne fait pas appel à des notions compliquées. Le problème de liaison étant résolu, il ne s'agit plus que d'adresser un fichier situé sur une machine déterminée.

Les SGBD. Ca veut dire Système de Gestion de Base de Données. Au pif, 2 SGBD connus Oracle et MySql.
Pour vous donner un exemple. Mon site fait des calculs d'assainissement. Là on est dans un contexte serveur, puisque c'est Online qui m'héberge.
Chaque membre, lorsqu'il se connecte, a accès à un espace réservé de la base de données. Il peut y avoir autant de visiteurs connectés en même temps, sa,s qu'ils ne se marchent sur les pieds, mais il n'y a qu'une seule base.
Dans certains cas (contexte universitaire) nous sommes deux à pouvoir regarder ce qu'ils font.

Je viens d'avoir une conversation téléphonique et il semble que la solution du SGBD est à préférer.

à suivre.

[fatal_error]

salut,

Si j'étais à votre place, je me servirais d'un fichier unique comme intermédiaire.
Chaque joueur peut lire le fichier, donc la situation actuelle est visualisée.
Lorsqu'un joueur agit, son programme envoie un ordre sur le fichier. Donc celui-ci est à jour à tout moment.
Le programme doit contenir une fonction d'écriture, une fonction de lecture, avec un timer éventuellement, et une fonction de nettoyage-rafraichissement.
Ca peut paraitre un peu lourd, il y peut-être d'autres solutions, mais celle là me parait simple à mettre en oeuvre, et certainement très efficace.

L'idée est bonne, mais par l'intermédiaire d'un fichier, c'est une abération.
La position d'un joueur, pas besoin de la stocker dans un fichier, en mémoire est suffisant.

Le fichier, on l'utilise pour les accès moins fréquents (comme la sauvegarde du joueur par exemple).

La solution de SGBD serait envisageable aussi, mais dans votre contexte, ça me parait plus compliqué et moins intéressant à faire.

le sbgd c'est pour la bdd, wikipedia. C'est useless dans un premier temps...surtout si c'est votre premier jeu.

Pour ce qui est des threads et multi threads, jvais pas te faire un cours yen a sur le net. Faudrait que tu nous en dise plus sur ton jeu. Mais si il est basique, (faire promener des ptits joueurs), t'es pas obligé de multithread.
En gros :
p1,p2 des joueurs,
S le serveur
p1 veut bouger : tu demandes à S de bouger p1. (par exemple t'envoie un truc style : "move:[10,0]")
S recoit le message de p1. il update la position de p1 dans sa map.
Il envoit la nouvelle position de p1 à [p1,p2]
p1 et p2 rafraichissent leur écran. (au début tu téléportes le joueur, mais après tu peux faire style le joueur a bougé (en envoyant "updatePosition:[8,0]" par exemple)

Cette config est basique (par exemple, si p2 envoie un message pendant que p1 envoit le sien, tu traite d'abord le message de p1, puis apres celui de p2), du coup, peut etre que p2 va traverser p1 mais c'est des détails à te préoccuper par la suite...

Jpense que tu peux t'en sortir sans multithread pour commencer, ca t'enleveras tous les acces concurrents, cqui est un peu chiant à debugguer, surtout si t'es pas familiarisé avec la synchro

[Dlzlogic]

@ Fatal_error
L'idée était d'avoir une base unique. Qu'elle soit sur disque ou en mémoire, je ne sais pas si c'est vraiment là le problème.
On peut avoir un programme centralisé sur un serveur, et sur chaque machine un programme de saisie, visualisation etc et d'adressage au serveur, personnellement, je trouve plus simple, dans un premier temps, d'avoir sur chaque machine le programme de jeu avec la centralisation de l'état actuel à un instant donné.

Il est vrai qu'il faudrait plus de détail. En tout cas, il me semble nécessaire de trouver un moyen de centralisation, programme sur le serveur ou seulement l'état actuel avec une gestion de flux.

[Gandalf 13]

Plus de détails? D'accord... Dans l'immédiat, c'est un projet qui se veut être assez simple et basique du fait de la date à laquelle on doit le présenter (mercredi prochain) et aussi parce que l'on a d'autres projets à coté qui comptent aussi pour l'école. C'est donc un survival, avec une map et un perso qui bouge dessus et qui peut attaquer. Les monstres doivent pouvoir arriver par vague à partir des points de respawn, donc avec un timer surement. Ensuite, on a décidé de rajouter un mode multi pour pouvoir s'amuser un peu. Personne ne s'y connaissait, donc je me suis proposé de le faire étant donné que je n'avais rien a faire et que cela me paraissait intéressant. Donc j'ai commencé a apprendre un peu et maintenant, je peux lancer un serveur et des clients qui s'y connectent dessus, ainsi que faire des echanges entre les deux. Et oui, c'est mon premier jeu.

Je fais un peu de MySql dans le cadre de l'école, je ne savais pas par contre ce que signifait SGBD, merci pour le renseignement ^^

En fait, à la base, je partais plus sur la solution de fatal_error... Mais si je comprends bien, il faudrait faire un fichier ou trouver un moyen de transmettre aux deux joueurs tout ce que les joueurs font? Ca va pas lager a mort ca?

[Dlzlogic]

Juste une courte réponse, vous employez un vocabulaire qui m'est inconnu.
Je pense que les échanges avec fatal-error seront plus faciles.

[fatal_error]

il faudrait faire un fichier ou trouver un moyen de transmettre aux deux joueurs tout ce que les joueurs font? Ca va pas lager a mort ca?

ca se teste assez vite.
Tu prends deux/quatre clients. Tu fais générer des messages à des temps aléatoires suffisamment courts.
Tu mets coté serveur un update de position (qui consiste à vérifier que le joueur a le droit), qu'il est pas mort, etc...
Et tu chronometres le temps entre ta demande et la réponse.

Vu que t'as déjà établi les sockets, c'est assez easy d'avoir une idée de si ca va ramer!

[Gandalf 13]

Juste une courte réponse, vous employez un vocabulaire qui m'est inconnu.
Je pense que les échanges avec fatal-error seront plus faciles.

Merci quand meme...

ca se teste assez vite.
Tu prends deux/quatre clients. Tu fais générer des messages à des temps aléatoires suffisamment courts.
Tu mets coté serveur un update de position (qui consiste à vérifier que le joueur a le droit), qu'il est pas mort, etc...
Et tu chronometres le temps entre ta demande et la réponse.

Vu que t'as déjà établi les sockets, c'est assez easy d'avoir une idée de si ca va ramer!

Ah ben oui! Je vais essayer et je dirai ce que ca fait... Merci ^^