Reprise du message précédent :

Oui mais ça simplifierai la programmation des bots aussi...

Bah.. vaut mieux quand meme.. ça mange pas de pain..
et je trouve que c'est + reglo..

Je vois pas...je connais pas de langage dans lequel ce soit difficile de stocker un tableau de 7*8...

y'a un truc que vous oubliez : HTTP n'est pas connecté. Comment un joueur sait qu'il doit refaire une requete ?
 
d'apres moi utiliser http pour ce genre de choses c'est une belle connerie  

Bah si on communique via du html c'est sur que c'est pas couteux pour le serveur...mais inutile...

 
ben le "prog maman" repondra bien evidemment..  

Ca risque de poser des pbs de synchro éventuellement oui...mais ils sont sûrs de leur coup là...

le pb c'est s'il met pas à jour la réponse assez vite, un bot pourra avoir l'impression qu'il a la parole alors que c'est plus à lui...si entre-temps l'autre a déjà répondu, ca risque de merdoyer grave...

repondra comment ?
 
imaginons : je joue, le serveur me réponds ok ou coup invalide ou autre (une page, donc), et la connexion coupe.
 
le serveur ne peut pas prendre l'initiative de contacter un client    
 
 
====> Droit dans le mur, concours a la con, blabla tout ca

nan, c'est meme pas ca le probleme, cf plus haut

[bot1 mode ecoutage]
[bot2 mode ecoutage]
 
bot1> je joue coup dans colonne 2
[bot1 mode ecoutage]
maman> ...
bot1> (timeout detected) je joue coup dans colonne 2  
[bot1 mode ecoutage]
maman> message reçu, au tour du bot2
[bot1 mode ecoutage]
bot1> je joue coup dans colonne 3
 
etc...

 
   
 
tu cherches loin la.. si tu coupes le cable (figuré bien sur) et ben il est normal que ça ne marchera plus..
(Puis d'ailleur le serveur surveillera le timeout et le considerera comme une defaite..)

boulay
 
1. connection, c'est en anglais, en francais on parle de connexion.
2. déconnexion, au niveau socket, pas au niveau physique.
 
t'es vraiment un gros naze

ce qu'il veut dire, c'est qu'une connection HTTP n'est pas persistente !
donc si le serveur envoie la réponse au client et qu'entre temps tu perds la connection, tu fais quoi ?

Il va aussi falloir gérer des conneries comme ca:

 
mais le serveur dit oui jusqua ce que le bot ai confirmé sa lecture du oui..
 
   ou est le probleme??

nan, meme pas de ca que je parle, je parle du fonctionnement normal, apres envoi de la page, la connexion coupe, c'est normal, pas une erreur, mais ca fout votre délire en l'air  

 
1. ta gueule    
2. ta gueule    
3.    
 
PS: putain la honte.. aujourd'hui on ma corrigé un "connexion" en "connection"..    merde quoi.. la honte!   d'ailleur j'ai du le prouver a la personne en cherchant dans le dico.. pff..

Ton client n'a qu'à boucler. Il fait une connec au serveur, attend la réponse 10 secondes et si rien n'arrive, il casse la connec pour la relancer
 
Evidemment, HTTP n'est pas du tout le protocole adapté pour ce genre de choses. Mais il a le grand avantage de pouvoir passer les proxies plus facilement qu'une connexion sur le port (au hasard) 589

 
c'est toi qui delire la!  

Non, c'est du déconnecté, c'est tout. Mais tu peux tout à fait simuler une protocole connecté avec. Par contre, c'est pas du tout la panacée ; moi j'dis que si vous avez pas de contrainte de firewall ou autre, faites une bête connexion TCP de socket sur un port quelconque. C'est bien plus adapté.

fais ton serveur, fais un bot, et on en recause, ok ?

Bon ça part sur du n'importe quoi là ! Lorill a raison de toute façon : hors de question d'utiliser du HTTP pour ça, c'est ingérable.
Voici ce que je propose : on met en place notre propre protocole de communication avec des commandes simples ! Inutile de s'emmerder avec un fichier XML quand 2-3 commandes bien choisies font parfaitement l'affaire !

C'est ce que je pensais dès le départ...

 
 
j'ai fait des spectacles en direct.. des chats.. des question/reponse.. le tout en http..
et ça a toujours tres bien marché.. j'ai eu 40 personnes connectées.. aucuns problemes..
 
   
spa bien compliqué en plus..
 
 
Bah je bidouille un serveur.. dans 1 semaine ça devra etre prêt (hé oui j'ai du boulot aussi moi..    )

On choisit un port, 2/3 commandes et c'est plié...

dans ce cas il faudra un serveur à nous et tout..  

Il y a pas quelqu'un ici qui a une IP fixe?

moi j'ai une IP à peu près fixe mais j'ai pas de machine... à moins que votre truc tourne sur un PC sous Linux sans disque dur avec 1 Mo de RAM libre

-- s'est déjà proposé aussi  

ben ouais j'ai pas d'ip fixe mais un dyndns qui marche bien
mais bon, pas de bp illimitée.
cela dit 5? par mois ça serait pas la mort en se cotisant

Bon on verra l'hébergement plus tard, c'est pas urgent de toute façon !  
Faut mettre en place les attributions du serveur et le protocole !
 
Bref aperçu de la boucle du serveur :
- Ecouter les demandes de connection sur un port xxx
- Attribuer une place sur le plateau de jeu à chaque joueur, à concurrence de 2 joueurs maxi. Les autres sont en attente.
- Envoyer une commande (BEGIN par exemple) à chaque joueur pour signaler que la partie commence
- Choisir aléatoirement le joueur qui jouera le 1er coup
- Victoire = false
Tant que (victoire == false)
(1) Envoyer une commande au joueur dont c'est le tour et mettre à jour une variable indiquant le joueur qui jouera le prochain tour
(2) Recevoir la réponse du client
(3) Evaluer le plateau de jeu (4 couleurs alignées ?)
(4) Si évaluation positive, victoire = true
(5) fin Tant Que
 
A peaufiner, mais ça peut être un bon début

harko >>
ta solution n'utilise pas http alors? tu prones plutot un mode connecté?
pq 2 joueurs maxi? c pas compliqué de gerer plusieurs rooms...
 

Oui, c'est largement préférable je pense, sinon on va passer plus de temps à implémenter des timers et autres conneries de surveillance que l'algo en lui même
 

ben le vrai puissance 4 se joue à 2

timers? ha, pour voir quand c'est à ton tour de jouer...
hmmm. ouais, pas faux. mais
- une fois implementé on pourrait imaginer releaser le framework(qui gererait la comm etc) pour chaque langage, le concours ne portant pas sur celui-ci, mais sur le reste.
- au niveau du serveur ça serait plus simple en mode deconnecté j'ai l'impression
 

beh tu peux avoir plusieurs tables (rooms) avec des jeux qui tournent en parallèle

on a qu'a faire un faux puissance 4  

un puissance -- \o/

 
+1 --  

 
Bon, j'ai lu en diagonal, et je ne voie pas de raison d'abandonner le protocole HTTP pour un truc propriétaire.
 
Pour les problèmes de synchros, le plus simple, c'est que Maman envoie un état complet du jeu (en XML par exemple) au bot dans le cas d'une réponse "Oui, c'est à toi de jouer".
Comme çà, quand un bot joue, c'est toujours avec des données à jour, même s'il joue 15 fois de suite à cause d'une connexion qui merde.
 
Les réponses possibles du serveurs (Liste non exhaustive) :
(Je vous laisse immaginer les requêtes du client...)
 
"Oui c'est à toi de jouer : état de la partie..."
"Non, c'est pas à toit de jouer"
"Bravo, tu as gagné contre XXX. Prochaine partie contre YYY"
"Tu as perdu contre XXX. Raison :"
   "XXX a joué un coup gagnant : état de la partie..."
   "Mauvais coup" <- si un bot fait un coup invalide, c'est pas la peine d'aller plus loin, sinon çà peut durer longtemps !
   "Tu as mis trop de temps à répondre"
 
"Liste des parties en cours auquel tu participes : En particulier, celle qui attendent que tu joue (indication du timeout pour chacune)!"
"Liste des parties/tournois ouvert auquel tu peux t'inscrire"
"Inscription enregistrée. Il est JJ/MM/AAAA HH:MM:SS. Le tournoi démarre à JJ/MM/AAAA HH:MM:SS + x"
"Inscription non prise en compte. Raison :"
   "Plus de place"
   "Joueur inconnu"
   "Tournoi commencé"
   "..."
"Joueur inconnu"
"Partie inconnue"
 
Sinon, le puissance 4, c'est une bonne idée pour commencer.
 
Enfin, si l'envoie de l'état complet du jeu (c'est rien pour un puissance 4) devient compliqué à gérer, on peut aussi numéroter les coups. Il faut aussi informer le bot du coup de son adversaire. Donc s'il joue le coups 5, et que maman lui redemande le coups 5, y'a pas de problème non plus !

surtout qu'une grille de 7x8 ça ne fait jamais que 56 bytes (au pire, parce qu'on pourrait coder l'info sur 2 bits, pas vrai harko? ) donc autant envoyer une chaîne de 56 bytes pour l'état du jeu

Bon pour la communication vous faites comme vous le sentez, finalement comment c'est implémenté ca change pas grand-chose je suppose...par contre si c'est http je touche pas au code du serveur, ca c'est sur!