Re: [Maitretarot-devel-fr] Ajout d'un jeu dans maitretarot

[Philippe Brochard]

"Yves Mettier" <address@hidden> writes:

> Philippe nous disait, dans le thread Documentation:
> 
> > Comment ca ce passe si on veux documente un nouveau jeu ?
> > Ce serai bien que ce soit facile d'acces dans un logiciel a
> > part.
> 
> La premiere question est: comment cela se passe si on ajoute un nouveau jeu, 
> belote,
> tarot a 5...
> 
> Si on se lance dans une telle entreprise, c'est la qu'on va voir si le 
> protocole a ete
> bien concu, et si les implementations sont solides. Si elles le sont, la 
> question est
> reglee: il n'y a qu'a coder. Sinon...
> 
> Sinon, nous allons avoir a faire, si nous voulons faire propre, quelque chose 
> qu'on a
> deja fait une fois dans le projet maitretarot, chose qu'on fait difficilement 
> en
> general: repartir a zero. Pour rappel, maitretarot_server est le descendant de
> tarotserver (un bout de code qui n'est jamais alle loin a cause de mauvaises 
> idees au
> depart). Guillaume (qui ne repond plus mais est encore abonne a cette liste) 
> avait
> repris tarotserver et a corrige certaines erreurs de conception de ma part. 
> Et j'ai a
> mon tour a nouveau repris le developpement de maitretarot_server en 
> continuant sur ces
> erreurs (en particulier, le protocole dans un format binaire). Cela nous a 
> fourni deux
> occasions de repartir a zero. Et on ne l'a pas fait: c'est pas facile.
> 
> Et la ou j'ai decide de le faire, c'est pour adopter un format texte du 
> protocole: c'est
> la naissance de cardgame_server. Et du coup, correction d'autres erreurs 
> aussi, comme
> l'abandon de threads et de l'idee de mettre des forks a la place.
> 
> Mais ce redepart a zero n'a ete possible que grace
> - au fait qu'on avait deja une implementation qui fonctionnait, avec ses 
> interets et ses
> inconvenients
> - au fait qu'on avait mesure les limites de cette implementation (faible 
> evolutivite au
> niveau des fonctionnalites, quasi impossibilite de faire un jeu de tarot a 3 
> ou 5)
> - a notre experience a coder ce jeu.
> - a ma quantite de temps libre a ce moment la.
> 
> Et on en revient a la question du depart: qu'est-ce qui se passe si on veut 
> rajouter un
> nouveau jeu et que le protocole montre ses limites ?
> 
> Alors il faudra s'interroger si on est capables d'inventer un nouveau 
> protocole encore
> plus souple qui permette de rajouter facilement un nouveau jeu. Et sinon, 
> est-ce qu'il
> ne sera pas plus simple, et tout aussi efficace, de creer un nouveau moteur, 
> independant
> de cardgame_server (mais s'en inspirant, ne nous faisons pas d'illusions) ?
> 
> Et dans ce cas, se pose une nouvelle question: et si on refait un nouveau 
> serveur pour
> un autre jeu, n'y aurait-il pas moyen d'avoir du code commun ou des choses en 
> commun
> afin d'eviter de bosser inutilement ? Ici, j'ai un element de reponse. 
> Evidemment, on
> fera en sorte que cela soit le cas. Mais il faut s'attendre a ce que ce ne 
> soit pas tres
> bien fait, vu qu'on n'aura pas pense a cela au debut. Alors comme pour
> maitretarot_server, une fois qu'on aura des choses qui fonctionneront, on 
> repartira une
> nouvelle fois a zero.
> 
> Il est toujours preferable que ce soit nous qui repartions a zero, plutot que 
> d'autres.
> D'autres n'ont pas notre experience (cf le nombre de jeux de belote ou de 
> tarot sur
> linux) et reproduiront les memes erreurs. Et nous, il vaut mieux repartir a 
> zero, comme
> d'autres le feraient, plutot que de nous embeter avec du code qui deviendrait 
> une usine
> a gaz. Pour info, maitretarot_server est une usine a gaz (cf ce qu'on fait 
> avec les
> channel_sets, qui est joli, mais on peut faire plus simple: cardgame_server)
> 
> Voila, beaucoup de questions, peu de reponses, et tout dependra de 
> l'avancement du
> projet et des volontes de chacun. C'est une reflexion qui arrive tot dans 
> l'avancement
> du projet: on n'en est pas encore la. Mais ca n'empeche pas d'y reflechir 
> deja !
> 
Oula, que de questions :)

Pour le protocole : j'ai reflechit a 2/3 autres jeu et je pense qu'on
devrait s'en sortir proprement.

Mais, bon comme tu le dis : il faut d'abord implementer, faire des erreurs
et puis repartir a zero si on est dans une impasse (cf l'ancien protocole).


Donc : on verra.

La seul chose que je peux dire pour l'instant c'est que quand je compare
le code de libmt_client avec l'ancien protocole et le nouveau et bien
y a pas photo : le nouveau protocole est largement plus propre !


Philippe

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

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