Re: [Maitretarot-devel-fr] Uniformisation ?

[philippe brochard]

"Yves Mettier" <address@hidden> writes:

> > On Thu, Jan 16, 2003 at 02:40:52PM +0100, Yves Mettier wrote:
> >
> >> > C'est vrai, tout ca. Mais pour valet/cavalier/dame/roi, tu utilise
> >> 11/12/13/14 ?
> >>
> >> Actuellement, oui, et je continuerai dans ce sens dans maitretarot.
> >> Cependant, dans le protocole, c'est a mon avis pas une bonne idee de
> >> garder ca. Je prefere la solution <1 lettre><2 chiffres> qui est bien
> >> plus claire, et qui distingue bien toutes les cartes. Et qui permet
> >> aussi de pouvoir rajouter des cartes. D'ailleurs, euh, pour le rami ou
> >> des extensions du jeu de tarot, il faut pouvoir gerer deux jeux de
> >> cartes. Ca nous rajoute un chiffre aussi? Toujours a zero si on n'a
> >> qu'un seul jeu de cartes? On fait quoi?
> >
> > Je suis loin d'etre certain qu'il faille distinguer les cartes des deux
> > jeux. En fait, je ne vois pas trop dans quelles conditions c'est
> > necessaire. A part etre un pro et regarder le dos des cartes de tes
> > adversaires quand tu joues au rami, et en deduire que les probabilites
> > qu'il ait telle carte soit tant et tant ;)
> >
> > A moins d'utiliser un bitmap pour enregistrer un ensemble de cartes. Et
> > encore, au niveau du protocole...
> 
> Mmmmh, oui, bonne question, est-ce que cela sert?
> Cependant, si jamais on trouve un cas ou cela doit servir, il faudra
> pouvoir s'adapter. Soit on prevoit un changement des noms des clefs
> (l'ancien nom pour s01 par exemple, et le nouveau nom pour s001). Soit on
> anticipe tout de suite, et on prevoit cela tout de suite dans la notation
> des cartes.
> Je suis pour la seconde solution: ca nous evitera bien du boulot apres si
> le cas se presente, pour peut-etre 10 min de codage en plus et une
> vingtaine d'octets supplementaires pour certains messages (24 quand on
> joue a 3 au tarot)
> 
> Dans la seconde solution, voici deux suggestions de codage:
> c=couleur - 1 char
> n=numero de la carte - 2 chars
> p=numero du paquet - 1 char
> 
> suggestion 1: cnnp (ou cpnn, peu importe)
> suggestion 2: cnn(p) (p est obligatoirement en dernier mais est facultatif)
> 
> Je prefere la solution 1 qui permet de mettre en place un algorithme plus
> simple puisque la taille du codage d'une carte est connue a l'avance et
> que chaque champ a un emplacement fixe et surtout que chaque champ est
> present.
> 
> Le cout de la solution 1 par rapport a celui de la solution 2 est qu'on
> pourra avoir jusqu'a 24 octets supplementaires dans la solution 1 dans le
> cadre du jeu de tarot, dans un message. Par contre, le cout de la solution
> 2 par rapport a la solution 1 est un certain nombre de tests
> supplementaires, ce qui alourdit un peu les algos.
> 
> Il faut savoir qu'une trame TCP transporte de toute facon (environs) 1500
> octets (1512 il me semble, pour etre precis). A priori, vu le protocole
> qu'on met en place, on attendra rarement 1500 octets, et surement pas lors
> de l'envoi des cartes: 24 cartes * (4 caracteres + 1 separateur) +
> commande + clef = moins de 200 octets. On est loin des 1500. Donc cet
> octet supplementaire par carte n'est surement pas une economie.
> 
> Bref, moi, je prefere prendre en compte le numero de paquet de cartes tout
> de suite, et je prefere le codage cnnp.
> 
> Qu'en pensez-vous?

Je suis aussi pour la proposition 1. C'est la plus facile
a coder (par la suite) et celle qui prend en compte les
futures evolutions possibles, meme si on ne les connaient pas.



Philippe


PS : Je repond aux autres mails des que j'ai un peu plus de temps...

-- 
Philippe Brochard    <address@hidden>
                      http://hocwp.free.fr

-=-= http://www.fsf.org/home.fr.html =-=-