Si vemos que las buenas ideas empiezan a repetirse, debemos creer entonces que las cosas están mejorando.

De forma lamentable, creo que la respuesta es negativa.


Al igual que en mi último Post, hoy me referiré a un juego desarrollado por una empresa como herramienta de vinculación con sus posibles clientes.

La empresa, SAP, es líder en la implementación de software de administración de recursos, es por ello que no me sorprende que busquen constantemente nuevas formas de relacionarse con sus clientes, haciendo la comprensión de sus servicios un proceso más simple, amable y, por qué no decirlo, divertido.

Sin embargo la experiencia relacional es tan pobre, que dudo que quien pase por esta simulación se siente compelido a  probar una plataforma SAP. Hagamos una revisión de dicha experiencia.

Descripción:
El juego en cuestión (alojado en http://www.pensarengrande.cl/flash.html) es una simulación del día de trabajo del empleado de una empresa. La interfaz nos muestra como este trabajador se desplaza por la empresa y debe resolver distintos tipos de problemas asociados a su gestión de ventas, como por ejemplo, stock, historial de clientes, transacciones, gestión de procesos, etcétera.

Lo anterior es presentado a través de una estructura de árbol de decisión en el cual el jugador deberá elegir entre dos posibilidades de acción.

Según las decisiones que tome obtendrá puntaje a tres categorías que representarán su gestión, las que son estress, productividad y rentabilidad.

Épica:
El estilo visual simple con influencia del diseño de información y de flujogramas es adecuado para un juego que apunta a pedagogía empresarial.

Ahora bien la falta de elementos narrativos de fondo, como así una estructura de estilo poco definidas hacen que el juego parezca tosco o en una primera etapa de desarrollo.

Por otra parte el uso de un lenguaje poco coloquial en las interfaces de uso genera un distanciamiento emocional entre el jugador y la experiencia.

Soporte:
Errores de programación hacen que el juego falle al, por ejemplo, introducir una arroba (no reconoce el comando altgr+q).

Textos que se escapan de sus globos que los sostienen, audios descalzados e iconografía poco clara que no aportan al desarrollo del juego, son percibidos como adornos innecesarios.

Ausencia de un control de jugadores inscritos obliga al jugador a reintroducir sus datos cada vez que quiere jugar.

La captura de datos de contacto debiese hacerse después de la experiencia o como una forma de liberar etapas, no al principio, ya que no se aprovecha la experiencia de satisfacción.

Mecánica:
La estructura de árbol de decisión excesivamente corta limita la experiencia de rejuego a 3 ocasiones, e impide un entrenamiento progresivo del jugador.

Existe una nula conexión entre objetivos, resultados y ganancias con los valores premio del juego. No importa cuántas veces juguemos, el puntaje siempre será el mismo.

El juego no reconoce las habilidades propias del jugador antes de jugar y establece que todo criterio de decisión es, per sé erróneo.

Conclusión:
Comprendo que la gente de SAP haya querido (implícitamente) hacer un Juego de Crisis, ya que así se valoriza su producto.

En un JdC, la estructura del juego está pensada para que el jugador pierda sin importar lo que haga, de este modo reconozca las debilidades en sus procedimientos y busque nuevas alternativas de resolución.

Sin embargo todo JdC reconoce que existen derrotas y derrotas catastróficas, como así también simulaciones ideales. De este modo el jugador podría, en el caso de SAP mejorar su desempeño cada vez que lo juegue sin que ello implique que gane el juego. Además el juego podría implementar un cheat mode en el cual, a través de alguna estratagema el jugador pudiese instalar SAP para ganar el juego.

Para cerrar, creo que nuevamente el problema no pasa por SAP, quienes piden la solución, si no la falta de capacitación de quienes prestan este tipo de servicio, en otras palabras:

Más juego y menos código.