Los controles siempre tienen que proveer feedback<\/em> cuando son utilizados. Los usuarios usan los controles para comunicarse con la aplicaci\u00f3n \u2013para hacer algo en el mundo del videojuego. Si no sucede nada obvio cuando se usa un control, los jugadores se preguntar\u00e1n si el juego ha capturado su acci\u00f3n, e incluso podr\u00edan frustrarse por la falta de resultados. Por lo tanto, los controles siempre requieren feedback<\/em> o el videojuego puede sufrir una usabilidad pobre.<\/p>\n Muy a menudo los jugadores nuevos no saben c\u00f3mo jugar con un juego de forma inmediata, e incluso los jugadores experimentados quiz\u00e1s no recuerdan c\u00f3mo jugar en un primer momento. Sin una gu\u00eda suficiente, los jugadores pueden confundirse: quiz\u00e1s saben qu\u00e9 quieren hacer, pero quiz\u00e1s no saben c\u00f3mo comunicarlo al juego.<\/p>\n Como dise\u00f1ador de interfaces, siempre quieres que el jugador se aprenda la interfaz r\u00e1pidamente y que los usuarios puedan utilizar los controles de forma \u00abintuitiva\u00bb.<\/p>\n Las gu\u00edas para reducir la confusi\u00f3n son:<\/p>\n 1) Reducir el n\u00famero de controles requeridos.<\/strong> Cuanto m\u00e1s tipos de controles, m\u00e1s complejidad y m\u00e1s oportunidades de confundir al jugador. El punto en que los controles resultan \u00abdemasiado\u00bb depende de la jugabilidad (si es un juego de estrategia, acci\u00f3n en primera persona, etc.), el esquema de control, la plataforma f\u00edsica de videojuegos (consola con mando, ordenador con teclado o rat\u00f3n, port\u00e1til con capacidades multit\u00e1ctiles, etc.) y de los propios jugadores. Si como dise\u00f1ador encuentras que es un reto ajustar toda la funcionalidad en un esquema de control que se entienda, una posible soluci\u00f3n ser\u00eda cambiar la jugabilidad para reducir la complejidad de la interfaz. As\u00ed pues, a pesar de que tu esquema de control parezca funcionar, siempre deber\u00edas considerar mejorar la experiencia del usuario simplificando los controles.<\/p>\n Una forma de simplificar tu esquema de control es utilizando controles basados en el contexto. Por ejemplo, a The Elder Scrolls V: Skyrim<\/em>, un \u00fanico bot\u00f3n f\u00edsico se asocia a la acci\u00f3n \u00abUtilizar\u00bb.<\/p>\n Seg\u00fan donde mire el jugador, el control contextual de The Elder Scrolls V: Skyrim<\/em> mostrar\u00e1 una acci\u00f3n u otra dependiendo del objeto. Dependiendo de qu\u00e9 se encuentre ante el personaje, este bot\u00f3n sirve tanto para empezar una conversaci\u00f3n, abrir una puerta, como para coger un objeto. Esta decisi\u00f3n de control, sin embargo, impone algunos l\u00edmites de dise\u00f1o; por ejemplo, si un objeto se encuentra demasiado cerca de una puerta, el usuario podr\u00eda abrirla accidentalmente cuando lo que quer\u00eda realmente era coger el objeto. Esta decisi\u00f3n de dise\u00f1o (unificar en un \u00fanico control sensitivo en el contexto diferentes acciones) tiene un impacto negativo menor que implementar otro bot\u00f3n f\u00edsico que fuera \u00abAbrir\u00bb, por ejemplo.<\/p>\n 2) Destacar los controles no disponibles.<\/strong> Se tiene que dejar siempre claro al jugador cuando un control no se encuentra disponible. Por ejemplo, en un juego de acci\u00f3n que permita al jugador cambiar de armas de forma r\u00e1pida, ser\u00eda frustrante ver una opci\u00f3n de control mostrando esta opci\u00f3n cuando no se dispone de una arma secundaria. El juego nunca deber\u00eda sugerir a los usuarios que pueden hacer algo que realmente no pueden hacer.<\/p>\n Hay generalmente dos aproximaciones para gestionar controles que no est\u00e1n disponibles. Una es simplemente no ense\u00f1ar el control. Esta opci\u00f3n ahorra espacio en pantalla y puede hacer que el juego parezca menos complejo; es por lo tanto una opci\u00f3n v\u00e1lida para los primeros compases de un juego para no mostrar a los jugadores acciones que no pueden hacer y que no entienden. Cuando el control est\u00e9 disponible m\u00e1s adelante, su aparici\u00f3n se puede destacar a trav\u00e9s de un texto de tutorial o un efecto visual \u2013llamando la atenci\u00f3n del jugador hacia la nueva habilidad u opci\u00f3n que representa.<\/p>\n Una segunda aproximaci\u00f3n es que el control se mantenga en pantalla pero \u00aben color gris\u00bb (cualquier otra forma com\u00fan de mostrar que una opci\u00f3n no se encuentra disponible). En este caso, si el rat\u00f3n pasa por encima de la opci\u00f3n o el bot\u00f3n del control intenta ser activado, hay que proveer feedback<\/em> que indique al usuario por qu\u00e9 el control no se encuentra disponible. Esta aproximaci\u00f3n funciona especialmente bien cuando el control ha estado previamente disponible para el jugador, donde, en este caso, sacar el control de pantalla podr\u00eda confundir m\u00e1s al jugador. Otra raz\u00f3n para mostrar los controles desactivados es para apoyar al sistema de recompensas del juego: los jugadores ven una opci\u00f3n que quieren y, por lo tanto, tienen un motivador extr\u00ednseco. Si todas las opciones del juego est\u00e1n ocultas, podr\u00eda disminuir para los jugadores el incentivo para seguir jugando o lograr determinados objetivos.<\/p>\n 3) Utilizar convenciones consistentes.<\/strong> La consistencia es un aspecto cr\u00edtico para la usabilidad de una interfaz. Los controles de una interfaz que son similares deber\u00edan funcionar de forma similar. Las interfaces nunca tendr\u00edan que hacer nada que sorprendiera al usuario. En t\u00e9rminos de controles visuales<\/em>, los elementos de una interfaz que hagan funciones similares deber\u00edan ser similares visualmente. Por ejemplo, los botones de una interfaz tendr\u00edan que parecer botones \u2013y asimismo cualquier cosa que no sea un bot\u00f3n no tendr\u00eda que parecer un bot\u00f3n.<\/p>\n Cualquier acci\u00f3n que los jugadores tengan que hacer que no lleve directamente a la acci\u00f3n deseada es una inconveniencia \u2013referido como una tasa<\/em> en el libro About Face 2.0: The Essentials of Interaction Design<\/em> por Cooper y otros (Cooper, Reimann y Dubberly, 2003).<\/p>\n Un punto cr\u00edtico al dise\u00f1ar esquemas de control es hacer que las acciones m\u00e1s importantes sean las m\u00e1s accesibles. Cualquier acci\u00f3n que un jugador tenga que hacer de forma frecuente debe estar asignada a uno de los controles primarios. Por ejemplo, si atacar en un juego de acci\u00f3n requiriera cuatro botones diferentes y navegar por diferentes men\u00fas, el juego seguramente resultar\u00eda frustrante de jugar y el ritmo del juego ser\u00eda de todo menos emocionante.<\/p>\n Un ejemplo que demuestra una correcta priorizaci\u00f3n de los controles combinada con una maximizaci\u00f3n de la inmersi\u00f3n puede encontrarse en el juego en primera persona Dead Space Extraction<\/em> (Wii). En Dead Space<\/em> en tercera persona, la salud se muestra en una barra de salud dieg\u00e9tica en la espalda del personaje, pero en Dead Space Extraction<\/em> no se puede hacer lo mismo, dado el punto de vista en primera persona. La salud del personaje es una informaci\u00f3n vital a la que debe ser f\u00e1cil acceder a ella y solo ser mostrada a trav\u00e9s del HUD en los juegos en primera persona. Para evitar un elemento no dieg\u00e9tico constante, este HUD est\u00e1 oculto hasta que el jugador no aprete un bot\u00f3n secundario del Wiimote<\/em>.<\/p>\n Esquema de control del Dead Space Extraction<\/em> para Wii. Algo que hay que considerar especialmente con implicaciones fuera de la jugabilidad son los pasos que el jugador tiene que llevar a cabo la primera vez que juega. Hacerlo f\u00e1cil al jugador para hacer f\u00e1cil la introducci\u00f3n al juego es especialmente importante en demostraciones o periodos de prueba; si los jugadores todav\u00eda no se han comprometido financieramente, es m\u00e1s probable que renuncien ante cualquier inconveniente. Un ejemplo sencillo es el siguiente: si hay que pulsar repetidamente el bot\u00f3n de acci\u00f3n principal y a la vez navegar por diferentes men\u00fas para entrar en el juego, estamos hablando de una alta complejidad para que el jugador pueda jugar en el videojuego. Una opci\u00f3n \u00abJugar\u00bb al inicio del juego ser\u00eda m\u00e1s conveniente, de forma que con un solo clic se empieza el juego.<\/p>\n Otro m\u00e9todo para reducir las tasas<\/em> en el control es minimizar toda la informaci\u00f3n que se pide al jugador para llevar a cabo determinada acci\u00f3n. Un ejemplo ser\u00eda reducir el n\u00famero de pasos requeridos para que un jugador ataque a un enemigo. El juego Star Wars: Knights of the Old Republic 2: The Sith Lords<\/em> es un ejemplo extremo de esta idea; el personaje puede autom\u00e1ticamente seleccionar, moverse y atacar un enemigo cuando se lo encuentra. Como este comportamiento quiz\u00e1s no es siempre deseable, se facilitan al jugador opciones de inteligencia artificial para que tenga m\u00e1s control de c\u00f3mo quiere que se haga la gesti\u00f3n de los personajes. Esta implementaci\u00f3n es especialmente \u00fatil en este juego porque el jugador tiene dos IA amigas \u2013y controlarlas todas al mismo tiempo ser\u00eda complejo y tedioso para el jugador.<\/p>\n Elementos f\u00edsicos de la UI del juego Star Wars: Knights of the Old Republic 2: The Sith Lords<\/em>. Otra opci\u00f3n es eliminar completamente la selecci\u00f3n autom\u00e1tica de los enemigos como en los juegos de disparos en primera persona (FPS) u otros g\u00e9neros de acci\u00f3n. Con esta aproximaci\u00f3n, pulsar el bot\u00f3n de ataque hace que el jugador dispare (o ataque con una arma cualquiera). La detecci\u00f3n de colisiones y las f\u00edsicas determinar\u00e1n qu\u00e9 se impacta con el ataque; no hay \u00abobjetivo\u00bb en s\u00ed. Esta aproximaci\u00f3n tiene otras implicaciones de interfaz: el movimiento y la c\u00e1mara deben estar especialmente refinados porque son cr\u00edticos en el transcurso de la acci\u00f3n.<\/p>\n Reducir la complejidad de la jugabilidad \u2013m\u00e1s all\u00e1 de s\u00f3lo sacar los controles\u2013 puede incrementar la usabilidad. Otro ejemplo de tases<\/em> en el control es el sistema de inventario en algunos juegos de rol (role playing games,<\/em> RPG,<\/em> en ingl\u00e9s). Para equipar un nuevo objeto, los jugadores normalmente tienen que entrar en un men\u00fa de gesti\u00f3n, seleccionar \u00abgesti\u00f3n de equipamiento\u00bb, y navegar por varias capas de men\u00fas para encontrar el objeto a equipar. Si los jugadores est\u00e1n intentando maximizar una habilidad en concreto, por ejemplo, la resistencia al fuego, quiz\u00e1s deben comparar todos los objetos hasta que encuentren el que tiene mayor resistencia al fuego. Incluso podr\u00eda ser que los elementos de armadura estuvieran divididos entre diferentes partes (casco, espalderas, etc.) y tipos (ligera, pesada, etc.), para a\u00f1adir todav\u00eda m\u00e1s complejidad a todo el proceso. Este tipo de sistemas, a pesar de ser realistas y proveer de profundidad, suelen ser tajantes<\/em> cognitivamente y dif\u00edciles de gestionar para el jugador.<\/p>\n C\u00f3mo podr\u00edamos reducir la tasaci\u00f3n<\/em> al control? Una posibilidad es reducir la complejidad de la jugabilidad reduciendo el n\u00famero de objetos del juego. Tener menos objetos reduce la variedad para el jugador, la tasa<\/em> asociada a la gesti\u00f3n de objetos nos obliga a cuestionarnos en primer lugar la necesidad de tener tantos objetos. Otra opci\u00f3n ser\u00eda dejar la complejidad de la jugabilidad tal como est\u00e1 (es decir, no reducir el n\u00famero de objetos), pero reducir la complejidad de la interfaz proveyendo al jugador de atajos que lo ayuden a maximizar las calidades de la armadura para determinados objetivos. Siguiendo con el ejemplo anterior, los jugadores podr\u00edan decidir que quieren maximizar su resistencia al fuego y la interfaz se encargar\u00eda de seleccionar todos los elementos que le ayudar\u00e1n a hacerlo. Para los jugadores que les gusta la complejidad y el detalle, la opci\u00f3n de continuar seleccionando los elementos de la interfaz de forma manual podr\u00eda mantenerse en paralelo a esta funci\u00f3n espec\u00edfica.<\/p>\n Muchas de estas gu\u00edas comportan la mejora de la usabilidad al hacer las cosas m\u00e1s f\u00e1ciles para los jugadores. Sin embargo, esta filosof\u00eda puede llevarse demasiado lejos en el dise\u00f1o de una interfaz para videojuegos, y esto tampoco es bueno. En los videojuegos, la usabilidad consiste en proveer la mejor experiencia de juego \u2013no s\u00f3lo maximizar la facilidad de uso. A pesar de que muchos jugadores se preocupan por los resultados finales, como por ejemplo ganar el juego, la satisfacci\u00f3n viene de la experiencia y el desempe\u00f1o del resultado. En el libro A Theory of Fun<\/em>, Raph Koster propone que la parte divertida de un juego es el aprendizaje que tienen que hacer los jugadores ante los retos siempre crecientes de un juego (Koster, 2005).<\/p>\n Imagen del juego Progress Quest<\/em>, donde se puede ver que toda la interfaz son listas y barras de progreso.<\/p><\/div>\n Llevado al extremo, hacer un juego f\u00e1cil de utilizar podr\u00eda significar un juego que se juega a s\u00ed mismo \u2013con los jugadores intentando, cuando menos, involucrarse con una experiencia interactiva (como an\u00e9cdota, hace muchos a\u00f1os apareci\u00f3 el juego Progress Quest<\/em>, un RPG en l\u00ednea donde el jugador no ten\u00eda que jugar, s\u00f3lo dejar la aplicaci\u00f3n abierta para ir consiguiendo objetos, experiencia y subir por las tablas de puntuaci\u00f3n). Por ejemplo, tened en cuenta la gesti\u00f3n de inventario comentada anteriormente. Cuando un oponente muere, los jugadores pueden saquearlo \u2013y ganar oro y otros objetos. Si los jugadores quieren maximizar los beneficios en juegos como Temple of Elemental Evil <\/em>o Icewind Dale<\/em>, los jugadores tienen que recolectar y vender todo el equipamiento mundano que los enemigos utilizan. Puesto que los personajes pueden cargar un m\u00e1ximo de peso u objetos, son necesarios varios viajes entre el pueblo y la Dungeon<\/em>. Estos tipos de juegos son consistentes con los juegos de rol de mesa, como el Dungeons & Dragons<\/em>, del que se han originado muchos de estos juegos.<\/p>\n El juego The Bard\u2019s Tale<\/em> (la versi\u00f3n de 2004, no el original de 1985) intent\u00f3 eliminar este aspecto tedioso de la jugabilidad dando directamente el oro a los jugadores cuando mataban a un enemigo. Si los jugadores encontraban una arma mejor que la que ten\u00edan, pod\u00edan asignarla directamente y hacer que la antigua arma se convirtiera directamente en oro. Esta implementaci\u00f3n tiene sentido hasta cierto punto; \u00bfpero qu\u00e9 pasar\u00eda si los jugadores no equiparan directamente la mejor arma cuando la encuentran? Bastantes cr\u00edticos comentaron en su \u00e9poca que el juego perd\u00eda parte del encanto de los toques tradicionales de los RPG mediante esta simplificaci\u00f3n. Para mucha gente, parte de la gracia de los RPG es vender objetos a los comerciantes e ir comprobando los nuevos objetos para ver si son realmente una mejora. Si se automatiza por completo este proceso se elimina completamente este aspecto de la jugabilidad. La lecci\u00f3n a aprender es que antes de simplificar la interfaz de un videojuego, aseguraos de que s\u00f3lo est\u00e1is eliminando tedio, no jugabilidad.<\/p>\n Un jugador cogiendo los objetos de un cad\u00e1ver en Baldur\u2019s Gate<\/em>. Fuente: screenshot<\/em> de Baldur\u2019s Gate<\/em>.<\/p><\/div>\n Las acciones que puedan resultar frustrantes para los jugadores tendr\u00edan que ser dif\u00edciles de conseguir por accidente. Esta directriz se aplica especialmente a los errores que se pueden producir durante un segmento intenso del videojuego. Por ejemplo, con un mando de Xbox, si se utilizan los botones \u00abB\u00bb y \u00abX\u00bb para varias combinaciones de ataques, pero el bot\u00f3n \u00abA\u00bb abre una pantalla de inventario, la posibilidad de frustraci\u00f3n es alta porque el jugador puede pulsar accidentalmente \u00abA\u00bb mientras cambia entre los botones \u00abB\u00bb y \u00abX\u00bb. Tened especial cuidado a la hora de asignar determinados tipos de acciones a las palancas de control anal\u00f3gicas de un controlador de consola. Mediante el uso normal de la palanca de control anal\u00f3gica, el jugador puede pulsar f\u00e1cilmente el bot\u00f3n del control anal\u00f3gico, activando cualquier acci\u00f3n que est\u00e9 asignada. En Dark Cloud 2<\/em>, por ejemplo, se usan los botones anal\u00f3gicos para cambiar de personaje; deshacer este cambio de personaje es tedioso e interrumpe el flujo de combate.<\/p>\n Imagen del juego Dark Cloud 2<\/em> durante unos momentos de lucha. Un concepto relacionado con la minimizaci\u00f3n de las posibilidades de errores accidentales es la estrategia Do What I Mean<\/em> (DWIM), que implica interpretar la intenci\u00f3n del usuario en vez de admitir a ciegas las entradas de control. Si el jugador comete un error, pero el juego puede identificar lo que el jugador realmente quer\u00eda hacer, el juego sigue la intenci\u00f3n del jugador en lugar de la orden literal. Por ejemplo, si un jugador sale del juego, pero no ha guardado la partida recientemente, el juego deber\u00eda cuestionar esta decisi\u00f3n, requiriendo la confirmaci\u00f3n y pidiendo al jugador que guarde el juego antes de salir. (Una mejor implementaci\u00f3n podr\u00eda ser guardar autom\u00e1ticamente el juego en un espacio de guardado autom\u00e1tico, en lugar de molestar al jugador con la solicitud de confirmaci\u00f3n). Aun as\u00ed, si el jugador acaba de guardar el juego, el juego deber\u00eda salir para minimizar las molestias.<\/p>\n Vuestra interfaz siempre deber\u00eda apoyar al juego. Esta directriz engloba b\u00e1sicamente todas las dem\u00e1s, pero vale la pena mencionarla por separado para destacar la importancia de como el juego y la interfaz funcionan con o contra ellos mismos si no tenemos cuidado. Por ejemplo, a Star Wars: Knights of the Old Republic<\/em>, el jugador tiene dos tipos de armas: \u00abcuerpo a cuerpo\u00bb y \u00aba distancia\u00bb. Cambiar entre un blaster<\/em> y el sable de luz requiere que el jugador abra el modo de gesti\u00f3n, acceda a los equipos, seleccione la ranura del arma y, finalmente, elija una arma nueva. Este proceso de m\u00faltiples pasos interrumpe el flujo de combate y resulta tedioso para el jugador.<\/p>\n Una de las mejoras hechas en la secuela Star Wars: Knights of the Old Republic 2: The Sith Lords<\/em> implic\u00f3 crear un control para la acci\u00f3n de conmutaci\u00f3n de arma. El jugador pod\u00eda tener una segunda arma equipada en la ranura y pod\u00eda cambiar entre las dos armas con una sola tecla sin salir del modo de combate. Al reducir las tasas<\/em> de control, se pudo animar a los jugadores a utilizar los dos estilos de combate mediante la interfaz del juego. Sin embargo, esta mejora no tuvo un \u00e9xito completo por dos motivos: primero, mientras que se hizo un esfuerzo para equilibrar mejor la utilidad de las armas de rango y de cuerpo a cuerpo, las t\u00e1cticas generales de combate no cambiaron \u2013y esto hizo que el cambio de arma tampoco tuviera mucha importancia. En segundo lugar, como en el juego original, los \u00e1rboles de habilidades para armas \u00aba distancia\u00bb y \u00abcuerpo a cuerpo\u00bb estaban separados; por lo tanto, la mayor\u00eda de los jugadores se especializar\u00edan en un tipo de combate. Poder cambiar r\u00e1pidamente entre armas de diferentes estilos no resultaba finalmente ventajoso.<\/p>\n Mientras que la adici\u00f3n del bot\u00f3n de cambio r\u00e1pido de arma hizo mejorar la interfaz, compar\u00e1ndolo con el primer juego, las imperfecciones fundamentales del dise\u00f1o de jugabilidad limitaban toda la ayuda que aportaba este cambio de control. La interfaz y el juego no estaban completamente sincronizados.<\/p>\n Maximizar la usabilidad de un esquema de control puede ser un reto, dado que un cambio aparentemente peque\u00f1o puede reverberar en muchos aspectos de vuestro dise\u00f1o \u2013se resuelve un problema cr\u00edtico, pero se introducen nuevos problemas. A medida que iter\u00e1is sobre vuestro esquema de control, hay que pensar en los efectos que puede tener un cambio en cualquiera otro sistema.<\/p>\n Cooper, A.; Reimann, R.; Dubberly, H.<\/strong> (2003). About Face 2.0: The Essentials Of Interaction Design<\/em>. John Wiley & Sons, Inc.<\/p>\n Raph<\/strong>, K.<\/strong> (2005). A Theory Of Fun For Game Design<\/em>. Nueva York: Paraglyph Press.<\/p>\n","protected":false},"excerpt":{"rendered":" Introducci\u00f3n La usabilidad es igual de importante que la funcionalidad para que un juego sea \u00abdisfrutable\u00bb. La funcionalidad de un videojuego puede visualizarse listando todas las acciones requeridas y asegur\u00e1ndonos de que el usuario puede llevarlas a cabo, pero la usabilidad es m\u00e1s dif\u00edcil de cuantificar. Si una interfaz permite realizar todas las acciones necesarias, […]<\/p>\n","protected":false},"author":4,"featured_media":18327,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[24],"tags":[],"_links":{"self":[{"href":"http:\/\/design-toolkit-test.uoc.edu\/es\/wp-json\/wp\/v2\/posts\/14802\/"}],"collection":[{"href":"http:\/\/design-toolkit-test.uoc.edu\/es\/wp-json\/wp\/v2\/posts\/"}],"about":[{"href":"http:\/\/design-toolkit-test.uoc.edu\/es\/wp-json\/wp\/v2\/types\/post\/"}],"author":[{"embeddable":true,"href":"http:\/\/design-toolkit-test.uoc.edu\/es\/wp-json\/wp\/v2\/users\/4\/"}],"replies":[{"embeddable":true,"href":"http:\/\/design-toolkit-test.uoc.edu\/es\/wp-json\/wp\/v2\/comments\/?post=14802"}],"version-history":[{"count":6,"href":"http:\/\/design-toolkit-test.uoc.edu\/es\/wp-json\/wp\/v2\/posts\/14802\/revisions\/"}],"predecessor-version":[{"id":18034,"href":"http:\/\/design-toolkit-test.uoc.edu\/es\/wp-json\/wp\/v2\/posts\/14802\/revisions\/18034\/"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/design-toolkit-test.uoc.edu\/es\/wp-json\/wp\/v2\/media\/18327\/"}],"wp:attachment":[{"href":"http:\/\/design-toolkit-test.uoc.edu\/es\/wp-json\/wp\/v2\/media\/?parent=14802"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/design-toolkit-test.uoc.edu\/es\/wp-json\/wp\/v2\/categories\/?post=14802"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/design-toolkit-test.uoc.edu\/es\/wp-json\/wp\/v2\/tags\/?post=14802"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Minimizar la confusi\u00f3n<\/strong><\/h2>\n
![\"\"](\"\/wp-content\/uploads\/2020\/12\/27193_001-1024x610-1.jpg\")
Fuente: screenshot<\/em> de The Elder Scrolls V: Skyrim<\/em>.<\/p><\/div>\nMinimizar la<\/strong> inconveniencia<\/h2>\n
La<\/strong> conveniencia debe estar emparejada a la importancia<\/strong><\/h3>\n
![\"\"](\"\/wp-content\/uploads\/2020\/12\/27193_002.jpg\")
Fuente: Manual Dead Space Extraction<\/em> (Wii).<\/p><\/div>\nPermitir una<\/strong> introducci\u00f3n f\u00e1cil<\/strong><\/h3>\n
Eliminar pasos<\/strong> innecesarios<\/h3>\n
![\"\"](\"\/wp-content\/uploads\/2020\/12\/27193_003.jpg\")
Fuente: screenshot<\/em> de Star Wars: Knights of the Old Republic 2: The Sith Lords<\/em>.<\/p><\/div>\nEliminar<\/strong> complejidad innecesaria<\/strong><\/h3>\n
No facilitar<\/strong> mucho la vida del jugador<\/strong><\/h2>\n
![\"\"](\"\/wp-content\/uploads\/2020\/12\/27193_004.jpg\")
![\"\"](\"\/wp-content\/uploads\/2020\/12\/27193_005-1024x576.jpg\")
Prever errores<\/strong> accidentales<\/h2>\n
![\"\"](\"\/wp-content\/uploads\/2020\/12\/27193_006.jpg\")
Fuente: screenshot<\/em> de Dark Cloud 2<\/em>.<\/p><\/div>\nApoyar<\/strong> la jugabilidad<\/strong><\/h2>\n
Referencias<\/h2>\n