Texte du tutoriel sans utilisateur ennuyeux?

J'ai un texte de tutoriel (que je prévois d'augmenter avec une voix plus tard, mais il doit être du texte pour l'instant, car je n'ai pas encore contracté d'acteur de VO).

Le texte se présente dans des dialogues, qui sont comme des tweets (moins de 140 caractères chacun). Le texte est gros et lisible.

Le texte contient des instructions vitales qui expliquent à l'utilisateur ce qu'il doit faire ensuite . Lors d'un test de lecture, un utilisateur doit simplement appuyer sur OK OK OK sans lire le texte. La boîte de dialogue finale disparaîtrait et l'utilisateur n'aurait aucune idée de ce qu'il devait faire, car il n'avait pas lu les instructions. Le jeu s'attend à ce qu'il exécute la tâche qu'il vient de demander, et il ne sait pas ce que c'est.

J'ai essayé:

• mettre un compteur (3), (2), (1), puis lorsque le compteur disparaît, vous pouvez appuyer sur ok. Je pense que le compteur est ennuyeux / distrayant
• griser / désactiver le bouton jusqu'à ce que 2-3 secondes se soient écoulées pour chaque boîte de dialogue de texte
• masquer complètement le bouton ok jusqu'à ce que 2-3 secondes se soient écoulées pour chaque boîte de dialogue de texte

Comment puis-je mieux gérer ce problème de l'utilisateur ne lisant pas le texte du didacticiel avant de fermer la boîte de dialogue?

Ne pas avoir énormément de murs de texte de tutoriel. Si vous avez besoin de plus d'une seule petite flèche à l'écran, vous devriez vraiment vous demander pourquoi .

"Pourquoi l'utilisateur clique-t-il boîte de dialogue après boîte de dialogue?" Mauvaise question. "Pourquoi affichons-nous plusieurs dialogues?" Bonne question.

Vous dites que les boîtes de dialogue indiquent à l'utilisateur comment effectuer la tâche. La tâche est trop grande. La tâche devrait être « déplacer ici », « cliquez sur ce », « tactile », etc. Non « déplacer ici, toucher votre nez, frotter votre ventre, regard plein nord, sauter sur un pied, appuyez sur Haut, Haut, Bas, Bas, gauche, droite, gauche, droite, B, A "

Les instructions données doivent être décomposées en petites parties discrètes. Bien fait, vous pouvez garder les instructions à l'écran à tout moment ou mettre en évidence le bit nécessaire. Par exemple, dans un jeu avec un contrôleur, vous pouvez afficher une image du bouton souhaité à appuyer sur l'écran jusqu'à ce qu'il soit appuyé. Si vous souhaitez que le joueur interagisse avec un élément, faites-le briller, rebondir ou se démarquer jusqu'à ce qu'il interagisse avec. Si vous voulez dire au joueur comment interagir, ouvrez le bouton / la touche droite lorsqu'ils sont assez proches (de nombreux jeux le font tout le temps, même en dehors des didacticiels, en particulier ceux avec des commandes contextuelles).

Un autre thème que vous auriez pu remarquer pour éviter le texte. Les joueurs sont des créatures paresseuses et ils ne veulent pas lire les instructions. Montrez, ne dites pas.

Si vos testeurs sautent simplement votre texte, vous devriez faire de même - prenez cela comme un indice pour l' éliminer .

Au lieu de cela, créez votre jeu de telle sorte qu'il offre aux utilisateurs une expérience d'apprentissage progressive qui leur enseigne ce qu'ils doivent savoir.

L'un de mes jeux préférés pour cela est la série Half-Life. Vous commencez par apprendre à marcher. Ensuite, vous devez apprendre à sauter. Et puis vous obtenez un pied de biche. Ils ne le jettent pas entre vos mains et vous font immédiatement vous battre avec, mais au lieu de cela, vous commencez simplement à casser des trucs juste pour le plaisir - ou peut-être pour éliminer une simple barrière à votre progression. Plus tard, vous devrez l'utiliser pour survivre et vous battre. Mais d'abord, vous pouvez jouer avec.

Structurez donc votre jeu pour créer l'enseignement, et ne structurez pas votre enseignement pour créer le jeu. Si ça a du sens.

Pensez également à utiliser des PNJ pour transmettre des messages. Si vous avez besoin que le joueur aille chercher un objet, demandez à un PNJ de lui dire: "Vous devez aller chercher cet objet". S'ils ne le font pas, ce n'est pas grave. Mais après un certain temps, ce PNJ devrait dire: "Hé, vous devez ramasser cet objet - ne m'avez-vous pas entendu la première fois?" Pensez, "Ils vous attendent Gordon ... Dans la salle de test ... ..." si vous connaissez votre HL;)

Les joueurs aiment jouer - et explorer. Laissez-les faire ça. Ne les forcez pas sur un chemin rigide sans aucune chance d'expérimenter. Laissez-les apprendre ce qui fonctionne en faisant, pas en vous contentant de leur dire.

Et si ce que vous leur demandez de faire est si compliqué que vous devez leur donner un manuel, reconsidérez sérieusement l'approche que vous adoptez avec le jeu.

Si le texte du tutoriel est vital, pourquoi autoriseriez-vous le joueur à les renvoyer pour toujours et à se perdre? Voici quelques idées:

Une approche courante que j'ai vue consiste à ignorer le texte du didacticiel uniquement lorsque le joueur a terminé l'action requise .

Par exemple, si le texte actuel est:

Bienvenue dans le jeu de bobobobo! Appuyez sur A pour sauter.

N'écartez ce texte que si le joueur a appuyé sur A et sauté.

Une autre approche consiste à laisser le joueur revoir le texte à volonté . Par exemple, dans Binding of Isaac, la salle de départ vous indique les commandes. Vous pouvez librement revenir dans cette salle au cas où vous auriez besoin d'un rappel:

Il y a une autre astuce ici et c'est pour rendre le texte du tutoriel aussi discret que possible . Une bulle de texte qui flotte sur tout distrait. Si c'est en arrière-plan, ou est quelque chose qui pourrait être soulevé à volonté (par exemple des signes qui peuvent être lus, ou des PNJ qui peuvent être parlés):

Une autre approche (et c'est la plus difficile mais a probablement le meilleur effet) consiste à rendre les indices très très subtils . Dans le commentaire du développeur pour Escape from Butcher Bay, le développeur principal a mentionné de petits changements de niveau qui ont empêché leurs testeurs de se perdre: agrandir certaines portes, ajouter des lumières, etc. Cela a eu un effet psychologique sur les joueurs qui leur a donné l'impression que c'était le cas. la bonne façon de procéder, sans en être explicitement informé.

Dans la même veine (mais d'une manière moins subtile), l'étape d'ouverture de Half-Life contenait des couloirs à code couleur. Le joueur peut choisir de les suivre, ou peut-être lui rappeler inconsciemment:

Encore une chose; J'ai lu ceci quelque part (mais je ne me souviens pas maintenant) que le premier niveau de Super Mario Bros a un excellent exemple de préparation préalable du joueur aux obstacles. Considérez cette section:

Voyez comment c'est presque le même puzzle de saut répété deux fois. D'abord, il n'y a presque aucune conséquence pour ne pas sauter par-dessus l'écart, mais le joueur qui échoue (ou pas) saura à quoi s'attendre et quoi faire (ou ne pas faire) lorsqu'il parviendra à la vraie affaire: le deuxième obstacle où l'échec entraîne la mort. Parfois, il est préférable d'enseigner au joueur en le laissant s'entraîner de cette manière dans des réglages à faibles enjeux.

Il m'est venu à l'esprit que le texte de saisie n'est pas seulement un gadget utilisé dans Final Fantasy, Legend of Zelda, etc.

Si le texte continue sur quelques secondes, ALORS l'utilisateur a la possibilité d'appuyer sur OK, l'utilisateur est plus susceptible de le lire!

C'est une très bonne question pour le site UX (User Experience) StackExchange, soit dit en passant!

Fournir un moyen à l'utilisateur de masquer les boîtes de dialogue, mais avec un moyen de les ressusciter lorsque l'utilisateur découvre qu'il est bloqué.

 Do not bother me with this stuff, I know what I'm doing [ ] <- checkbox (or whatever)

Lorsque l'utilisateur sélectionne cette case à cocher et ferme la boîte de dialogue, vous pouvez en quelque sorte en informer l'utilisateur.

Par exemple, disons que votre jeu a une barre d'état en bas. Un "ballon" pourrait apparaître là-bas en disant: "D'accord, je serai hors de votre chemin, mais cliquez ici si vous êtes coincé!" puis s'estompe d'elle-même.

Ou la boîte de dialogue fermée pourrait s'animer vers cet endroit, puis un ballon apparaît brièvement, "D'accord, mais je ne suis pas parti; je suis ici si vous avez besoin de moi".

Rien de ce genre.

Je dirais, donnez à l'utilisateur la possibilité d'accéder à un écran de didacticiels qui contient les entrées présentées jusqu'à présent, ou si l'utilisateur est dans la même zone pendant longtemps, affichez à nouveau le didacticiel ...

En supposant que toutes les autres réponses ne s'appliquent pas (et vous avez vraiment VRAIMENT besoin d'instructions textuelles), présentez ce texte précisément au moment où l'utilisateur en a besoin. Cela le rend pertinent, alors que le présenter à l'avance le rend ennuyeux.

Attendez que le joueur soit exactement au bon endroit; ils sont au point où ils doivent prendre les mesures nécessaires pour continuer. Attendez qu'ils se heurtent littéralement à la porte verrouillée avant de leur dire comment l'ouvrir. Si possible, détectez qu'ils tâtonnent bêtement, afin de leur donner une chance de deviner la bonne procédure sans message. Si le joueur semble attendre quelque chose, l'instruction peut être la bienvenue.

Et TOUJOURS rendre le texte sautable. Permettez au joueur de le sauter presque par accident, comme avec n'importe quel clic ou le bouton le plus proche de son pouce. Si le jalon du didacticiel, le déclencheur, l'événement, etc. (la preuve que le joueur a reçu le message) ne se produit pas, vous pouvez rejouer le message. N'interrompez pas.

Vous pourrez peut-être en faire une option qu'ils pourront activer s'ils en ont besoin, ou ignorer s'ils ne le font pas.

Il serait peut-être préférable, au lieu d'une boîte de dialogue contenant des instructions, de donner la possibilité d'ouvrir cette boîte de dialogue. Je ne suggérerais pas d'y ajouter des effets sonores, ceux-là deviennent ennuyeux. Et il pourrait être délicat d'équilibrer visuellement. Mais, personnellement, je n'aime vraiment pas ces dialogues "d'aide", en particulier lors de la relecture du jeu, ils deviennent facilement ennuyeux.