Inauguration

A not so thrilling day for a first logbook entry:

– The power board of my laptop seems to have died,

– 3 studious TH with Alexis,

– Flo and I decided how should we work on the BLE tutorial,

– First thoughts (in French) on the first project, sent to the mailing list (that will probably never publish them):

Avant de parler technique, voici une proposition de scénario de jeu (sans trop faire attention aux contraintes) pour qu’on parte sur les mêmes bases. Qu’est-ce que vous en pensez ? Ça peut être assez marrant.

– Les participants (sorciers) ont une baguette connectée à leur smartphone, qu’ils portent à la main ou à la ceinture.
– Un sorcier peut saisir sa baguette, la pointer vers un autre sorcier.
– La baguette s’active, il peut alors jeter un sort avec un geste bien précis, en récitant éventuellement une formule.
– La baguette y réagit (son, lumière, vibration, …), mais le sort n’est pas instantané (pour laisser du temps à l’autre, les avada kedavra dans le dos c’est lâche).
– En parallèle le smartphone de l’attaquant contacte le serveur et l’informe de l’attaque.
– Le serveur décide si : l’attaque est autorisée (niveaux un peu équivalents, que Dumbledore ne s’attaque pas à Neville), si le sort est autorisé (valide, bien fait, “débloqué” en fonction du “niveau” du sorcier, si le sorcier a suffisamment de points de mana pour l’envoyer).
– Si oui, le serveur contacte le smartphone de l’attaqué, il le notifie (vibration du téléphone ou de la baguette, son (formule), …)
– Si non, la baguette montre au sorcier que le sort a échoué.
– Si le sort est valide, l’attaqué doit se dépêcher de faire une parade (validée ou non par le serveur comme ci-dessus).
– Un combat peut ensuite avoir lieu si les sorts ne sont pas létaux (ils peuvent diminuer le karma, faire baisser une “jauge de vie”, …)
– On peut envisager plusieurs types de sorts de combat (la baguette tremble, le téléphone hurle et vibre, la baguette envoie une décharge, on devient indétectable/inattaquable) et même des sorts un peu plus longs (l’autre regagne plus doucement des points de karma, l’autre blesse ses coéquipiers quand il utilise un sort à leur proximité, etc., et leurs contraires).
– Le combat se termine quand le serveur décide un vainqueur (après un sort mortel, ou avec une heuristique de combat : celui qui fait le mieux les gestes, qui crie le plus fort, qui vise le mieux, …). Le bilan du combat a un impact sur l'”expérience” des sorciers (déterminé par le serveur).
– L’expérience des sorciers débloque des sorts, des parades, …
– Le tout peut se faire en équipe (règles classiques : dernier en vie, sorcier à protéger, …).
– Le serveur peut éventuellement “provoquer” des combats quand deux joueurs sont à proximité (en allumant les baguettes, comme l’épée de Frodon).
– … ?
La baguette pourrait aussi avoir une fonction d'”apprentissage” pour guider le geste des sorciers qui apprennent un nouveau sort.

Et ensuite, quelques réflexions sur le système :

On parle donc d’une super baguette magique (a priori imprimée en 3D ?) avec des capteurs (Alexis évoquait la centrale inertielle, vu le scénario ci-dessus on peut aussi penser à un micro pour entendre/confirmer le sort qui va avec le geste, un capteur de pression pour que la prise en main de la baguette joue également, ..), et des LED/retours haptiques pour donner vie à l’action en cours (pourquoi pas un mini haut-parleur pour seconder le téléphone, un mini buzzer électrique pour faire lâcher la baguette sur certains sorts, ..?).

Si on a plusieurs personnes en face de nous il faut aussi un moyen de viser (infrarouge par exemple ? pas très précis ni très robuste en extérieur.. vous avez des idées ?). À moins qu’on ne choisisse notre adversaire au préalable sur notre téléphone (mais niveau gameplay ça casse pas mal le truc).

Il faut ensuite que la baguette transmette ces infos au smartphone (connecté en Bluetooth Low Energy). À lui ou au serveur d’identifier le geste, le son, etc. Si un des objectifs est d’empêcher les gens de tricher il faudra réfléchir à authentifier le sort (donc la baguette et/ou le téléphone), ce qui n’est pas un détail puisque ça a un impact direct sur la construction de l’API.

Il faut ensuite reconnaitre la signature d’un geste à partir des données inertielles et de la signature vocale en la comparant à une BDD, c’est de l’info rigolote. On peut faire ce travail au niveau du téléphone pour minimiser les données échangées avec le serveur, ou niveau serveur pour, entre autre, être sûr qu’on utilise la même version de la BDD des deux côtés et restreindre la possibilité de frauder.

L’API reprendrait globalement les contours du scénario avec des objets Sorcier, Sort, Parade, …, qui pourraient interagir entre eux.

Le serveur fait ensuite le lien entre les smartphones (ou est-ce qu’on essaie de le court-circuiter un peu pour éviter la latence ? wifi direct, bluetooth (pas LE), …?). Le “ou pas” veut dire qu’il faut vérifier qu’on arrive à faire des aller-retours incessants avec le serveur sans détruire l’interactivité du jeu (si on a une seconde d’attente pour que le sort arrive dans la baguette du voisin ça risque d’être chiant). Le serveur permet de lancer une partie et d’en définir les règles, les joueurs peuvent rejoindre une partie avec un identifiant (ou en NFC, etc.). Il valide le déroulement de la partie, authentifie les joueurs et maintient leur profil à jour. Il se charge de l’expérience et des équipes et il peut par exemple envoyer de nouveaux sorts vers les téléphones des sorciers (qui sont notifiés) au fur et à mesure qu’ils sont débloqués.

– Subsequent email exchanges and sparse thoughts on the Battle Royale project,

– Translation of this blogpost in order to match the (too easily forgotten) instructions of one of our BDFL Alexis.

3 comments to Inauguration

  • Alexis Polti

    Didn’t we say that you had to post in english ? 🙂

  • lerela

    Sure thing

  • allegrem

    Love the Harry Potter project!! I really look forward to seeing how you’re going to handle the aiming.

    About the server, I would recommend you not to worry too much about the latency. I guess you prefer to assume that the players have a reliable connection, instead of handling adhoc connections, server sync, offline fallback, pattern recognition on the smartphone, very likely a lot of code duplication between the server and the client, etc… Plus, you can afford a little more latency than a feedback after pressing a button: the end of a gesture is more vague than the end of a button press.

    May the force be with you 😉