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 20/01/2014 20:50 | #
Alors ça avance votre projet ? J'ai hâte
Citer : Posté le 20/01/2014 20:51 | #
Plus ou moins, je planche sur un algorithme pour initialiser la connection, mais c'est chaud de synchroniser le serveur et la calto...
Citer : Posté le 20/01/2014 20:51 | #
Je comprend, vous êtes entrain de faire la mise à jour pour crée une calcIphone
Citer : Posté le 02/02/2014 15:29 | #
j'y pense, mon topic serait il lié à celui là ?
Et je n'ai pas compris, la connéxion se ferra par internet ?
Je suis de l'autre coté de la manche maintenant. Yay.
Citer : Posté le 02/02/2014 15:50 | #
Contrairement à ton topic, ici il s'agit plus d'une connexion filaire: on branche la caltos sur l'arduino directement, ce qui est plus simple à mettre en oeuvre, de plus le nombre de fils est réduit: 3 fils par caltos, sachant qu'un de ces 3 doit être relié à la masse (GND): le référentiel; tandis qu'il faut généralement plus de fils pour la com à distance.
Pour ce qui est de l'internet, il suffirait d'avoir des modules Ethernet qui assureraient la com avec un serveur distant pour transmettre des infos à une autre carte relié à l'internet et donc à une caltos qui y serait branché, mais il faut le serveur... Et je doute qu'une seule arduino avec une extension ethernet fasse l'affaire (à moins d'utiliser la TRE, bien plus rapide)
Citer : Posté le 02/02/2014 16:01 | #
Oui mais le processeur de la TRE est un TI
au secours !
Ils sont partout !
Je suis de l'autre coté de la manche maintenant. Yay.
Citer : Posté le 02/02/2014 16:03 | #
Si un jour je fais un serveur sur Internet, je ferai le serveur directement sur le Web, et non sur une Arduino.
Citer : Posté le 02/02/2014 16:03 | #
@Gollum: Et alors, c'est plutôt bien qu'il ait fait appel à des gars compétant dans ce domaine, 1gHz pour le processeur c'est plutôt cool non? Sur le plan des calculatrices je dis rien mais là tu exagère, TI fait d'assez bon trucs quand même.
Sinon c'est vrai que c'est mieux sur le web direct, une arduino c'est sympa mais ça a des limites
Citer : Posté le 02/02/2014 16:05 | #
Je sais mais si je déc***e pas, qui vas le faire ?
Je suis de l'autre coté de la manche maintenant. Yay.
Citer : Posté le 02/02/2014 19:03 | #
C'est pas possible de faire ça en branchant directement sur un ordi ? Parce faire du multi joueur si personne n'a le matériel bof.
Citer : Posté le 02/02/2014 19:43 | #
A moins de faire un logiciel qui gère le serial pour la caltos, et l'internet, mais ça devrait être possible (par contre ne comptez pas sur moi pour ça)
Citer : Posté le 02/02/2014 21:05 | #
Il suffit d'accéder au port Usb de l'ordi et puis c'est comme avec l'arduino, sans l'arduino. (enfin je pense)
Citer : Posté le 08/02/2014 07:51 | #
Pas sur que ce soit si simple.
déjà,il faudra trouver dans quel mode de connexion la calto doit se mettre.
ensuite, il faut faire un programme qui trouve la-dite calto.(je ne sais pas si on a les sources de screen receiver mais ça pourrait être bien)
et après, pour gérer un refresh auto sur une calto tout en continuant de jouer et de voir les autres joueurs jouer et se déplacer je pense qu'il y a du pain sur la planche
Je suis de l'autre coté de la manche maintenant. Yay.
Citer : Posté le 15/03/2014 13:10 | #
j'ai hâte moi aussi de voir ce que ca va donner
Quand même un mmorpg sur calto... vous y allez fort !Vous pensez faire quel terme de mmorpg à terme ? un jeux d'entraide ou chacun joue contre un objectif commun ou un jeu où tout le monde
se tape sur la gueuleest ennemi ?-Mon Fall Down
-Mon jeu de mains
-Mon starwars
-Mon dessinatout
-Mon niaiseux version 2.0
-Mon niaiseux version 3.0
-Inferno
-Mon super labyrinthe (en cours)
-Mon call of duty en 3D
-Casion (avec Az)
Citer : Posté le 15/03/2014 13:22 | #
Pour synchroniser l'Arduino et la calto, tu ne peux pas simplement leur faire envoyer un message particulier ?
Ensuite, chaque fois que tu envoies un paquet de données, tu le commences et le termines par deux octets différents prédéfinis.
Ainsi, la calculatrice sait où commencent et se terminent les paquets. Si elle reçoit des données fragmentées, elle les ignore.
De cette manière, on a une sorte de synchronisation entre les deux périphériques.
Citer : Posté le 16/03/2014 10:34 | #
Et avec un truc comme ça ? C'est pas plus simple, du coup il n'y a pas de serveur.
Tu as une connection directe entre les calculettes. Le protocole d'échange est plus simple :
Chaque calto à un code, un identifiant.
A chaque fois elles envoient leur identifiant suivit du paquet puis un octet de fin.
Et cela chaqu'un son tour, les caltos réceptionnent le message et agissent en fonction.
1,2,3,1,2,3,1,2,3,1,2,...
Le paquet donne s'implement la position du joueur, sa direction, son action,... à chaque frame.
Citer : Posté le 16/03/2014 10:38 | #
Ça dépend si Dark Storm relie le port 3 broches de la caluclatrice à ceux de l'Arduino ou le port USB.
Mais de toute manière, on est obligé d'avoir un serveur pour coordonner les actions des joueurs.
Citer : Posté le 16/03/2014 10:40 | #
Pourquoi un serveur ? Si on est moins de 5 ça doit bien fonctionner sans.
Citer : Posté le 16/03/2014 10:43 | #
D'abord, la calulatrice n'a pas un nombre infini de ports. On ne peut pas les relier en chaîne, ce serait ingérable.
Ensuite, les calculatrices ne font qu'appliquer les ordres qu'elles reçoivent et envoyer les requêtes de l'utilisateur.
Il faut bien quelque chose pour traiter tour ça. Quand tu joues en muiltijoueur, il y a toujours soit un serveur soit un hôte, mais dans ce cas-là celui-ci peut communiquer directement avec toutes les machines.
Citer : Posté le 16/03/2014 10:52 | #
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.