Créer un jeu que je peux confier à mon enfant

Je développe un jeu en ligne, et mon fils y joue. Cette phrase a l'air anodine — mais c'est la contrainte de conception la plus stricte de tout le projet. Car je suis assis des deux côtés de la table : en tant que développeur qui veut des fonctionnalités, et en tant que père qui sait ce qui traîne sur Internet.

Quelques décisions qui n'existeraient pas sans ce double rôle :

Des comptes sans adresse e-mail. Un enfant ne devrait pas laisser une traînée de données juste pour empiler des blocs. Nos comptes ne demandent donc pas d'e-mail — ce qu'on ne collecte pas ne peut faire de mal à personne.

Des mondes publics uniquement avec mot de passe. Des inconnus ne peuvent pas débarquer comme ça dans le monde d'un enfant. Celui qui doit jouer avec reçoit le mot de passe en personne — dans la cour de récré, pas par un algorithme.

Le rappel de pause. Le jeu affiche la durée de la session et rappelle gentiment de faire des pauses. Est-ce que j'ai pris plaisir à coder ça en tant que développeur ? Disons que le père a eu le dernier mot sur le développeur. (L'avis de Justus sur la question est consigné, et il est différent.)

Signaler, aussi simple que chatter. S'il se passe quelque chose de bizarre, on tape /report — le reste (historique du chat, contexte du monde) part automatiquement avec. Un enfant ne devrait rien avoir à prouver.

Le plus intéressant : aucune de ces décisions n'a rendu le jeu moins bon. La règle du mot de passe rend les mondes plus personnels. Les comptes allégés nous épargnent bien des casse-têtes de protection des données. Et le rappel de pause… eh bien, il lui arrive aussi de rappeler le développeur à l'ordre.

On construit autrement quand son utilisateur le plus important est assis à la même table de cuisine. Aujourd'hui, j'en suis convaincu : on construit mieux.