Multijoueur sans cable (MSC) - Page 1

Pour le multijoueur sans cable (MSC)
Faisons vivre cette catégorie ( "La course au défit" )
Je vais aller faire un tour sur les forum casio pour leur en parler.

Ben je pense qu'il faut savoir quelle genre de technologie ont casio, .... mais si ils ont les listes et les matrices come nous , sa vas être facille à faire.... lol,... le tout est de trouver une idée de jeu "de base", qu'on lance l'algorythme pour tout le monde, et qu'on réalise !!!!!!!

Bon pour ^préciser, moi je peux vous aider pour les Ti82 voire 89 ( sa dépend du niveau de programation ), ou sinon pour organiser l'écriture des algo....

faudrait aussi mettre un link vers le forum de casio en question pour que en cas d'info sur le dit forum, on ai plus qu'a revenir au début de cette page pour y acceder !!!

Ca c 1 bonne idee!
Je connais des gars qui sont au bord du suicide avec leur CASIO!

Je connais des gars qui sont au bord du suicide avec leur CASIO!

lol, des fois y a de quoi !
Plus sérieusement je suis aller faire un tour et y a pas grand chose, ils sont pas très actif.
Peut-être que ce projet redynamisera leurs troupes !!
j'ai trouvé 2 forum ou j'ai posté, en les renvoyant sur ce forum. http://www.casioland.net/forum/viewforum.php?f=3
http://www.jeuxcasio.com/viewforum-6-0.html

Donc je suis en train de finir les prgm de convertisseurs et je fait un organigramme de ceux-ci.

Pour la version en fichier Visio 2003 :http://paul.michel88.free.fr/MSc.VSD
J'espère que c'est plus clair pour ceux qui n'avais pas compris

trés intéressant ! La chasse est donc ouverte pour les codages des variables,...il faut faire puissant, mais léger,...si possible même aléatoire pour qu'il ne soit pas repérable,.. hum... on vas se marrer je vous dit

Il ne reste plus qu'a avoir une démo jouable de la version Ti pour commencer à mettre au point les possibilités de multijoueur !

Si tu peut empécher la gruge, faut mettre qqch de plus compliquer que "3var1"

en effet,... ikl faut faire puissant !!!!! Sa doit surement être le moyen sur lequel il vas faloir le plus réfléchir finalement,...c'est kle transfert des données sans fraude,.... faudra peut être inventer un système comme sur les code barre, je sais pas si vous avez déjà entendu parler, mais style si vous décidez d'épaaissir un trait de code barre, il ne sera plus valable parce que la chaine de 0 et 1 ne sera plus corecte, ...

je m'explique ,...

dans nos transferts de parametres, tu peux mettre peins de conditions comme, " le premier paramètre doit être impair et divisible par 7" , " le deuxième paramètre doit être multiple de 4", le troisième paramètre dit être plus grand que le 1+2ème paramètre", "le quatrième paramètre doit être compris entre 10 et 20",...etc......

la biens sur, c'est trés léger,...mais l'avantage, c'est que en rentant une chaine au hasard, il y a peu de chance qu'elle soit corecte si on met des outils efficazce permetant de le détecter... le tout est biens sur de mettre des rapports de multiplication, ( style, un paramètre au milieu de la chaine serait un multiple pour certains nombres de base,... )


Mais ne nous égarons pas, d'aprés vous, combien de "Var" faut il rentrer pour que le joueur ne se lasse pas ???

c'est kle transfert des données sans fraude

t'a deux solutions:
.tu code (au sens cypte) sa asser bien, sa risque d'être plutôt pas très court. (et de toute fasson, ce sera réversible, suffira de lire la soruice du progm quir eçoit)
.T'envoi un numéro qui est pas "claire" pour l'user, ie il se sera poas si 3 et mieux que 2 et si 1 est mieux que 2 (il faut pas que lka "qualité" du numéro soit crosisante/décroissante). Evidemment, il va vite s'en rendre comtpe, et c'est chiant à coder.
.Tu compte sur l'intégrité des joueurs . (surtout sur l'autre joueur qui regarde )

bah, on vas devoir forcément être exposé à la fraude, donc autant trouver le max d'astuces pour la repousser, le moyen le plus évident et de pas faire apparaitre clairement les infos transmises, et que ces dernières ne soient vraiment QUE interprétable par la calto,...

histoire que si je te dise 14, 2, 36, 21, 18,...que sa soit incompréhensible,...

un truc bon à savoir, c'est que le petit algo que j'ais mis au dessu,

dans nos transferts de parametres, tu peux mettre peins de conditions comme, " le premier paramètre doit être impair et divisible par 7" , " le deuxième paramètre doit être multiple de 4", le troisième paramètre dit être plus grand que le 1+2ème paramètre", "le quatrième paramètre doit être compris entre 10 et 20",...etc......

le principe du code barre,...je l'ais fais vitte fais sur ma 82,....elle a mis 400 essais aléatoires pour trouver 1 chaine corecte à ses "faibles" conditions !!! !!! 1/400 !!! sa représente du 0.0025% de chances de tyrouver aléatoirement une combi qui marche,... ( bon statistiquement j'aurais du faire plusieurs essais,... )

donc trouver par hasard une chaine de nombre est qasi impossible, proble, si le joeur vas dans l'éditeur, il comprend le cryptage, et peut lancer des attaques aléatoires,... il faut donc pousser l'aléatoire à 0,...qu'il n'éxiste plus qu'une seule solution de possible au niveau code, que certain chiffres de la chaine soient exacts,...impossibles en théorie à trouver... mais quel est ce moyen ???

C'est pas pour vous désenchanter mais j'ai déja pas mal galéré pour faire le prgm avec un encodage "simple" (comme en haut). Mais bon il faut tout tenter. Vous pensez faire un codage compliqué, mais tu peut bien ouvrir la source ( avec codex ) et regarder donc , je pensais, que certains sont très fort en asm, qui pourrais nous faire ça sans pbl. Alors les casio je ne sais pas cmt ils pourraient se démerger, mais, nous, avec nos TI ca serais infalsiffiable !!
en plus il faut faire guaf avec un système plus conpliqué de codage parce que avec mon prgm on ne peut pas mettre de chiffre à virgule .
http://paul.michel88.free.fr/TI/A1.8xp
http://paul.michel88.free.fr/TI/A2.8xp
(il faut les 2)

Ms il y a aussi 1 autre probleme: il ne faut pas que le code a rentrer soit trop long! On va vite en avoir marre s'il faut rentrer 30 chiffres a chq tour!
Ms ca ne devrait pas qd meme poser trop de problemes, on va pas faire des jeux qui traitent + de 10 parametres.
Pr ce qui est du codage ont peut le faire rapidement et relativement simplement en utilisant des fonctions: par exemple le nombre codé Y à entrer est l'image de la variable X par la fonction f(X)= - 5X + 18 .
Ensuite pr décoder il faut faire pareil avec la fonction de decodage, ici: (18-X)/5

(par contre ca marche qu'avec les fonctions monotones: 1 seul antecedent par valeur de Y, donc pas de X^2 et autres...)

je pense que faut pas forcement chercher compliquer pour ne pas tricher mais pour l'asm je pense que c'est LE moyen pas compliqué pour un maxi de sécurité (ca rime !)
Vous avez regardé les prgm ? vous en pensez quoi ?

Salut... J'ai vu le message de Paul_2 sur casioland.

Ca a l'air marrant votre projet, mais je crois que vous vous emballez un peu vite...
Proposer une technique de codage unique ne me semble vraiment pas être une bonne idée. D'abord parce que le type de code dépend du type d'information à transmettre, ensuite parce qu'il suffit que quelqu'un connaisse la clé pour qu'il la divulgue comme il veut, et également parce que si vous vous rendez compte que le codage doit être légèrement modfié, vous devez adapter tous les progs déjà existants pour qu'ils restent compatibles.

Je préfère aussi vous prévenir tt de suite: Le basic casio ne gère pas les chaînes de caractères Pas moyen de faire en sorte que l'utilisateur doive entrer un code du genre "3Ak6htb" puis que la caltoche le récupère, elle ne connait que les nombres

Sinon pour ce qui est du rapprochement entre les différentes calculatrices, intéressez-vous au langage MLC d'Epic Programming Studios, ça peut donner quelque chose de pas mal

Voilà, c'était pour mettre mon grain de sel dans l'histoire
Au fait:

1/400 !!! sa représente du 0.0025% de chances

1/400 = 0.25%

1/400 = 0.25%

lol oui comme un con j'ais fais la division avec ma calto que j'avais sous la main et j'ais pas multiplié par 100 !

Mais bon, je vois pas le problemme dans un sens ! Si c'est un jeu au tour par tour, la seul chose qu'on a besoin de coder, c'est la commande qu'effectue le joueur et les dégats pouraient être calculés par la ti réceptrice,...( pardon, la calto réceptrice )

en gros la question est la ! A t'on besoin de crypter de manière importante les échanges de données ??? Si oui, autant s'aretter la pour le basic ( et pour pas mal de choses aussi, car pour trouver un codeur asm sur toutes les calto sa vas être coton !!! )

Le basic casio ne gère pas les chaînes de caractères

le basic Z80 non plus ( enfin la 82 et la 83 c'est sur,...aprés peut être qu'au dessus... )

intéressez-vous au langage MLC d'Epic Programming Studios

what did you disme ? sa se trouve ou sa ? Tu veux dire que y'a quelqun qu'a trouvé un la,guage commun aux deux calto ??? Sa ne résoudpas notre problemme du cable ou la possibilité de jouer à plus de 2 ( comme pourait le permettre le MSC!!! )

En fait vous voulez définir (et imposer?) un codage standard pour les progs qui utiliseraient cette technique... Evidemment y'a d'autres personnes qui ont eu cette idée de communication auparavant, mais à ma connaissance elle n'a pas été fort exploitée. Et personnellement, je ne vois pas l'intérêt d'un tel standard.

Si quelqu'un veut s'inspirer de cette technique dans un prog, il sera sûrement assez malin pour trouver lui-même un code assez bien adapté à son problème... Je ne pense pas qu'il puisse y avoir un codage universel qui satisfera tout le monde.
Comme je l'ai dit, le code dépend du type d'information à traiter... Et puis, si le but est d'éviter les gruges, il serait intéressant que le codage ne soit pas bijectif dans certains cas: Imaginez que pour un jeu, la caltoche veuille transmettre un nombre de 1 à 5 à l'autre... Si les codes sont par exemple 45, 596, 153, 90 et 354, les joueurs verront rapidement que ce sont ces mêmes 5 nombres qui reviennent souvent, et pourraient tricher plus facilement que si plusieurs codes étaient utilisables pour un même nombre au départ (donc au lieu de toujours coder "1" par 45, on pourrait dire que 953, 764 et 24 sont aussi des codages possibles, ce qui donne à l'utilisateur l'impression qu'il a affaire à un cryptage bien complexe; mais la calto réceptrice sait bien que ces nombres représentent tous un "1").

Je pense que c'est au programmeur du jeu de trouver ce qui convient le mieux à son programme. Et pour ce qui est des problèmes de compatibilité entre caltoches, généralement ce sont les mêmes personnes qui s'occupent de l'adaptation (ou en tout cas ça se base sur les sources originales), et donc il n'y a pas de raison que le même codage ne puisse pas être utilisé sur les différentes versions du jeu...

Pour MLC: Personne n'a "trouvé" de langage commun, c'est une équipe de programmeurs sur différents modèles de caltoche qui s'est rassemblée pour créer un nouveau langage interpreté, et pour écrire les progs capables d'executer les scripts écrits dans ce langage. Allez voir par ici: http://dysfunction.earthforge.com/?p=mlc.php
Comme tu dis, ça ne rédoud pas la question de la communication entre caltoches... Mais finalement moi, des vrais problèmes j'en vois pas Pas la peine de chercher un codage ultime, il n'y en a pas...

avec nos TI ca serais infalsiffiable !!

Tu conait le déssasemblage ?. ( and reverse engeenering )

par exemple le nombre codé Y à entrer est l'image de la variable X par la fonction f(X)= - 5X + 18

Déjà, sur ce genre de truck, t'a un ordre, et le gars se rendra vite compte que plus le nombre est (bas par exmple) plus il est (bien par exmple).
Ensuite, effectivement, il te faut une focntion bijective. (donc inversible)
Pour finir, le moindre gars qui lit la source sera comprendre.

il suffit que quelqu'un connaisse la clé pour qu'il la divulgue comme il veut

pas forcément. Déjà, depend du système de clef ( privée, publique/privé). Ensuite, c'est pas forcément vrai. (il peu ne pas y avoir de clée, ou juste une clée publique et un code inrenversible.) Fin, on se pend la tête pour pas grand chose pour la "sécurité".

Mais c'est sur que si tu code en asm le cryptage/décryptage et que tu cloosed-sources, sa devrait passer. ( soit disant, y'a toujours moyen de renverser ^^).

le basic Z80 non plus ( enfin la 82 et la 83 c'est sur,...aprés peut être qu'au dessus... )

y'a que la 82 ( et <) qui ne les gères pas. Les Ti 83, Ti 83+, Ti 84+ les gérent. ( mais disposent de focntions très limité dessu)

intéressez-vous au langage MLC d'Epic Programming Studios

Ouaip, je conait. (kevin en fait parti now, http://dysfunction.earthforge.com/ )
ils ont un forum asser actif.
Mais bon, bauf...

En fait vous voulez définir (et imposer?) un codage standard pour les progs qui utiliseraient cette technique... Evidemment y'a d'autres personnes qui ont eu cette idée de communication auparavant, mais à ma connaissance elle n'a pas été fort exploitée. Et personnellement, je ne vois pas l'intérêt d'un tel standard.

Non pas du tout, y'avait aucunement cette atention au départ.

il serait intéressant que le codage ne soit pas bijectif dans certains cas

Dans ce sens, on pourait prendre un codage périodique ^^. ( mais bijectif sur sa période)

Tu conait le déssasemblage ?

c'est vrai ca existe je savais pas. c'est génial !
Je pense pas que le codage soit un enjeux majeur : si qqn veux trricher il le fera, avec + ou - de difficultés mais bon ce n'est qu'un jeux. Donc faire un truc en asm (juste pour la partie encodage ) c'est déjà énormément limiter la fraude. Sinon faire une formule du type y=3x+18 me semble pas mal mais il faut pas avoir un coef directeur trop inportant par ce qu'ensuite on abaisse le nombre maxi
Avec les prgm que j'ai fait (bases de 3 : 1000>X>-1 ) donc avec cet exemple ca fait un nb maxi de x=(999/3)-18=315

Je crois que qqn a discuté du multijoueur entre casio et TI, ici:
http://65.254.50.194/~earthfor/dysfunction/forum/index.php?showtopic=254
mais les differences entre le voltage des caltos font en sorte que la TI fait griller la Casio

Trop fort

Pr le codage, la bonne solution peut alors etre la periodicité. Par exemple avec le systeme du cercle trigo; mettons qu'on ai 3 a coder: on le divise pr qu'il soit une mesure principale de l'angle ( entre -pi et +pi ): ca donne 3/10pi par exemple, et ensuite on rajoute un multiple de 2pi aléatoire: 63/10pi (un autre coup ca donnera 103/10pi ou 23/10pi). Et on peut encore ameliorer pr qu'on reconnaisse pas (...en rajoutant 4/10pi : ca donne 107/10pi ou 27/10pi...).

Et là difficile avec 107/10pi, 67/10pi, -13/10pi , -53/10pi, 47/10pi, de savoir que tous ces nombres correspondent à 3 !

verytourist
: Non pas du tout, y'avait aucunement cette atention au départ.

C'est quoi votre but exactement? J'avoue que je vois pas trop ou vous voulez en venir...

je ne vois pas l'intérêt d'un tel standard

Tu voix pas l'intérèt ? ba c'est de pouvoir jouer enssemble casio et TI. Je trouve que c'est un argument non-négligeable.
Mastercalto, c'est pas bête ton système mais leproblème c'estr que pour transformer un nb à virgule en une chaine, c'et bonbon !!
Donc je pense qu'il ne faut pas se casser la tête, comme je l'ai dit plus haut, "qqn qui veux gruger, gruge" .

Paul_2
: Tu voix pas l'intérèt ? ba c'est de pouvoir jouer enssemble casio et TI. Je trouve que c'est un argument non-négligeable.

Oui, mais je vois pas pourquoi ça demande autant d'agitation... C'est très simple à implémenter comme idée, vous croyez vraiment qu'il vous faut passer autant de temps à trouver comment la réaliser? Apparemment vous cherchez toujours comment coder les données à transmettre, et comme j'essaie de vous l'expliquer un codage unique n'a aucun intérêt.

Pour faire des progs compatibles Ti/casio il faut des gens qui savent programmer sur les deux machines, et il ne leur faudra que quelque instants pour décider d'une méthode pour transmettre les données, en se basant sur la même idée. Je vois pas trop en quoi vous allez pouvoir les aider efficacement...

En clair à quoi voulez-vous arriver? Qu'est-ce que vous voulez fournir pour ça?

Apparemment vous cherchez toujours comment coder les données à transmettre, et comme j'essaie de vous l'expliquer un codage unique n'a aucun intérêt.

sa on savais !

En clair, ce que moi j'ais comris en tout cas, c'est que le transferts des informations se fasse "oralement" entre les deux joueurs, qu'ils aient une Ti ou une casio, une graph65 ou graph 100, une 82 ou une V200 ! Que ce soit le plus court possible, mais que ce ne soit pas non plus trop simple à remarquer ( que la variable "force d'un coup" par exemple, qui vaut 3000 ne se transmette pas avec une simplevariable "entrez 3000",... )

Le tout est un peu de dégouter le joeur qui serait tenter de tricher ( en rendant donc une chaine de variable incompréhensibles et à chaques fois diférentes même si c'est la même attaque qui est demandée ! )

Bien entendu, celui qui veut s'amuser à tricher, eh bien qu'il triche ! Il n'y a rien de plus simple en basic que de repérer la ou se trouve la difficulté et de la baisser! Le tout est de transmettre de infos ( reste à savoir lesquelles pour savoir jusqu'ou il faut bosster le cryptage )!!

Et c'est tout !!!! C'est peut être anodin, mais c'est nouveau et révolutionaire en soit !!!! T'imagine que tous les gars de ta clase puisse jouer au même jeu !!!!! ( sauf les tit blaireaux qui ont des Hp ) !!! Sa vas êrmetrre de lier un peu Ti et Casio, que ce soit les codeurs ou les joueurs !!!

A mon avis, c'est une experience qui vaut la peine d'être codée ! Même si ce sera un jeu tout pourri ! Il sera magnifique de par l'originalité du principe !! Voila ce qui manque de nos jour au jeu...le génial !!!

Bien sur on s'emballe peut être trop ! Sa n'amusera jamais personne et le projet tombera dans l'oubli absolu,...mais j'en doute !

Mastercalto, c'est pas bête ton système mais leproblème c'estr que pour transformer un nb à virgule en une chaine, c'et bonbon !!

Non, n'oublie pas:

Orwell:
Je préfère aussi vous prévenir tt de suite: Le basic casio ne gère pas les chaînes de caractères Pas moyen de faire en sorte que l'utilisateur doive entrer un code du genre "3Ak6htb" puis que la caltoche le récupère, elle ne connait que les nombres

Et a cause de ca on sera ss doute obligés de se limiter a des petits jeux où il y a 1 seul parametre a gerer (ex: la force d'1 attaque ou sa precision, ms pas les 2 en meme temps).

j'essaie de vous l'expliquer un codage unique n'a aucun intérêt.

Très vite dit.
( les codages actuel els plus performants sont uniques. )
Après, c'est sur que l'on est sur Ti ^^

Le basic casio ne gère pas les chaînes de caractères

ca va etre dur de faire un jeu "bien" sans pouvoir utiliser de chaine !!!

C clair! Les casio c vraiement de la...

NAAAAAAN!!!! On a frisé l'incident diplomatique!