Bonjour à tous! Je suis un designer UI / UX spécialisé dans les interfaces de jeu. Je suis aussi un humaniste: tout ce qui concerne le code suscite une peur et une méfiance innées, que je ne peux pas surmonter. Avoir peur d'un progéniteur «magie noire» est normal pour un designer. Mais il y a un problème qui complique grandement la vie.
Le fait est que dans notre travail, nous, concepteurs d'interfaces, devons souvent nous rapprocher des sites et des applications internes et même y entrer un peu. Ce besoin est particulièrement pertinent au stade du prototypage précoce et rapide, lorsque vous souhaitez collecter quelque chose sur votre genou qui peut donner une idée du produit final, aura le minimum de fonctionnalités nécessaires et aura également l'air décent. Cependant, la plupart des concepteurs (y compris moi-même) n'ont même pas les connaissances minimales pour créer et éditer leur propre partie d'interface du prototype, via le code. Et cela est également normal pour l'industrie.
Connaissant notre caractéristique humanitaire, les programmeurs compatissants (ainsi que d'autres bonnes personnes) ont créé un nombre suffisant d'outils pour créer un design et le tester sur de vrais appareils sans écrire une seule ligne de code. Ces outils sont facilement googlé sur demande du type «programme de prototypage d'interface». Ce sont Sketch, Adobe XD, Figma, Principle, InVision, Marvel, etc. Ils sont géniaux. Ils sauvent des millions de cellules de concepteur nerveux (et peut-être quelques vies). Des centaines d'articles ont été écrits à leur sujet; ils sont à juste titre loués par les designers UI / UX du monde entier.
Cependant, ces outils sont principalement adaptés aux développeurs d'applications Web et mobiles. Pour le développement de jeu (et nous ne parlons ici que de développement de jeu), ils sont mal adaptés.
«Attendez une minute, quelle est la différence?» Demandez-vous. Les jeux sont aussi des applications, non? Pas vraiment. Les spécificités du jeu apportent une correction significative au processus de production.
Faisons les choses correctement.
Premièrement, les applications «ordinaires» non liées au jeu reposent le plus souvent sur le principe de solutions simples aux problèmes des utilisateurs. Par exemple, je veux résoudre un problème spécifique - transférer de l'argent sur la carte de Serege - et pour cela j'ouvre une application bancaire. La rapidité avec laquelle je peux résoudre ma question détermine le degré de satisfaction de cette interaction. Après le transfert, je ferme l'application et l'oublie un moment. Je suis satisfait, la banque est satisfaite, Seryoga est satisfaite. Il s'agit d'un chemin linéaire compréhensible du point A au point B.
La banque, comme moi, souhaite clôturer les tâches des utilisateurs le plus rapidement possible. Il ne les crée pas spécifiquement. Schématiquement, cela ressemble à ceci:
Dans le secteur du divertissement (où les principaux revenus proviennent de la publicité), plus un utilisateur passe de temps dans un service, plus il peut en générer de profit. Par conséquent, YouTube lui-même, sans demander, lance la prochaine vidéo et vole les algorithmes qui sélectionnent cette vidéo pour vos intérêts. Dans les jeux mobiles, c'est pareil. Le désir de s'amuser et de prendre une dose de dopamine dans un sens est une tâche définie par l'utilisateur. Mais elle n'a pas de solution définitive et définitive, ce que les producteurs de contenu utilisent. Nous voulons que vous ne vous détachiez pas de nos jeux. Généralement.
Par conséquent, les jeux utilisent des cycles qui lancent aux joueurs de nouvelles tâches et les transfèrent habilement d'une activité à une autre. Cela ressemble à ceci:
Une telle structure est déjà beaucoup plus difficile à prototyper. Appelez ce jeu de fonction
embuscade n ° 1 . Il y en a d'autres.
Embuscade n ° 2 Le jeu est avant tout un gameplay. L'interface est juste une liaison, un cadre pour un diamant (bien que dans certains jeux l'interface = gameplay, mais ne parlons pas de tristes choses). Sans ce joyau au milieu, il est souvent difficile d'évaluer la qualité de votre interface (et maintenant je ne parle pas du look). Le problème est que le gameplay ne peut pas être intégré dans des outils de prototypage; ils existent dans différents programmes, dans des mondes différents. Et s'il n'y a pas de gameplay, alors il n'y a pas de jeu lui-même. Aucun contexte n'est nécessaire.
Embuscade n ° 3 Dans les jeux, il y a des éléments et / ou animations très non standard. La palette d'éléments est beaucoup plus large que celle que l'on trouve sur les sites Web ou dans les applications bureautiques. Tous les programmes de prototypage ne peuvent pas tous les recréer.
Ambush No. 4 Les jeux sont faits sur des moteurs de jeu. Les outils de prototypage sont synchronisés avec eux sur ... rien. Ils ne sont tout simplement pas conçus pour cela. Tout ce qui a été fait au * nom du programme de prototypage *, vous (ou votre pauvre collègue) le recréerez ensuite dans le moteur. De zéro. Et ce n'est pas un fait qu'en même temps, il sera possible de tout répéter au moins de la même manière que dans le prototype: les capacités des programmes sont différentes. C'est pourquoi de grands joueurs comme Game Insight (
vidéo ) ou Pixonic (
article ) se penchent sur les outils internes qui synchronisent en quelque sorte Photoshop, coupent les sprites, les assemblent dans le moteur, la gestion du style, etc.
Oui, au fait. Note marginale. Je n'ai travaillé qu'avec des jeux réalisés sur Flash ou Unity. Flash est déjà mort, il s'agira donc principalement d'Unity. Je suppose que tout le plus ou le moins dit est vrai par rapport à d'autres moteurs de jeux populaires, mais ce n'est pas exact.À quoi conduit une telle duplication des travaux? De toute évidence, le fait que l'effort pour développer et prendre en charge
des prototypes d'interfaces plus ou moins
complexes monte en flèche. Qu'il s'agisse de montres humaines de créateurs relativement bon marché (désolé les gars), mais néanmoins.
Je ne veux pas dire que le prototypage d'interfaces de jeu avec des outils standard est stupide. Bien sûr que non: tout travail préparatoire à la réalisation de l'interface vaut mieux que son absence. C’est juste que la façon dont nous sommes familiers, concepteurs, a des limites et des problèmes qui peuvent être évités. Plus d'informations à ce sujet plus tard.
Il y a un tel gars,
Om Tandon . Il a publié de nombreux articles sur le jeu UI / UX, et en général, cela semble être une sorte de tâtonnement dans la question. Du moins, écrit-il avec beaucoup de confiance (au fait, c'est de lui que j'ai tiré des photos et quelques idées pour cet article). Je conseille aux personnes intéressées de lire le cycle correspondant de ses articles sur LinkedIn (n'oubliez pas le VPN): les
première ,
deuxième et
troisième parties. Vous pouvez également regarder sa
vidéo lors d'une conférence à Londres. Il est préférable de s'arrêter et de le faire dès maintenant avant de continuer à lire cet article, car Je vais m'appuyer par endroits sur son matériel.
Malgré le fait qu’en général, l’idée d’Ohm - rendre les prototypes aussi proches que possible des produits finaux aussi rapidement et à moindre coût que possible, j’aime, en particulier je ne peux pas être d’accord avec lui. Par exemple, il affirme que pour obtenir le même résultat dans le prototype de gameplay (Ohm l'appelle prototype de développement), en comparaison avec le concepteur, cela prend plusieurs fois plus de temps et d'efforts. Des chiffres concrets sont donnés: il faut
5-7 jours pour créer
ce prototype en utilisant Principle (l'un des outils de prototypage les plus populaires), et il faudrait
20 à 30 jours à l'équipe pour implémenter la même fonctionnalité dans le moteur, selon Ohm. Et il ne s'agit pas de «tout faire selon la beauté», mais simplement d'obtenir un résultat identique à la sortie. À mon avis, le chiffre est grandement exagéré.
Deuxièmement, les exemples de prototypes cités par Om sont encore pour la plupart linéaires. Il s'agit soit de tutoriels avec une séquence des seules vraies actions, soit d'une chaîne d'écrans le long desquels vous pouvez vous déplacer dans les directions «là » et «ici», ou une imitation de micro-interaction locale. Oui, ils ont l'air délicieux, mais je n'y ai vu aucun cycle de jeu ou logique complexe.
Troisièmement, dans les prototypes d'Ohm fabriqués dans Principle, pour les raisons déjà décrites, il n'y a pas et ne peut pas être le gameplay lui-même. Il n'y a même pas de 3D en tant que telle! Ils ne concernent que l'interface utilisateur / UX plate, indépendamment du jeu lui-même. À mon avis, cela réduit leur valeur. Bien que Om affirme que ces solutions conviennent pour émuler de manière convaincante environ 80% des genres de jeux.
Quatrièmement, l’une des principales raisons pour lesquelles Om a développé un prototype d’interface est son utilisation ultérieure dans la recherche sur l’utilisabilité. C'est génial et correct, mais à quelle fréquence avez-vous rencontré des études d'utilisabilité compétentes (oh, au moins certaines) dans le développement de jeux nationaux? De tels prototypes sont-ils nécessaires pour les petites équipes et les studios qui ne mènent pas ces mêmes études? Si le prototype de
gameplay est une partie évidente et obligatoire du développement de
n'importe quel jeu (à condition que vous ne fabriquiez pas de papier calque à partir d'un autre projet), alors y a-t-il un intérêt à s'embêter avec des prototypes
"design" - c'est une question ouverte.
D'après mon expérience, la
carte d'écrans non interactive la plus simple sous la forme d'une image lourde résout la grande majorité des problèmes d'interaction et de connexions entre les écrans. Cette image est collectée en une demi-heure et rien que les maquettes dessinées dans Photoshop (illustrateur) ne seront nécessaires pour cela. Il est le plus souvent possible d'arrêter.
Dans quels cas est-il judicieux de passer à un prototype interactif et très détaillé (Ohm appelle cette
haute fidélité )? Nuuu ... Par exemple, si votre client a besoin du matériel le plus visuel, et non du schéma BW, pour accepter le travail. Ça arrive.
Ou si vous avez besoin de faire une belle construction de démonstration que vous pouvez montrer aux investisseurs et conduire par téléphone.
Ou si le gameplay du projet ou de sa partie individuelle est si nouveau qu'il est généralement difficile de savoir comment créer une interaction avec lui, et des cycles constants de test d'hypothèse sont nécessaires.
Ou si vous souhaitez accélérer le processus d'essai et d'erreur dans les interfaces, décharger les programmeurs en cours de route.
Ou si vous avez besoin d'un produit simulé pour les tests d'utilisabilité.
En bref, je ne recommanderais pas de faire un prototype détaillé d'un jeu avec une interface par défaut, mais il y a des cas où c'est vraiment nécessaire. Décidez simplement pourquoi vous dépensez vos ressources à ce sujet et quel type d'épuisement vous prévoyez de recevoir.
Encore une fois, brièvement. Je vois
trois façons principales de prototyper l'interface de jeu:
1) Limité à une carte d'écrans. Ne vous embêtez pas avec les prototypes interactifs si vous ne comprenez pas quoi et comment vous voulez les tester.
2) Faites d'une primitive (faites glisser des images avec des transitions) un prototype interactif dans le programme dans lequel elle se révélera plus rapidement. Il s'agit d'une variante pour ceux qui comprennent quoi et comment ils veulent vérifier, et qui n'ont pas besoin d'être particulièrement détaillés ou de connecter l'interface avec le gameplay (par exemple, vous n'êtes intéressé que par la méta-partie du jeu). Il peut être regardé sur l'appareil.
Mais si, objectivement, vous avez besoin de quelque chose de plus proche du produit réel, alors c'est la troisième option, et nous y attardons plus en détail. Pour ce faire,
prototype de l'interface directement dans Unity , cher ami-designer. C'est plus facile que vous ne le pensez.
Le fait est que l'unité est un écosystème entier, une énorme moissonneuse-batteuse. En partie effrayant, parfois monstrueux et inconfortable, mais certainement avec ses avantages. Par exemple, quelle que soit la fonctionnalité supplémentaire que vous souhaitez attacher au moteur, il est fort probable qu'elle soit déjà disponible en téléchargement dans
Asset Store . Parfois même de bonne qualité. Les outils de conception ne font pas exception.
Par exemple, personnellement, j'aime vraiment
DoozyUI , qui vous permet de créer des écrans séparés sans trop de tracas, d'ajouter des liens et des transitions entre eux et de fixer rapidement les animations d'interface. Puisqu'ils ne paient pas de supplément pour la publicité, je dirai tel quel: c'est loin d'être le seul outil disponible sur le marché. Et même probablement pas le meilleur. Il m'a soudoyé avec un grand nombre de tutoriels, une histoire riche et son propre système pour afficher les connexions entre les écrans. Regardez cette beauté!
Cependant, il existe d'autres excellentes solutions pour créer des systèmes d'écran complexes dans Unity sans connaissance approfondie du code. Tout ce que vous avez à faire est d'investir un peu de votre temps dans leurs recherches et de creuser plus profondément dans l'Asset Store.
En principe, vous pouvez vous passer du tout d'extensions et utiliser ce que Unity propose dès le départ. Juste pour la psyché humanitaire, ce sera beaucoup plus douloureux. Vous devez comprendre que dans n'importe quelle situation au début, le néophyte Unity devra regarder NN heures de formation (ou tirer constamment des programmeurs, comme dans mon cas). Pourtant, le moteur n'est pas conçu pour les concepteurs; c'est un environnement qui était initialement hostile à notre frère. Par conséquent, de nombreux concepteurs UI / UX de jeux ne considèrent même pas les fonctionnalités Unity comme un outil pour leur travail. Mais vous n'en faites pas partie, n'est-ce pas?
Encore une fois, quel est le bénéfice du prototypage des interfaces pour les jeux immédiatement dans Unity:
Ils sont faciles à intégrer dans le prototype "gameplay" et donnent une image beaucoup plus holistique et impressionnante du futur produit.
Des parties de prototypes fabriqués dans Unity peuvent être directement réutilisées dans un projet de «finition». Cela ne fonctionnera pas complètement - les programmeurs proposeront très probablement de coller vos extensions de conception pour Unity quelque part plus profondément, mais dans des parties et des écrans séparés - c'est très possible.
Ces prototypes fonctionneront sur les appareils exactement comme vous le souhaitez. Sera correctement étiré et mis à l'échelle. Envisagera la frange et les zones sûres. Aucune différence avec le résultat final, beauté!
Ces prototypes modifient facilement et rapidement "à la volée". Il n'est pas nécessaire de répéter le même travail d'abord en principe, puis en unité. Vous pouvez même faire quelque chose sans passer par Photoshop.
Posséder Unity permet au concepteur d'accéder à des interfaces tridimensionnelles et de contrôler l'interface depuis l'intérieur du moteur.
En plus des bonus directs, il y en a qui accompagnent: apprendre à connaître le moteur facilite grandement la vie en général et augmente également votre valeur en tant que spécialiste du marché du travail.
En général, je voulais dire tout cela.
Chers collègues, n'ayez pas peur d'expérimenter! Examinez de près les moteurs avec lesquels vous travaillez et leurs capacités. Faites plus, dérangez, soyez intéressé. C'est payant.
Et pour cela, il n'est pas nécessaire d'être un technicien.