Introducció
La usabilitat és igual d’important que la funcionalitat perquè un joc sigui gaudible. La funcionalitat d’un videojoc pot visualitzar-se llistant totes les accions requerides i assegurant-nos que l’usuari pot dur-les a terme, però la usabilitat és més difícil de quantificar.
Si una interfície permet fer totes les accions necessàries, la seva funcionalitat és correcta; però si no ho permet, aquesta no ho és. No obstant això, les qüestions d’usabilitat no són tan clares. Maximitzar la usabilitat d’un joc requereix sentit comú i iteracions de «prova i error».
Tot seguit trobareu una llista de 6 guies sobre què cal tenir en compte a l’hora de dissenyar el control d’una aplicació interactiva per tal de maximitzar-ne la usabilitat.
Proveir feedback per als controls
Els controls sempre han de proveir feedback quan són utilitzats. Els usuaris utilitzen els controls per a comunicar-se amb l’aplicació –per a fer quelcom en el món del videojoc. Si res obvi esdevé quan un control és utilitzat, els jugadors es preguntaran si el joc ha capturat la seva acció, i inclús podrien frustrar-se per la falta de resultats. Per tant, els controls sempre requereixen feedback o el videojoc pot patir d’una usabilitat pobra.
Minimitzar la confusió
Molt sovint els jugadors nous no saben com jugar amb un joc de forma immediata, i inclús els jugadors experimentats potser no recorden com jugar de primer moment. Sense una guia suficient, els jugadors poden confondre’s: poden saber què volen fer, però poden no saber com comunicar-ho al joc.
Com a dissenyador d’interfícies, sempre vols que el jugador aprengui la interfície ràpidament i que els usuaris arribin al punt d’utilitzar els controls de forma «intuïtiva».
Les guies per a reduir la confusió són:
1) Reduir el nombre de controls requerits. Com més tipus de controls, més complexitat i més oportunitats de confondre el jugador. El punt en què els controls esdevenen «massa» depèn de la jugabilitat (si és un joc d’estratègia, acció en primera persona, etc.), l’esquema de control, la plataforma física de videojocs (consola amb comandament, ordinador amb teclat o ratolí, portàtil amb capacitats multitàctils, etc.) i dels jugadors mateixos. Si com a dissenyador trobes un repte ajustar tota la funcionalitat en un esquema de control que s’entengui, una possible solució seria canviar la jugabilitat per a reduir la complexitat de la interfície. Dit això, tot i que el teu esquema de control sembli funcionar, sempre hauries de considerar millorar l’experiència de l’usuari simplificant els controls.
Una forma de simplificar el teu esquema de control és utilitzant controls basats en el context. Per exemple, a The Elder Scrolls V: Skyrim, un únic botó físic s’associa a l’acció «Utilitzar».
Depenent de què es troba davant del personatge aquest botó serveix tant per a començar una conversa, obrir una porta, com per a agafar un objecte. Aquesta decisió de control, però, imposa alguns límits de disseny; per exemple, si un objecte es troba massa a prop d’una porta, l’usuari podria obrir la porta accidentalment quan el que volien realment era agafar l’objecte. No obstant això, aquesta decisió de disseny (unificar en un únic control sensitiu al context diferents accions) té un impacte negatiu menor que implementar un altre botó físic que fos «Obrir», per exemple.
2) Destacar els controls no disponibles. S’ha de deixar sempre clar al jugador quan un control no es troba disponible. Per exemple, en un joc d’acció que permeti al jugador canviar d’armes de forma ràpida, seria frustrant veure una opció de control mostrant aquesta opció quan no es disposa d’una arma secundària. El joc no hauria mai de suggerir als usuaris que poden fer alguna cosa que realment no poden fer.
Hi ha generalment dues aproximacions per a gestionar controls que no estan disponibles. Una és simplement no ensenyar el control. Aquesta opció estalvia espai en pantalla i pot fer que el joc sembli menys complex; és per tant una opció vàlida per als primers compassos d’un joc per tal de no mostrar als jugadors accions que no poden fer i que no entenen. Quan el control estigui disponible més endavant, la seva aparició es pot destacar a través d’un text de tutorial o un efecte visual –cridant l’atenció del jugador cap a la nova habilitat o opció que representa.
Una segona aproximació és que el control es mantingui en pantalla però «en color gris» (qualsevol altra forma comuna de mostrar que una opció no es troba disponible). En aquest cas, si el ratolí passa per sobre l’opció o el botó del control intenta ser activat, cal proveir de feedback que indiqui a l’usuari per què el control no es troba disponible. Aquesta aproximació funciona especialment bé quan el control ha estat prèviament disponible per al jugador, on en aquest cas, treure el control de pantalla podria confondre més el jugador. Una altra raó per a mostrar els controls desactivats és per a donar suport al sistema de recompenses del joc: els jugadors veuen una opció que volen i, per tant, tenen un motivador extrínsec. Si totes les opcions del joc estan ocultes, podria mancar per als jugadors l’incentiu per a seguir jugant o assolir determinats objectius.
3) Utilitzar convencions consistents. La consistència és un aspecte crític per a la usabilitat d’una interfície. Els controls d’una interfície que són similars haurien de funcionar de forma similar. Les interfícies mai haurien de fer res que sorprengués a l’usuari. En termes de controls visuals, els elements d’una interfície que facin funcions similars haurien de ser similars visualment. Per exemple, els botons d’una interfície haurien de semblar botons –al mateix temps que qualsevol cosa que no sigui un botó no hauria de semblar un botó.
Minimitzar la inconveniència
Qualsevol acció que els jugadors hagin de fer que no porti directament a l’acció desitjada és una inconveniència –referit com una taxa en el llibre About Face 2.0: The Essentials of Interaction Design per Cooper et. al. (Cooper, Reimann & Dubberly, 2003).
La conveniència ha d’estar aparellada a la importància
Un punt crític en dissenyar esquemes de control és fer que les accions més importants siguin les més accessibles. Qualsevol acció que un jugador hagi de fer de forma freqüent ha d’estar assignada a un dels controls primaris. Per exemple, si atacar en un joc d’acció requerís de quatre botons diferents i navegar per diferents menús, el joc segurament resultaria frustrant de jugar i el ritme del joc seria de tot menys emocionant.
Un exemple que demostra una correcta priorització dels controls combinada amb una maximització de la immersió pot trobar-se en el joc en primera persona Dead Space Extraction (Wii). En el Dead Space en tercera persona, la salut es mostra a través d’una barra de salut diegètica en l’esquena del personatge, però en el Dead Space Extraction no es pot fer el mateix, donat el punt de vista en primera persona. La salut del personatge és una informació vital que requereix que sigui fàcil d’accedir-hi i sol ser mostrada a través del HUD en els jocs en primera persona. Per a evitar un element no diegètic constant, aquest HUD està ocult fins que el jugador no premi un botó secundari del Wiimote.
Permet una introducció fàcil
Una cosa que cal considerar especialment amb implicacions fora de la jugabilitat són els passos que el jugador ha de dur a terme la primera vegada que juga. Fer-ho fàcil al jugador per a fer fàcil la introducció al joc és especialment important en demostracions o períodes de prova; si els jugadors encara no s’han compromès financerament, és més probable que renunciïn davant de qualsevol inconvenient. Un exemple senzill és el següent: si cal prémer repetidament el botó d’acció principal conjuntament amb una navegació a través de diferents menús per a entrar al joc, estem parlant d’una alta complexitat perquè el jugador pugui jugar al videojoc. Una opció «Jugar» a l’inici del joc seria més convenient, de manera que amb un sol clic es comença el joc.
Eliminar passos innecessaris
Un altre mètode per a reduir les taxes al control és minimitzar tota la informació que es requereix al jugador per a dur a terme una certa acció. Un exemple seria reduir el nombre de passos requerits perquè un jugador ataqui un enemic. El joc Star Wars: Knights of the Old Republic 2: The Sith Lords és un exemple extrem d’aquesta idea; el personatge pot automàticament seleccionar, moure’s i atacar un enemic quan se’l troba. Com que aquest comportament potser no és sempre desitjable, es faciliten al jugador opcions d’intel·ligència artificial perquè tingui més control de com volen que es faci la gestió dels personatges. Aquesta implementació és especialment útil en aquest joc perquè el jugador té dues IA amigues –i controlar-les totes al mateix temps seria complex i tediós per al jugador.
Una altra opció és eliminar completament la selecció automàtica dels enemics com en els jocs de trets en primera persona (FPS) o altres gèneres d’acció. Amb aquesta aproximació, prémer el botó d’atac fa que el jugador dispari (o ataqui amb una arma qualsevol). La detecció de col·lisions i les físiques determinaran què s’impacta amb l’atac; no hi ha «objectiu» en si. Aquesta aproximació té altres implicacions d’interfície: el moviment i la càmera han d’estar especialment refinats perquè són crítics al transcurs de l’acció.
Eliminar complexitat innecessària
Reduir la complexitat de la jugabilitat –més enllà de només treure els controls– pot incrementar la usabilitat. Un altre exemple de taxes al control és el sistema d’inventari en alguns jocs de rol (role playing games (RPG) en anglès). Per tal d’equipar un nou objecte, els jugadors normalment han d’entrar en un menú de gestió, seleccionar «gestió d’equipament», i haver de navegar a través de diverses capes de menús per a trobar l’objecte a equipar. Si els jugadors estan intentant maximitzar una habilitat en concret, per exemple, la resistència al foc, potser els cal comparar tots els objectes fins que trobin el que té major resistència al foc. Fins i tot podria ser que els elements d’armadura estiguessin dividits entre diferents parts (casc, espatlleres, etc.) i tipus (lleugera, pesant, etc.), per a afegir encara més complexitat a tot el procés. Aquest tipus de sistemes, tot i ser realistes i proveir de profunditat, solen ser taxatius cognitivament i difícils de gestionar per al jugador.
Com podríem reduir la taxació al control? Una possibilitat és reduir la complexitat de la jugabilitat a través de reduir el nombre d’objectes del joc. Tenir menys objectes redueix la varietat per al jugador, la taxa associada a la gestió d’objectes fa que calgui qüestionar-se en primer lloc la necessitat de tenir tants objectes. Una altra opció seria deixar la complexitat de la jugabilitat tal com està (és a dir, no reduir el nombre d’objectes), però reduir la complexitat de la interfície proveint el jugador de dreceres que l’ajudin a maximitzar les qualitats de l’armadura per a determinats objectius. Seguint amb l’exemple anterior, els jugadors podrien decidir que volen maximitzar la seva resistència al foc i la interfície s’encarregaria de seleccionar tots els elements que ajudessin a fer-ho. Per als jugadors que els agrada la complexitat i el detall, l’opció de continuar seleccionant els elements de la interfície de forma manual podria deixar-se en paral·lel a aquesta funció específica.
No facilitar gaire la vida del jugador
Moltes d’aquestes guies comporten la millora de la usabilitat a través de fer les coses més fàcils per als jugadors. No obstant això, aquesta filosofia pot arribar a portar-se massa lluny en el disseny d’una interfície per a videojocs, i això tampoc és bo. En els videojocs, la usabilitat consisteix a proveir la millor experiència de joc –no sols maximitzar la facilitat d’ús. Tot i que molts jugadors es preocupen pels resultats finals, com per exemple guanyar el joc, la satisfacció ve de l’experiència i l’acompliment del resultat. En el llibre A Theory of Fun, Raph Koster proposa que la part divertida d’un joc és l’aprenentatge que han de fer els jugadors davant dels reptes sempre creixents d’un joc (Koster, 2005).
Portat a l’extrem, fer un joc fàcil d’utilitzar podria significar un joc que es juga a si mateix –amb els jugadors mirant, si més no, d’involucrar-se amb una experiència interactiva (com a anècdota, fa molts anys va aparèixer el joc Progress Quest, un RPG en línia on el jugador no havia de jugar, només deixar l’aplicació oberta per a anar aconseguint objectes, experiència i pujar per les taules de puntuació). Per exemple, tingueu en compte la gestió d’inventari comentada anteriorment. Quan un oponent mor, els jugadors poden saquejar-li el cos –i guanyar or i altres objectes. Si els jugadors volen maximitzar els beneficis en jocs com Temple of Elemental Evil o Icewind Dale, els jugadors han de recol·lectar i vendre tot l’equipament mundà que els enemics utilitzen. Com que els personatges poden carregar un màxim de pes o objectes, són necessaris diversos viatges entre el poble i la Dungeon. Aquests tipus de jocs són consistents amb els jocs de rol de taula, com el Dungeons & Dragons, del qual molts d’aquests jocs s‘han originat.
El joc The Bard’s Tale (la versió del 2004, no l’original de 1985) va intentar eliminar aquest aspecte tediós de la jugabilitat a través de donar directament l’or als jugadors quan mataven un enemic. Si els jugadors trobaven una arma millor que la que equipaven, podien assignar-la directament i fer que l’antiga arma es convertís directament en or. Aquesta implementació té fins a cert punt sentit –però què passaria si els jugadors no equipessin directament la millor arma quan la troben? Força crítics van comentar en la seva època que el joc perdia part de l’encant dels tocs tradicionals dels RPG a través d’aquesta simplificació. Per a molta gent, part de la gràcia dels RPG és vendre objectes als comerciants i anar comprovant els nous objectes per a veure si són realment una millora. Automatitzant completament aquest procés s’elimina completament aquest aspecte de la jugabilitat. La lliçó a aprendre és que abans de simplificar la interfície d’un videojoc, assegura’t que sols estàs eliminant tedi, no jugabilitat.
Preveure errors accidentals
Les accions que puguin resultar frustrants per als jugadors haurien de ser difícils d’aconseguir per accident. Aquesta directriu s’aplica especialment als errors que es poden produir durant un segment intens del videojoc. Per exemple, amb un comandament d’Xbox, si s’utilitzen els botons «B» i «X» per a diverses combinacions d’atacs, però el botó «A» obre una pantalla d’inventari, la possibilitat de frustració és alta perquè el jugador pot prémer accidentalment «A» mentre canvia entre els botons «B» i «X». Tingueu especial cura a assignar determinats tipus d’accions a les palanques de control analògiques d’un controlador de consola. Mitjançant l’ús normal de la palanca de control analògica, el jugador pot fàcilment prémer el botó del control analògic, activant qualsevol acció que hi estigui assignada. Al Dark Cloud 2, per exemple, s’utilitzen els botons analògics per canviar de personatge; desfer aquest canvi de personatge és tediós i interromp el flux de combat.
Un concepte relacionat amb la minimització de les possibilitats d’errors accidentals és l’estratègia Do What I Mean (DWIM), que implica interpretar la intenció de l’usuari en comptes d’admetre a cegues les entrades de control. Si el jugador comet un error, però el joc pot identificar el que el jugador realment volia fer, el joc segueix la intenció del jugador en lloc de l’ordre literal. Per exemple, si un jugador surt del joc, però no ha desat la partida recentment, el joc hauria de qüestionar aquesta decisió, requerint la confirmació i demanant al jugador que guardi el joc abans de sortir. (Una millor implementació podria ser guardar automàticament el joc en un espai de desament automàtic, en lloc de molestar el jugador amb la sol·licitud de confirmació). Tanmateix, si el jugador acaba de guardar el joc, el joc hauria de sortir per a minimitzar les molèsties.
Donar suport a la jugabilitat
La vostra interfície sempre hauria de donar suport al joc. Aquesta directriu engloba bàsicament totes les altres, però val la pena esmentar-la per separat per a destacar la importància de com el joc i la interfície funcionen amb o en contra d’ells mateixos si no hi tenim cura. Per exemple, a Star Wars: Knights of the Old Republic, el jugador té dos tipus d’armes: «cos a cos» i «a distància». Canviar entre un blaster i el sabre de llum requereix que el jugador obri el mode de gestió, accedeixi als equips, seleccioni la ranura de l’arma i, finalment, triï una arma nova. Aquest procés de múltiples passos interromp el flux de combat i resulta tediós per al jugador.
Una de les millores fetes a la seqüela Star Wars: Knights of the Old Republic 2: The Sith Lords va implicar crear un control per a l’acció de commutació d’arma. El jugador podia tenir una segona arma equipada a la ranura i podia canviar entre les dues armes amb una sola tecla sense sortir del mode de combat. En reduir les taxes de control, es va poder animar els jugadors a utilitzar els dos estils de combat a través de la interfície del joc. No obstant això, aquesta millora no va tenir un èxit complet per dos motius: primer, mentre que es va fer un esforç per a equilibrar millor la utilitat de les armes de rang i de cos a cos, les tàctiques generals de combat no van canviar –i això va fer que el canvi d’arma tampoc tingués gaire importància. En segon lloc, com en el joc original, els arbres d’habilitats per a armes «a distància» i «cos a cos» estaven separats; per tant, la majoria dels jugadors s’especialitzarien en un tipus de combat. Poder canviar ràpidament entre armes de diferents estils no resultava finalment avantatjós.
Mentre que l’addició del botó de canvi ràpid d’arma va fer millorar la interfície, comparant-ho amb el primer joc, les imperfeccions fonamentals del disseny de jugabilitat limitaven tota l’ajuda que aportava aquest canvi de control. La interfície i el joc no estaven completament sincronitzats.
Maximitzar la usabilitat d’un esquema de control pot ser un repte, atès que un canvi aparentment petit pot reverberar a través de molts aspectes del vostre disseny –resolent un problema crític, però introduir-ne de nous. A mesura que itereu sobre el vostre esquema de control, cal pensar en els efectes que un canvi pot tenir en qualsevol altre sistema.
Referències
Cooper, A., Reimann, R., & Dubberly, H. (2003). About face 2.0: The essentials of interaction design. John Wiley & Sons, Inc.
Raph, K. (2005). A theory of fun for game design. Nova York: Paraglyph Press.