MMGOC (Massive Multiplayer Game On-Calc)
Posté le 09/12/2013 18:32
Je cherche des volontaires, actifs ou non, sachant coder en C, pour participer à un projet d'envergure : créer le premier MMO-RPG mode calto : MMGOC (Massive Multiplayer Game On-Calc).
Le principe est simple : une carte Arduino sert de serveur, qui organise les requêtes des différents joueurs connectés à l'Arduino.
Le jeu sera une sorte de RPG hyper simplifié (au début du moins) : on peut bouger sur une carte, voir les joueurs, et comme interaction les attaquer.
L'objectif initial est de créer la prouesse de connecter 5 joueurs minimum. (Sachant qu'une carte Arduino Mega peut accueillir jusqu'à 25 caltos
)
Dans un premier temps, les caltos seront connectées via le port série (3-pins) directement sur la carte. Ensuite, si c'est faisable (et ça l'est, faut juste de l'huile de coude), connecter le serveur via un port Ethernet en ligne de manière à ce que chacun puisse jouer en ligne. Et là ça serai classe 8)
Bien entendu, ça ne sert à rien, sinon qu'à doubler les TI-men dans la quête du concept le plus innovant
(et un peu à se divertir bien sur)
J'ai créé (pour moi, et pour les intéressés) un repo sur Bitbucket de manière à ce que les dévellopeurs aient facilement accès au code.
Si vous voulez faire partie de la team (pas besoin de venir souvent, juste de savoir lire et d'y ajouter votre pierre lorsque vous voulez), n'hésitez pas, je suis ouvert.
Bon, après, si y'a personne c'est pas un problème mais j'aurai personne avec qui tester une fois arrivé au réseau en ligne
Bref, qu'en dites-vous ?
Lien du repo
Citer : Posté le 16/03/2014 11:11 | #
Quand je dis les relier en chaîne, ce serait plutôt ça:
C1 -- C2 -- C3 -- C4 -- C5
Là où c'est problématique c'est que si C1 veut envoyer des infos à C5, elle est obligée de passer par toutes les machines entre elles.
Mais le vrai problème, c'est que si au même moment C3 envoie aussi des infos à C5, alors les paquets pourront être mélangés et les informations mal interprétées ; c'est trop compliqué à mettre en place.
La solution avec un serveur est plus pratique:
C1 ---- |
C2 ---- | Serveur
C3 ---- |
Celui-ci reçoit tous les ordres (en fait il va lire de son propre chef donc les informations ne se mélangent pas), sait les interpréter correctement et c'est lui qui, en partant d'une requête de C1, va la transformer en un ordre pour C2.
De plus, lui connaît toutes les données et peut les envoyer en même temps (ou presque) à toutes les calculatrices, cela permet une meilleure coordination et évite que les machines soit en permanence en train de s'échanger des informations dans tous les sens.
De plus, la première solution ne propose qu'une fluidité limitée par rapport à la deuxième, voire insuffisante.
Citer : Posté le 16/03/2014 11:53 | #
Pour ça il faut que le serveur demande à chaque calto de lui envoyer les infos, celle ci les envoie, demande à une autre qui les envoie, encore une autre... puis ensuite il traite toutes les données et envoie à chaque calculatrice.
Si on ne fait pas ça, imagine que C1 et C3 envoient en même temps au serveur, ça foire tout.
Donc niveau fluidité, c'est pas terrible, ca fait beaucoup d'échange :/
Moi je pense plutôt à une configuration comme celle là :
C1
!
C2-----!------C3
!
C4
C1 envoie : son identifiant (imaginons 1 pour faire simple), suivit de son information
C2, C3, C4 recoivent les données et déplacent, tournent, modifient, ... le jeu en fonction.
C2 envoie : son identifiant (imaginons 2 pour faire simple), suivit de son information
C1, C3, C4 recoivent les données et déplacent, tournent, modifient, ... le jeu en fonction.
C3 envoie : son identifiant (imaginons 3 pour faire simple), suivit de son information
C1, C2, C4 recoivent les données et déplacent, tournent, modifient, ... le jeu en fonction.
...
Le système tourne en continu.
L'avantage : communication direct, pas de matériel que personne n'a (c'est mieux pour le mutli
Citer : Posté le 16/03/2014 11:56 | #
Il est vrai que ton matériel peut faire office de plateforme d'échange, mais alors pourquoi pas un serveur ?
[...] en fait il va lire de son propre chef donc les informations ne se mélangent pas [...]
Comme je l'ai dit, la calculatrice écrit dans un buffer dès que l'utilisateur a entré son information et le serveur Arduino va y lire au moment où ça lui plaît.
Rien n'empêche le buffer de contenir plusieurs requêtes, tant que le serveur y répond dans l'ordre dans lequel elle y ont été écrites.
Citer : Posté le 16/03/2014 11:58 | #
Pourquoi faire compliquer quand on peut faire simple ?
Ok pour le buffer
Citer : Posté le 16/03/2014 11:59 | #
Parce que le serveur se programme
Comment ta configuration empêche-t-elle les signaux de se croiser ?
Citer : Posté le 16/03/2014 12:03 | #
Ils ne se croisent pas ! Puisque les caltos envoient chacun leur tour les informations qui les concerne. Une fois l'information de la C1 envoyée et terminée, alors uniquement à partir de ce moment, C2 envoie.
Quand C1 envoie, toutes les caltos recoivent l'information.
Citer : Posté le 16/03/2014 12:08 | #
Alors l'utilisation d'un serveur Arduino va considérablement augmenter la vitesse d'exécution donc la fluidité du jeu si on arrive à le programmer en "multi-tâches".
Puisque le serveur a un plus grand potentiel de puissance.
Tu aimerais jouer à un multi sur calto à 3 FPS ?
Bien sûr, j'exagère
Mais quand on arrive à des jeux plus complexes (une bataille sur un plateau 2D, par exemple), le serveur, puisqu'il possède à tout moment toutes les informations, gère la partie par ses propres moyens.
Ça permet de maintenir une fluidité raisonnable.
Citer : Posté le 16/03/2014 12:13 | #
Nan mais je vois absolument pas ce qui limiterait les FPS. Dis moi dans ce cas
Parce que c'est les caltos qui vont executer le programme, pas l'Arduino. Donc la puissance de calcul de l'Arduino ne change rien.
Citer : Posté le 16/03/2014 12:16 | #
C'est l'Arduino qui exécute le programme. Les calculatrices ne savent qu'afficher les données que le serveur leur envoie. Si elle reçoit "Tu perds 10 PV", elle ne vas pas se poser de questions, juste diminuer le niveau de la jauge sur l'écran.
C'est le serveur qui calcule: "C1 a 10 d'attaque et C3 7 de défense, donc j'envoie à C3 qu'elle paerd 3 PV".
Et l'avantage du serveur, c'est que s'il est synchrone, les calculatrices peuvent toutes enoyer et recevoir des informations en même temps, ce qui multiplie la vitesse par le nombre de machines, dans la limite de la puissance du serveur.
Citer : Posté le 16/03/2014 13:28 | #
Je vais prendre un exemple :
Dans call of duty, au moment ou tu tires, tu envoies une information avec ta direction, tes coordonnées, plein d'autre trucs et l'information : "je tire". Le serveur a la position de tous les autres joueurs, alors il détermine si tu touches un adversaire ou pas. Il te répond : oui ou non en envoyant au passage d'autre informations comme la cible, si il est mort, la vie qu'il lui reste...
Mais le serveur ne fait que te répondre si tu touches ou non.
C'est bien ta PS3 qui va faire TOUT les autres calculs, l'impact sur le mur, la gestion du déplacement, le recul de l'arme, la baisse des munitions, ...
D'ailleurs, pour être plus précis, c'est ta PS3 qui effectue toutes les actions sur les autres joueurs qui sont sur ton écran, le serveur n'envoie que de temps en temps (biensur très courts) des informations sur les autres joueurs, tu n'as jamais vu quand ça lague un peu des joueurs adverses courir contre un mur, ou se téléporter d'un coup d'un point à un autre, c'est parce que ta PS3 n'a pas reçue de nouvelles informations sur ces joueurs, donc si il courait vers le nord, ta PS3 suppose qu'il courre toujours vers le nord et déplace l'adversaire vers le nord alors que ce n'est pas vrai. Et au moment ou elle reçoit une information elle mets à jour (d'où le phénomène de téléportation).
Bref tout ça pour dire que c'est TA PS3 qui effectue les calculs.
Et puis pas besoin d'une grande puissance de calcul pour effectuer des soustractions sur la vie d'un joueur
Sinon juste pour l'histoire, les serveurs de Call of duty (ou autre), ta PS3 envoie l'information "je tire" au serveur, mais pourrait très bien déterminer toute seule si tu touches un adveraire et dire au au serveur "j'ai touché lui, avec telle arme", mais on ne le fait pas pour des histoires de triche, car il suffirait qu'un malin trafic l'envoie et dise à chaque envoie "je touche quelqu'un"
Citer : Posté le 16/03/2014 13:36 | #
Mais bien sûr, je n'ai jamais dit le contraire
J'ai simplement dit que si nous étions malins, nous laisserions l'Arduino faire les caculs, parce qu'elle est plus puissante
Citer : Posté le 16/03/2014 13:44 | #
Ajouté le 16/03/2014 à 13:46 :
Parce qu'il faut bien faire la difference entre les calculs pour le jeu (moteur graphique, physique, menus, ...) et les calculs pour transmettre les informations entre les joueurs
Citer : Posté le 16/03/2014 13:51 | #
C'est le serveur qui fait les calculs degats = attaque-defense, mais il gère aussi les déplacements des personnages sur la map: par exemple, c'est lui qui vérifie qu'un personnage n'est pas en train de sortir de la map, et qui va empêcher son déplacement; ce n'est pas la calculatrice qui fait ça.
Pour simplifier:
- Le serveur est le coeur du programme. Il sait tout et effectue toutes les actions.
- Les calculatrices ne sont que des interfaces utilisateurs et se contentent de transmettre les requêtes.
Enfin, après rien n'empêche d'équilbrer les deux, d'autant plus que le serveur risque d'être surchargé de calculs s'il y a beaucoup de joueurs.
Citer : Posté le 16/03/2014 13:59 | #
C'est faisable, mais c'est clairement pas la bonne solution. Je préfère faire une condition du genre :
plutôt que
demander au serveur si je peux aller à droite
... attendre sa réponse
ne pas aller à droite
C'est justement ce genre de calculs que la calculatrice traite.
Tu parlais de fluidité mais, comme tu dis, tu pers énromement en fluidité parce que tu demande constement au serveur, et puis comme tu demandes pleins de choses inutiles que la calculatrice gère parfaitement, tu satures d'avantage la connection et tu attends encore plus.
Il ne faut pas que les caltos soient uniquement des claviers et des écrans.
Citer : Posté le 16/03/2014 14:04 | #
De plus, en envoyant juste la position au serveur, le programme est plus rapide
Citer : Posté le 16/03/2014 14:09 | #
Enfin, après rien n'empêche d'équilbrer les deux, d'autant plus que le serveur risque d'être surchargé de calculs s'il y a beaucoup de joueurs.
C'est bizarre, j'ai l'impression de me répéter
Ce que j'essaie de te dire, c'est que ce calcul sera certes effectué par la calculatrice (en fait je ne sais pas quoi te proposer comme exemple pour que tu comprennes ce que je veux dire), mais ceci serait effectué par le serveur (encore une fois, dans la mesure de ses capacités):
[b]Alors Si[/b] x>30 je ne fais rien
[b]Sinon Si[/b] la case à droite est de la lave je perds des PV
[b]Sinon[/b] [u]etc...[/u]
[b]FinSi[/b]
De toute manière, il faudra que la calculatrice envoie sa nouvelle position au serveur, ses PV si elle en a perdu, etc... ça fait des paquets ingérables.
Si le sevreur s'occupe de faire ça, on simplifie les communications.
Et puis un serveur maître ça évite qu'un malin joue avec un add-in différent construit sur les sources de l'original où il ne perds pas de PV ou autres.
Citer : Posté le 16/03/2014 14:16 | #
Et puis un serveur maître ça évite qu'un malin joue avec un add-in différent construit sur les sources de l'original où il ne perds pas de PV ou autres.
le cheat c'est cool 8)
Citer : Posté le 16/03/2014 14:23 | #
Ce que tu ne comprends pas c'est que plus la calto est indépendante du serveur, moins il y aura de transfert d'information avec le serveur. C'est logique
Si le sevreur s'occupe de faire ça, on simplifie les communications.
De toute manière, il faudra que le serveur envoie la nouvelle position aux calculatrices, ses PV si elle en a perdu, etc... ça fait des paquets ingérables.
Quelle est la différence, dans un sens ou dans l'autre c'est pareil.
Citer : Posté le 16/03/2014 14:26 | #
De toute manière, il faudra que la calculatrice envoie sa nouvelle position au serveur, ses PV si elle en a perdu, etc... ça fait des paquets ingérables.
Si le sevreur s'occupe de faire ça, on simplifie les communications.
De toute manière, il faudra que le serveur envoie sa nouvelle position aux calculatrices, ses PV si elle en a perdu, etc... ça fait des paquets ingérables.
Quelle est la différence, dans un sens ou dans l'autre c'est pareil.
+1. Encore que l'Arduino est plus puissante que la calculatrice.
D'où, encore une fois:
Si on laisse les calculatrices faire tous les calculs, le serveur ne servant qu'à transmettre, il y aura une perte de puissance considérable.
Citer : Posté le 16/03/2014 14:32 | #
Une perte de puissance ? tu comptes faire tourner quoi comme jeu aussi, il faut rester réaliste, on va pas faire tourner Battlefield sur nos caltos.
Citer : Posté le 16/03/2014 14:33 | #
Tant qu'à faire si tu peux garder le maximum de ressources pour ce qui est propre à la calculatrice (affichage et refresh de l'écran, etc...) c'est mieux je suppose