Worklog for an unnamed project

Coucou !

Me voilà devant vous en ce soir tardif pour vous présenter un petit projet qui est en train de germer dans mon ordi ; j'ai peur que le fond comme la forme soient assez atypiques pour rebuter certains, mais bon : partager est bénéfique pour l'émulsion, je suis d'humeur à écrire, et j'ai envie de faire vivre ce forum. Trois bonnes raisons, c'est bien assez.

Alors, de quoi ça s'agit !

Brève présentation

Il appert (du verbe apparoir, allez vous cultiver, il est joli) qu'au long de mes tribulations sur cette toile où nous sommes tous pris au piège, j'ai croisé à de nombreuses reprises dans la communauté francophone des aveugles et déficients visuels technophiles. L'un d'eux a même été mon gourou dans l'apprentissage du langage auquel je voue désormais ma prédilection, Python.

J'en ai gardé deux amis proches, dont l'un avec lequel je dissertais récemment de la crise que subit le marché des jeux accessibles (alias audiogames) : à savoir, y'en a pas. Ou peu. Ou ils sont mauvais. Et ce, pour des raisons assez évidentes qu'il est inutile de détailler ici (on peut en parler plus bas dans le thread, si vous voulez). Je cherchais un projet à mener à plus ou moins long terme, d'abord pour me dérouiller les doigts en sortant de prépa, ensuite pour avoir quelque chose de concret sous le coude ; l'idée était toute trouvée.

L'idée

Je m'y suis lancé il y a quelques semaines : la création d'un moteur de jeu destiné explicitement à la création de jeux accessibles, en Python. Pour être précis, j'ai suivi le schéma de réflexion classique ("bah, je vais faire un jeu accessible" $\rightarrow$ "ah oui, mais j'aurai besoin de telle ou telle fonctionnalité générique" $\rightarrow$ "bon, autant commencer par un moteur et voir ce qu'on peut en faire") et me voilà devant vous pour vous présenter le fruit de mes entrailles !

Avant que je m'égare, rentrons dans le vif du sujet

Mon objectif est de coder un moteur basique, proposant un empilement de couches d'abstractions suffisant pour que le développement d'un audiogame quel qu'il soit, soit facilité sans être prémâché. Et quand je dis quel qu'il soit, on peut envisager parmi les possibilités (liste non exhaustive) :

• un sidescroller (genre très en vogue chez les DVs) ;
• un RPG avec une dimension exploration sonore spatialisée ;
• un Point&Click, sans pointer ni cliquer (j'ai des idées là-dessus) ;
• un jeu de combat à la SF ;
• …

Pour cela, j'ai conçu et (en partie) spécifié une architecture modulaire que je décortiquerai dans le paragraphe suivant. Je suis actuellement en train de développer les modules de base du moteur ; partant de là, n'importe qui pourra prendre le code source du moteur une fois achevé et y greffer autant de modules de jeu qu'il le voudra, développés par ses bons soins et constituant ainsi, un jeu réel. Simple comme bonjour, hein.

L'architecture, comme promis :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

- abstraites
    - module        # classe abstraite des modules
    - objet         # la même pour les objets enregistrables
- bases
    - config        # module de config
    - log           # devine...
    - importeur     # gestionnaire des modules primaires, le papa du moteur
- primaires
    - interpreteur  # module d'interprétation des interactions utilisateur
    - audio         # module de gestion du son (TTS entre autres)
    - affichage     # l'affichage, parce qu'il en faut un peu, parce que je ne suis pas DV !
    - enregistreur  # ben, module d'enregistrement

Tous ces modules sont coordonnés par un fichier à la racine qui les appelle dans l'ordre voulu ; la boucle d'exécution est gérée par l'importeur, qui a la main sur tous les modules ; chacun des modules primaires est au même niveau dans la hiérarchie, et peut interagir avec tous les autres. Ainsi, il suffit d'ajouter les modules pertinents pour que ce squelette devienne un jeu fonctionnel, comme je le disais plus haut.

Pour l'instant, les modules de config et de logging sont achevés, la conception et la programmation de la classe abstraite des modules et de l'importeur en bonne voie, et je spécifie le reste en parallèle. Oui, c'est seulement un début. D'ailleurs, si vous avez des commentaires ou des questions sur mon choix d'architecture, ils sont très bienvenus ; rien n'est gravé dans le marbre pour l'heure (j'attends d'avoir un interpréteur Python compatible avec le marbre, mais ça coûte cher).

Les choix technologiques

J'allais oublier d'en parlé, et pourtant j'ai eu du mal à me fixer. Le principal problème a été de trouver un moyen efficace de faire du TTS en Python 3.x, puisque je tiens à ma version 3. J'ai fini par trouver une lib nommée SteelTTS, la 2to3iser, et je suis satisfait de ce que j'obtiens. Pour ce qui est de la gestion de l'interaction, du son et de l'affichage fenêtré (nécessaire), j'ai choisi pySFML qui a le mérite inestimable d'offrir une spatialisation sonore efficace. Et en conséquence de ces choix, me voilà avec Python 3.2.4…

Le mot de la fin

Choucroute. Non, je plaisante ; ce thread vous est légué, toutes les remarques, conseils et questions sont les bienvenus ; notamment, si vous souhaitez un peu de détail sur les spécifications des modules vus plus haut, dites-le (j'ai été un peu évasif). Pour le reste, je posterai de temps en temps pour parler de mon avancée, évoquer les problèmes que je rencontre, tout ça (d'où le titre de worklog). Bonne soirée !

_Choucroute.

J'ai un peu de mal a imaginer ce que peut représenter ce type de jeu mais je te souhaite bon courage, c'est un beau projet !

Tu as pensé a rentrer en contact avec des assos de DV ? ils pourraient probablement t'aider, t'apporter des idées ou un soutient.

J'ai un peu de mal a imaginer ce que peut représenter ce type de jeu

Bonne question. En fait, faut raisonner par l'exemple ; pour ce qui est des jeux de baston, savais-tu qu'il existe une importante communauté DV autour de Street Fighter IV ? En effet, le jeu est entièrement spatialisé (sur un plan de gauche à droite) et donc parfaitement jouable, moyennant un temps d'apprentissage des coups, persos et d'utilisation des menus.

Les sidescrollers reprennent généralement cette spatialisation plane de gauche à droite, en y ajoutant un certain nombre d'outils pour aider à la perception de l'environnement virtuel (radars, TTS pour les interfaces / dialogues / textes divers).

Pour ce qui est d'un jeu à exploration, imagine un simple écran noir — et quand tu mets ton casque, tu entends ce qu'entend ton personnage, en presque trois dimensions (avant, arrière, gauche et droite puisque le haut et le bas sont quasi impossibles à rendre par ordinateur). Des bruits de pas non spatialisés, un ruisseau à ta droite, le vent qui souffle et les oiseaux qui chantent, etc. De plus, tu disposes d'un radar qui t'annonce à la demande, ce qui se trouve devant toi, et d'autres outils du même acabit.

Les possibilités sont assez fascinantes à explorer, d'autant que ça sort complètement de ce qu'on a l'habitude de voir sur le marché des jeux pour voyants !

Tu as pensé a rentrer en contact avec des assos de DV ?

Je pense que mes contacts parmi la communauté devraient suffire, mes amis sont des gros geeks qui savent assez bien ce qu'ils attendent d'un bon audiogame et ce qu'en attend le public en général.

Merci pour ton message, en tout cas !

Ben merci pour le commentaire !

Alors c'est marrant ce que tu dis, il se trouve que les aveugles sont assez blasés de ce genre de jeux, parce que la plupart des audiogames existants reprennent exactement ce principe : le héros est aveugle, ce qui justifie le gameplay, mais c'est une facilité qui en gonfle un certain nombre, qui préféreraient jouer à des jeux qui ne les particularisent pas (et ça se comprend).

Par contre, à destination d'un public voyant et en adoptant une approche beaucoup plus progressive et soignée, ça serait intéressant indeed !

Puisqu'on en est à rêver, pourquoi pas un FPS pour DV ?

Je veux dire, pas juste un Point&Click, mais un fps 3d (pas affiché on est d'accord, mais le monde l'est), avec 2 radars qui subissent une variation sonore (volume, tessiture, ou autre), l'un pour viser le joueur le plus proche, l'autre pour déterminer la distance du prochain obstacle devant soi.

C'est une idée faites en 10s, donc elle est peut-être complètement stupide, mais je pense qu'on peut arriver à se débrouiller pour entendre 2 sons à la fois, même pour des non DV.

Ou alors utiliser un casque et jouer sur l'intensité du son sur chaque oreille : si elle est identique, c'est que la source est devant ou derrière ; si l'oreille gauche n'entend presque rien - en caricaturant -, c'est qu'elle est à droite…

si elle est identique, c'est que la source est devant ou derrière

Du coup il faudrait un indicateur qui signale si c'est devant ou derrière. Un son continu si c'est derrière, des "bips" si c'est devant ?

Je développe un peu l'idée:

Il faudrait donc un son continu pour l'obstacle devant, et un "bip" pour le joueur ennemi le plus proche (pourquoi les DV ne pourraient pas faire du TDM ?). Le bip est spatialisé, et continu si on est bon (= on tire et on shoote le joueur), et à priori aigu, puisque le radar d'obstacle sera lui un son tout le temps continu, donc plutôt plus grave sinon ça va vite faire suer.

Le radar d'obstacle est donc constitué d'un son continu. Pour éviter de se péter les oreilles il me semble qu'il serait mieux de le faire varier en tessiture plutôt qu'en volume.

Du coup, vu le truc, par rapport à un fps visuel, ça renverse pas mal les difficultés des armes, parce que shooter quelqu'un au sniper au son, ça se fait à peu près pareil qu'en visu, mais avec une mitraillette, déjà qu'il faut réussir à bien suivre le joueur qui s'enfuit (s'il s'enfuit), en plus il va falloir se repérer avec le radar joueur qui est continu, donc qui peut masquer celui d'obstacle, plus le fait qu'une mitraillette, ça fait du bruit …

@AmarOk : merci beaucoup ! Des commentaires comme ça, c'est super encourageant et ça me donne envie de continuer (malheureusement, ces jours-ci c'est pas la joie avec la rentrée, l'installation… à Rennes d'ailleurs, si je ne m'abuse c'est là que tu crèches ; j'espère avoir le temps de m'y remettre correctement dans la semaine).

@Vayel et dosmpm : vous êtes en train de réinventer plein de concepts existants, c'est rigolo. Un FPS pour DV, figurez-vous que ça existe déjà et ça s'appelle AudioQuake. Et oui, comme son nom l'indique, c'est un Quake (Quake I, le vieux, le fondamental) ultra-moddé pour être complètement accessible. Un de mes amis y est plutôt bon, et c'est vraiment impressionnant de le voir jouer (l'affichage graphique étant possible), il me bat sans problème en jouant super nerveusement dans le plus pur style Quake, si vous voyez le style de FPS que c'est.

Et sinon Vayel :

Ou alors utiliser un casque et jouer sur l'intensité du son sur chaque oreille : si elle est identique, c'est que la source est devant ou derrière ; si l'oreille gauche n'entend presque rien - en caricaturant -, c'est qu'elle est à droite…

Ça ça s'appelle la spatialisation sonore, disponible dans tous les cinémas.

@Alkareth : indeed je suis aussi à Rennes (à l'esir, donc l'univ de rennes 1) et ma rentrée est demain.
Par contre, j'ai des doutes pour la synthèse vocale que tu as choisi (enfin j'ai vu que ça supportait espeak, je suis curieux de voir les résultats en français, c'est assez médiocre ce que j'ai déjà testé).

Rennes 1 aussi, rentrée mardi…

C'pas une synthèse vocale, c'est un moteur de TTS, nuance vocabulaire mais pas que : il supporte les moteurs de synthèse installés sur le système (pas Jaws et NVDA, mais c'est un peu à part…). Non seulement eSpeak, qui est effectivement critiquable (d'après la plupart des DV, c'est une synthèse dégueulasse, très robotique, mais avec une prononciation impeccable), mais aussi SAPI5, le moteur par défaut de Windows (qui prend en charge toutes les voix installées sur l'ordi). Or SAPI5 a l'avantage indéniable d'être très rapide, de répondre au quart de tour ; comme je vais m'orienter, au moins dans un premier temps, vers un développement pour Windows (choix réfléchi et que je pourrai détailler ici si tu veux), le choix de SteelTTS est assez pertinent au final.

Edit : petit HS, tu rentres demain, j'en déduis que tu seras en première année ?

Non mais pour SAPI5 je comprends le choix (même étant plutôt très libre, j'avoue ne pas avoir trouvé de synthèse vocale (et c'est d'ailleurs une des rares choses que j'utilise en non libre…).
Sinon, oui je rentre en première année d'école d'ingé demain. (On se croisera peut etre à un JZDS ou à l'université. Dans tous les cas si on continue la discussion, mieux vaut passer en MP pour éviter de trop polluer le sujet).

C'est pas faux.

Effectivement, si tu t'es frotté un peu à ce domaine, je me doute que tu comprends mon choix : il est issu d'un certain nombre d'heures de recherche, de batailles avec des libs incompatibles, obsolètes, des DLLs inexploitables, etc. Je me doutais que cette partie-là du projet ne serait pas de tout repos, m'enfin.

Du coup, je prends le parti de me limiter à un moteur de TTS simple et efficace, avec grosso modo seulement une méthode say ; à ma charge de l'enrober suffisamment pour qu'il propose la plupart des fonctionnalités indispensable à un audiogame (à savoir, relecture de l'historique des messages lus, possibilité d'éluder un message, j'en passe et des meilleures). En fait, je pense que la conception du module audio représentera le plus gros défi pour moi, pour aboutir à quelque chose d'équilibré.