Salut, je cherche un moyen de gérer des buzzers pour faire des quiz. En gros il me faut quatre ou cinq buzzers tels qu'on puisse déterminer facilement qui a buzzé en premier.
J'ai trouvé des schéma pour faire ça sous la forme d'un circuit électrique, avec quelques fils, des leds, et un lot de porte AND qui permettent de n'avoir qu'une led d'allumée. C'est pas mal mais ça ne m'a pas l'air très pratique, ou alors il me faudrait de meilleurs boutons, et puis je n'a pas de pratique en électronique ce qui me met dans une position incertaine.
J'ai trouvé d'autres projets à base de micro-contrôleurs, ce qui serait encore plus incertain.
J'ai trouvé des sites et apps de quiz, mais moi je veux juste un buzzer.
Tel que je vois le truc, il faudrait :
- un service web pour héberger une partie,
- une interface web admin pour créer la partie et gérer les votes.
- une interface web pour que les clients puissent rejoindre une partie et buzzer.
Lorsqu'un joueur buzze l'admin le voit dans son interface et les buzzers des autres sont bloqués pendant quelques secondes.
As-tu connaissance d'un tel logiciel ? Une app Android pourrait faire l'affaire mais idéalement un service que je pourrais exposer sur mon réseau local sera bien suffisant.
# un buzzer distribyé qui passe par du HTTP(s) ou autre c'est complqué
Posté par totof2000 . Évalué à 4 (+2/-0).
LA latence réseau fait que tu ne pourras pas vraiment déterminer qui a buzzé en premier, à moins d'avoir une synchronisation parfaite entre les horloges des systèmes qui buzzent, et d'envoyer la date de l'evenement dans la réponse pour pouvoir comparer. De plus il n'est pas non plus garanti que les utilisateurs recevront en même temps la possibilité de buzzer au même moment (certains auront peut-être leur interface prete à buzzer avant les autres ) … Donc un système basé sur smartphone et communication réseau ne me parait pas très fiable au premier abord.
[^] # Re: un buzzer distribyé qui passe par du HTTP(s) ou autre c'est complqué
Posté par guitou . Évalué à 2 (+1/-0).
Hello.
Sauf a etre vraiment ambitieux, on peut se baser sur la reception de la requete buzz sur le serveur, d'autant sur un reseau local ou les latences devraient etre minimes et donc les ecarts negligeables.
Cependant, si les clients font du poll, pour avoir la dispo du buzzer au debut, la, y'a deja plus de risques d'inegalites (de l'ordre de l'intervalle entre 2 requetes, mais pas plus). Le plus simple reste sans doute de trouver un intervalle de poll acceptable (bien supportable pour le serveur, mais assez court pour la jouabilite), mais on peut aussi gerer ca avec un service cote clients pour etre au plus juste.
++
Gi)
[^] # Re: un buzzer distribyé qui passe par du HTTP(s) ou autre c'est complqué
Posté par nico4nicolas . Évalué à 2 (+0/-0).
Même sans une synchronisation parfaite, on peut avoir des résultats relativement suffisant pour l'application désirée. NTP permet d'avoir une précision à quelques dizaines de millisecondes près (dans le pire des cas) et de calculer la dérive entre 2 synchronisations. C'est toujours plus rapide que les réflexes humains.
La vitesse de l'électricité dans le corps humain est d'environ 15m/s, donc pour parcourir la distance cerveau -> doigt, l'électricité met environ 60ms. Il n'est pas nécessaire d'être plus précis que cela.
Ta solution avec synchronisation et envoi d'un horodatage me parait donc suffisante.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.