Grooms-jouer au go simplement sur telephone, tablette, ordi

Ici on discute des ressources informatiques pour le jeu de Go. Logiciels pour jouer, pour créer des diagrammes, pour tirer les rondes, etc. Et aussi, on peut lister les ressources en graphisme (artworks, logos, images, etc.).
nadenislamarre
Messages : 13
Enregistré le : dim. 7 oct. 2012 19:23

Re: Grooms-jouer au go simplement sur telephone, tablette, o

Message par nadenislamarre » sam. 13 oct. 2012 14:09

Je suis preneur d'une collaboration.
On peut se contacter par mail (mail sur la page principale de mon site).
Pour la partie connexion serveur vers client (c'est à dire pour que le client soit au courant des coups des autres), il existe des choses dans html 5 pour gérer des vrais connexions il me semble, mais c'est pas encore assez mature (il me semble meme que certains trucs sont désactivés). Pour l'instant, j'ai une page très simple à générer coté serveur :
- je stocke les parties dans un fichier unique avec un format très particulier qu'on pourrait appeler : append go format ;-) c'est un fichier qu'on n'ouvre qu'en mode append, pour des questions de performances, mais à la base surtout pour éviter les collisions entre 2 joueurs qui joueraient en meme temps (le fwrite de 10 octets sera toujours unitaires sur des ordinateurs)
du coup, pour checker l'update, j'ai une info simple : la date du fichier (le nombre de secondes depuis le 1er janvier 1970) qu'on peut obtenir ainsi
(http://grooms.tuxfamily.org/system/stat ... &mode=play) :
=> rapide coté serveur
=> court coté reseau (c'est l'entete http le plus long) on est à maximum 100 octets je pense
=> je le fais toutes les 5 secondes, et fait un vrai refresh si la valeur change (donc quand qq joue, c'est reproduit en moyen 2,5 secondes après si on néglige la durée de refresh) -- bon j'ai un petit bug la dessus que j'ai pas encore validé, donc on a un peu plus parfois en ce moment sur le site

Avatar du membre
fanfan
Messages : 123
Enregistré le : jeu. 18 févr. 2010 19:15
Club : Yosakura Nantes
Niveau : 3d
Pseudo KGS/IGS : fanfan
Contact :

Re: Grooms-jouer au go simplement sur telephone, tablette, o

Message par fanfan » dim. 14 oct. 2012 04:50

Bonjour,

J'ai mis en ligne ce que j'ai déjà fait à http://jeudego.org/play. On ne peut pas jouer de partie contre soi-même, mas il suffit de se créer 2 comptes et de se connecter avec chaque compte dans un navigateur différent pour pouvoir tester. On peut aussi suivre des parties en cours jouées par d'autre sans avoir besoin de compte (mais bon, évidemment, pour l'instant, personne ne joue vu que personne ne sait que ça existe : c'est le vide sidéral).

Je pense que ce n'est pas très bon de stocker les informations dans des fichiers : dans le cas présent, ton hébergeur pourrait te haïr, et tu vas probablement lui remplir ses logs à grande vitesse. Ce serait bien mieux de faire le stockage dans une base de données, parce que c'est "étudié pour" !

Pour éviter les collisions, il me semble qu'il suffit que chaque joueur ne puisse jouer qu'avec une couleur !

Pour ce qui est du format de données, j'utilise le sgf pour envoyer les données au serveur et les stocker dans la base de données. Il n'est pas trop gourmand en espace mémoire, et surtout, tôt ou tard, on doit exporter les données dans ce format, donc autant s'en servir le plus tôt possible. Note que pour une partie en train de se jouer, avec une seule branche de coups, le sgf est un format "append go format". Bref, je te conseille "travailler" en sgf autant que tu le peux et au plus tôt : ça ne sera pas du temps de perdu !

Je n'ai par contre pas du tout optimisé les échanges entre les clients et le serveur (j'utilise AJAX qui est désormais une technique robuste pour balader le sgf partout là où on en a besoin). Le fait de tester s'il y a un changement ou pas et de ne transmettre les données que s'il y en a un ne change pas grand chose au problème de fond : pour faire le test, on est obligé de faire un échange de données entre le serveur et les clients, et ces échanges seront nombreux (si tu n'as ne serait-ce que quelques dizaines d'utilisateurs présents, ces échanges seront en nombre du même ordre de grandeur qu'un site qui a 100 000 visiteurs/jour). Envoyer un octet d'information utile pour demander le test et y répondre ou les quelques centaines d'octets d'un sgf entier, c'est presque pareil vu qu'à chaque échange, y aura les entêtes à envoyer dont le poids sera du même ordre de grandeur que le sgf lui-même. Ceci étant, c'est une très bonne idée de se baser sur l'heure pour détecter s'il y a des mises à jour.

Pour optimiser les échanges, il faut surement en premier lieu chercher à diminuer leur nombre plutôt que leur taille, par exemple en augmentant le temps entre deux tests entre le serveur et un client en cas d'inactivité de ce client (et aussi "déconnecter" complètement les clients inactifs au bout d'un certain temps, c'est à dire faire en sorte que leur navigateur arrête de demander au serveur s'il y a du nouveau). Par contre, pour les clients hyperactifs, 5 secondes, c'est surement trop long.

PS : mes sources sont téléchargeables à http://jeudego.org/gos/_gos6/download.php (prendre la 601b).
C'est tout ce qui restait comme pseudo?

nadenislamarre
Messages : 13
Enregistré le : dim. 7 oct. 2012 19:23

Re: Grooms-jouer au go simplement sur telephone, tablette, o

Message par nadenislamarre » lun. 15 oct. 2012 21:47

>> Je pense que ce n'est pas très bon de stocker les informations dans des fichiers : dans le cas présent, ton hébergeur pourrait te haïr, et tu vas probablement lui remplir ses logs à grande vitesse. Ce serait bien mieux de faire le stockage dans une base de données, parce que c'est "étudié pour" !

Je ne partage pas votre avis. Les bases de données sont étudiées pour stocker un gros volume de donnees, et pouvoir en récupérer facilement les données. Par contre, pour stocker une partie de go ou faire un jeu temps réel, ce n'est pas du tout étudier pour.
A titre d'exemple, si on prend les 2 actions principales de mon jeu : 1. vérifier s'il y a eu une mise a jour 2. jouer
Pour le premier, si on passe par un fichier, il s'agit juste de récupérer l'inode du fichier. Une inode ce n'est que quelques octets. Si y'a 1000 parties en meme temps, il y a de grosse champs que toutes les innodes de chacun des fichiers restent en permanence dans le cache du driver du fs. L'action a une durée de l'ordre de la milli seconde.
Dans le case d'une base, si c'est sqlite, a chaque fois, il y aura instanciation de l'instance, analyse de la requete, calcul du plan d'execution, lecture d'index. On est dans le dizieme de secondes. Pour mysql, on a la connexion a initialiser avec le serveur, le cache requete a lire et les infos a recuperer. On est egalement proche du dizieme de secondes.
Par contre, dans le cas d'une base, il y a le probleme de contention/update des indexes communs aux rooms, ainsi que le probleme que les indexes/tables contiendront l'historique des parties (donc de plus en plus couteux avec le temps) ; enfin, il y a l'administration de la base.
Pour l'écriture d'un coup, c'est pareil, contention sur l'index/table, alors que dans un fichier, vu qu'il y a un fichier par room, pas de soucis.
Le seul avantages de la base, c'est qu'elle permettrait de répondre a des questions type : 'quelles sont les parties ou noir a gagne ?' ou d'autres choses statistiques, mais ce n'est pas le but de mon jeu.

>>Pour éviter les collisions, il me semble qu'il suffit que chaque joueur ne puisse jouer qu'avec une couleur !
Pas forcemment :
- par exemple, dans mon jeu, un joueur peu annuler son coup en recliquant dessus (une erreur de clic, ca arrive)
- dans le cas d'un jeu sur tablette, on n'utilise qu'une tablette pour 2 joueurs

>>Pour ce qui est du format de données, j'utilise le sgf pour envoyer les données au serveur et les stocker dans la base de données.
le sgf a de nombreux inconvénients. En fait, il n'a qu'un avantage, celui pour lequel il a été créé, a savoir qu'il est facile de l'échanger par mail (... il a été inventé à l'époque ou les pieces jointes n existait pas)
Mon gros problème de performance avec le sgf, et que a chaque coup, on est obligé de le réécrire complètement (donc par exemple, si y'a des commentaires, on réécrit facilement plusieurs KO a chaque coup)
Mon format est en append : on ne réécrit jamais rien, meme pour annuler un coup. On n'ecrit que quelques octects à chaque coup.
Ensuite, le sgf est limité à ce qu'il sait faire (ca, on ne peut pas lui en vouloir) mais du coup par exemple, on ne peut stocker qu'un auteur pour tous les commentaires et un seul commentaire par coup ; dans mon jeu, il peut y avoir plusiers commentateurs et plusieurs commentaires par coup.

Avatar du membre
fanfan
Messages : 123
Enregistré le : jeu. 18 févr. 2010 19:15
Club : Yosakura Nantes
Niveau : 3d
Pseudo KGS/IGS : fanfan
Contact :

Re: Grooms-jouer au go simplement sur telephone, tablette, o

Message par fanfan » mar. 16 oct. 2012 01:11

Bonjour,

A propos du débat "stockage dans un fichier" ou "stockage dans une base de données" : évidemment, si tu supposes que les accès disque se passeront presque toujours en cache, tu as raison de penser que l'approche "stockage dans un fichier" sera plus rapide. Toute la question se résume d'ailleurs quasiment à ça : quelle approche utilisera au mieux les caches ? Il faudrait tester pour se faire une idée ! Si ça se trouve, ça revient au même et on phosphore pour rien ! Note que je ne suis pas spécialement un fan de l'approche base de données. Il y a encore à peine quelques années, je préférais mettre tous mes sgf dans des fichiers : j'ai changé d'avis !

A propos des collisions : la reprise d'un coup peut être gérée par une demande à l'adversaire et non en retirant immédiatement le coup. De plus, assez rapidement, on va te demander de mettre en place une horloge pour décompter les temps de réflexion, ce qui va probablement t'obliger à identifier quel client joue avec quelle couleur. Au passage, ça n'empêche nullement de jouer à deux sur un client unique. C'est juste une option à rajouter. Ceci dit, ton approche actuelle consistant à n'identifier personne, et à poser sur le goban le premier clic détecté quelque soit le client d'où il vient est merveilleusement simple et me plait beaucoup.

A propos des avantages d'une base : tant qu'on se limite à un ensemble de "salles" et qu'on n'identifie personne, on n'a en effet pas besoin de base de données. On a juste une collection de fichiers dont les noms contiennent le nom des salles correspondantes et puis c'est tout. Mais à mon avis, tu ne vas pas te limiter à ça bien longtemps. Déjà, quand tu vas vouloir commencer à identifier les intervenants (et je suis certain que tu vas le vouloir tôt ou tard), le faire sans base de données, ça va se compliquer !

A propos du sgf : j'ai déjà connu plusieurs générations de petits scarabées qui ont essayé d'inventer autre chose : bienvenue au club ! :-) Je suis certain que ton format est meilleur dans ta situation actuelle car parfaitement adapté à ton problème. Néanmoins, outre le fait que le sgf est quand même bien adapté aux parties de go (en particulier dès qu'on fait des parties commentées) et très répandu, je sais aussi que tant qu'on ne revient pas en arrière (le retour arrière devrait rester exceptionnel en partie normale) le coup suivant se met justement en fin de fichier sgf (il suffit d'omettre la dernière parenthèse systématiquement), et que pour les commentaires multiples, rien ne semble empêcher de les concaténer au fur et à mesure en un seul commentaire (ce que tu vas surement faire quand tu exporteras tes données vers un sgf) et éventuellement en préfixant chaque intervention par l'identifiant de son auteur (à condition toutefois que tu mettes en place une identification des différents intervenants : on revient alors à l'idée d'identifier les clients comme pour savoir à qui c'est de jouer et éviter les collisions). Et du coup, on devrait rarement à avoir à réécrire tout le fichier lors d'une partie normale, même avec commentaires éventuelles des observateurs au fil de l'eau (il suffit d'omettre aussi le crochet fermant du commentaire tant que le coup suivant n'est pas joué). Évidemment, s'il s'agit d'une partie commentée, avec variantes multiples, et nombreux retours en arrière, c'est complètement différent.
C'est tout ce qui restait comme pseudo?

Avatar du membre
fanfan
Messages : 123
Enregistré le : jeu. 18 févr. 2010 19:15
Club : Yosakura Nantes
Niveau : 3d
Pseudo KGS/IGS : fanfan
Contact :

Re: Grooms-jouer au go simplement sur telephone, tablette, o

Message par fanfan » mar. 16 oct. 2012 08:31

Bonjour,

J'ai fait quelques tests rapides sur plusieurs machines pour comparer la vitesse d'un update en base de données (ajout dans une table de l'ensemble d'un sgf) et d'un append sur un fichier (ajout en fin de fichier de quelques octets) : l'update dans la base est environ 3 à 5 fois plus lent que l'append dans le fichier.

Note : ces opérations durent de l'ordre de 0,01 à 0,2 millisecondes chez moi (en considérant uniquement l'update et le append).
C'est tout ce qui restait comme pseudo?

nadenislamarre
Messages : 13
Enregistré le : dim. 7 oct. 2012 19:23

Re: Grooms-jouer au go simplement sur telephone, tablette, o

Message par nadenislamarre » mar. 16 oct. 2012 09:26

>> Déjà, quand tu vas vouloir commencer à identifier les intervenants (et je suis certain que tu vas le vouloir tôt ou tard), le faire sans base de données, ça va se compliquer !
- on est bien d'accord que c le coeur du probleme. pour l instant, j'essaie de camper sur ma position (en attendant ques les idees viennent). je reste egalement dans l idee de garder le jeu simple ; on va voir combien de temps je vais tenir (pour l instant c facile, j ai un bras de moins, donc je ne touche plus trop a l ordi - du coup je n ai pas encore regarde votre programme non plus - pas avant plusieurs jours ;-()

j'ai ca en valeur :

nicolas@setsouko:~$ time echo > /tmp/aa
real 0m0.001s
user 0m0.000s
sys 0m0.000s

mysql> create table go_move(id integer, x integer, y integer);
Query OK, 0 rows affected (0.08 sec)

mysql> insert into go_move values(1, 1, 2);
Query OK, 1 row affected (0.04 sec)

mysql> create index gg on go_move(id);


mysql> insert into go_move values(2, 1, 3);
Query OK, 1 row affected (0.04 sec)

mysql> insert into go_move values(2, 1, 3);
Query OK, 1 row affected (0.05 sec)

nicolas@setsouko:~$ time stat /tmp/aa -c %y
2012-10-16 09:16:51.753444079 +0200

real 0m0.005s
user 0m0.000s
sys 0m0.000s

TeoNC
Messages : 1
Enregistré le : jeu. 10 janv. 2013 16:56

Re: Grooms-jouer au go simplement sur telephone, tablette, o

Message par TeoNC » jeu. 10 janv. 2013 18:22

Je viesn de jetter un coup d'oeil (de débutant)
vraiment bonne idée et réalisation

A première vue, et en spectateur, je dirai quil manque au moins une chose : le chrono avec les tempms de chacun
puis (mais ça existe peuyt êtyre déjà, mais invisible aux visiteiurs) le paramétrage de la partie avant de commencer
(Dimension du Goban, handicap...)

Avis d'un débutant... à prendre comme tel

Teo

nadenislamarre
Messages : 13
Enregistré le : dim. 7 oct. 2012 19:23

Re: Grooms-jouer au go simplement sur telephone, tablette, o

Message par nadenislamarre » sam. 2 févr. 2013 19:11

le chrono existe désormais.

francoisb
Messages : 3
Enregistré le : mer. 29 mai 2013 23:27
Niveau : 6k
Pseudo KGS/IGS : Pelansowa

Re: Grooms-jouer au go simplement sur telephone, tablette, o

Message par francoisb » jeu. 30 mai 2013 20:05

fanfan a écrit : [...] je crains que les performances du serveur web ne s'écroule. En effet, pour que l'ensemble fonctionne avec une certaine fluidité, cela nécessite que toutes les pages des "clients" (c'est à dire les joueurs, mais aussi les observateurs) soient rafraichies régulièrement (disons chaque seconde). Ce point est problématique car les serveurs web "de base" ne sont pas du tout faits pour ça [...]
Bonjour fanfan,

il existe maintenant des technologies pour gérer ce genre de problème sans avoir a demander a chaque client de "rafraichir" toutes les secondes (ce qui est bien sur trop gourmand en ressources).

http://fr.wikipedia.org/wiki/Comet_(informatique)
http://fr.wikipedia.org/wiki/Server_push

Pour ma part, j'utilise .net/C# cote serveur et la librairie http://signalr.net marche très bien quand il s'agit de d'envoyer des info du serveur a une multitude de clients en temps réel.
Pelansowa

Vidéos de Go en français: https://www.youtube.com/user/dvo4you

Avatar du membre
fanfan
Messages : 123
Enregistré le : jeu. 18 févr. 2010 19:15
Club : Yosakura Nantes
Niveau : 3d
Pseudo KGS/IGS : fanfan
Contact :

Re: Grooms-jouer au go simplement sur telephone, tablette, o

Message par fanfan » dim. 2 juin 2013 22:02

Bonjour,

L'idée est de tout faire en php+javascript.

Si on s'autorise autre chose, on a évidemment beaucoup de possibilités.
C'est tout ce qui restait comme pseudo?

Répondre