Roba pero Hace Obra – Postmortem 2015

Publicamos Roba pero Hace Obra (2014) hace 10 años. En ese entonces la alcaldesa de Lima, Susana Villarán, enfrentaba un proceso de vacancia del que finalmente se salvaría. Entonces empezaba una década de inestabilidad política en Perú, en la que la vacancia y renuncia de autoridades electas se volvió moneda de cambio. Roba pero Hace Obra retrató ese momento satíricamente, presentando -casi como en chongo- una teoría sobre el poder, la corrupción y el gobierno en Perú.

Comparto a continuación el postmortem del juego que presenté en la Universidad Católica en el año 2015, en un evento de IGDA Perú. Tenía pensado escribir uno “original”, pero sabía que alguna vez había creado uno y tuve suerte de encontrarlo. Incluyo el documento sin cambios, porque me importa preservarlo como registro de mis ideas sobre este juego -y los juegos peruanos.

Postmortem Roba pero Hace Obra

Me gustaría agradecer en primer lugar a los miembros de IGDA Perú, y en especial a Carlos Mendoza por invitarme a participar de este evento, y por darle a “Roba pero Hace Obra” un espacio para visitar el mundo académico. Gracias también a la Universidad Católica, que en los últimos años busca consolidarse como un espacio para el desarrollo y la promoción de las artes digitales, la tecnología, y las humanidades en Perú.

Ya se hacía notoria la ausencia de una discusión que nos permita acercarnos a entender la relación que existe entre nuestra sociedad, la tecnología, la industria del entretenimiento y la educación (por más de que esta última relación pueda parecer en un principio contradictoria, forzada, o trillada). Este estudio debe de involucrar a los programas académicos de Humanidades, Comunicaciones, Psicología, Ciencias Sociales, Artes, e Ingeniería en todo el país.

RayoLaser

Hoy vengo a hacer el post-mortem de “Roba pero Hace Obra” en representación de “RayoLaser”. No podría definir con precisión qué es “RayoLaser”, pero podríamos decir que es una especie de “think tank” de entretenimiento que nació a finales del año pasado buscando agrupar proyectos que tengan que ver con el estudio y la producción de artes digitales, ficción interactiva, y nuevas formas de narrativa. Fundé “RayoLaser” a inicios del año 2013. Hoy colaboramos orgullosamente con con Rafael Gutiérrez, Gabriel Sánchez y Ricardo Gutiérrez.

Es para mí importante reconocer el trabajo de las personas que trabajaron conmigo en el desarrollo de este videojuego. Gabriel Sánchez Crisanto “El Mono de la Pistola” se encargó del diseño de “Ratañeda” -el especialista en “gestión y gobernabilidad” que pueden encontrar el juego-, y de enmendar todos mis errores y desaciertos en el diseño de la interface del juego. Su apoyo y empuje fue determinante para que el proyecto salga adelante y a tiempo. Todas las aberraciones de diseño y las falencias en el desarrollo de la interface corren por mi cuenta.

En segundo lugar quisiera mencionar a mi amigo chileno “Iceheart Kuchufleta”, que de buena gana y con mucha paciencia me asesoró con la programación del juego. Conocí a Iceheart en un foro de programación de manera casual y su apoyo ha sido determinante en este proyecto.

Naturaleza del trabajo

“Roba pero Hace Obra” puede ser entendido de manera general como un juego de simulación, pero es en esencia un argumento, un “statement” sobre la realidad política de las instituciones ediles, la ciudadanía, y la cultura nacional. No existió un “objetivo” a la hora de comenzar el proyecto, más que llamar la atención sobre una situación que nos aqueja a todos y que siempre se ha visto representada de una forma que –a mi parecer- es ya repetitiva (la caricatura, el reportaje).

El argumento que buscamos representar es el siguiente: La ciudad de Lima atraviesa una aguda crisis política. Existe una especie de desfase entre las demandas de los electores (la población), y las capacidades e intenciones de los políticos, o las instituciones gubernamentales. En esa línea, la corrupción es tolerada en la medida que el pueblo limeño (todos nosotros) reciba lo que más le gusta, que son grandes obras de infraestructura, o “gestos políticos”, por sobre reformas estructurales a mediano o largo plazo. El pueblo peruano es majadero e histérico (siempre tiene motivos para molestarse), e incluso tiene la capacidad de cesar a los gobernantes de sus funciones (ahí tienen la revocatoria); pero por otro lado tiene memoria a corto plazo, y saber perdonar, incluso a aquellos que le han hecho grandes males. Entonces, al político no solo se le exige ser un pragmático o técnico de la inversión pública, sino que tiene que calcular fríamente cualquiera de sus movidas en la ciudad.

Esboza también otros statements; a saber, que si eres un político, te guste o no, vas a tener que rozarte con la corrupción y la mafia, y tarde o temprano vas a tener que tranzar, o vas a ser atacado por tu oscuro pasado o el de los que están cerca de ti; o que nadie está a salvo en la fauna política nacional: puede ser un hermano etnocacerista, una suegra sobreviviente del Holocausto, unos audios sexuales, o un hijo descarriado.

“Roba pero Hace Obra” es un juego de simulación que no busca pecar de “realista” (sic), sino que es fiel a su propia naturaleza. El jugador ocupa el lugar del alcalde de un modelo de ciudad creado por mí; mi propia ciudad virtual, con sus propias mecánicas y posibilidades. El jugador –como alcalde de Lima- tendrá que tomar decisiones que le permitan encontrar el balance perfecto en una ciudad en la que la popularidad importa mucho, la corrupción es una opción cotidiana, y la memoria es de muy corto plazo.

Marco teórico

Retórica procedural

Ian Bogost presentó en su libro “Persuasive Games” el concepto de “retórica procedural” (“procedural rethoric” en inglés), para explicar la naturaleza expresiva y comunicativa de (no tan nuevos) artefactos culturales, como son los videojuegos y las simulaciones. Retórica procedural es persuadir haciendo el uso de procesos o procedimientos. Así, los procesos informáticos sirven para recrear sistemas complejos o darle vida a sistemas imaginarios, y nuevas formas ficcionales que ponen al jugador en rol determinado, para cumplir una función específica. El autor o diseñador crea reglas que permiten la generación de representaciones. Los sistemas de reglas, las mecánicas, sirven para generar comportamientos en el jugador. De esta manera se crean significados y se da un aprendizaje mediante la interacción de un jugador con una serie de algoritmos, procesos, órdenes.

En ese sentido, Sim City plantea argumentos y puntos de vista sobre la metrópolis norteamericana de finales de 1980: cuestiona a la utopía urbana, y vaticina el deseo de pragmatismo y tecnificación de la política que hoy es característico. Pone al jugador en una posición de poder en la que el cinismo o el moralismo kantiano pueden ser costosos. Plantea una función particular para el crimen, los desastres naturales, o los eventos deportivos. Pero también nos enseña acerca de diseño, y estética. Todo esto a través de una experiencia construida mediante procesos informáticos, iteraciones.

Literatura ergódica

Espen J. Aarseth en “Perspectivas sobre la Literatura Ergódica”, plantea otra entrada para entender los nuevos artefactos culturales. Aarseth dice que lo que caracteriza a los juegos, -entre otras otras nuevas formas de expresión-, es que el usuario no puede acceder al texto, si es que no hace un esfuerzo no-trivial para así poder decodificar el mensaje del autor. Según Aarseth, en un juego, el participante crea información que es interpretada por el sistema para producir resultados. Un jugador no solo produce información sobre su posición en el mundo o tablero (ghost), sino que también puede alterar el mundo en el que se desarrolla su acción, en algunos casos con mucha facilidad y un sorprendente grado de “libertad”.

Mi historia como desarrollador

Estudié sociología en la PUCP hasta el año 2011 y desde ese entonces me he desempeñado como profesor de ciencias sociales de nivel secundario en un colegio privado de Lima, y también me he dedicado a la producción musical.

Mi formación en informática siempre fue paupérrima, pero recuerdo haber pasado Carmen San Diego con mi papá cuando tenía 4 años. Así me aprendí las banderas y capitales de países que ya no existen. Luego, al año siguiente vino Maniac Mansion junto a mis primos, y Ancient Art of War nuevamente con mi papá. He jugado de todo, pero siempre he tenido una debilidad por los juegos de simulación, la administración, y los quests.

Creé mi primer juego en enero del 2014 haciendo uso de la versión gratuita de Construct 2. Me tomó 3 semanas hacerlo, y nadie lo pudo probar. “Un Día en la Vida”, era un simulador sobre mi vida como profesor de colegio, sociólogo, músico aficionado, adicto a los videojuegos, y aspirante a programador de simulaciones. Un relato sobre mí haciendo relatos.

Mi segundo proyecto fue crear un “motor de simulación” en Construct, llamado “motor ‘Cabitos’”. “Cabitos” te ponía en los zapatos del militar encargado de la infame base del ejército peruano en el que se cometieron tantas violaciones a los derechos humanos, y se maquinó la opresión de miles de compatriotas que sufrieron injustamente. “Cabitos” buscaba representar la complicada situación de las fuerzas del orden y el pueblo ayacuchano durante el Conflicto Armado Interno. La dinámica está planteada de tal manera que en cada momento tus decisiones sobre el presupuesto, las estrategias contrasubversivas a usar, o las formas de interrogatorio que permitas influenciarán en la percepción que el pueblo ayacuchano tiene de tu gestión como militar, en el desarrollo del conflicto armado, y en el destino de toda una nación. Lamentablemente el proyecto se estancó y el “motor” nunca se pudo terminar de implementar.

La idea era crear una plataforma que les permita a los profesores crear sus propias simulaciones sobre problemas sociales o dilemas éticos que les quisieran plantear a los alumnos. Los profesores tendrían que establecer las variables de los modelos y la forma en que se relacionarían estas variables con las decisiones de los jugadores/alumnos. Es una deuda pendiente que tenemos y que estamos empezando a saldar.

Sobre Roba pero Hace Obra

“Roba pero Hace Obra” se desarrolló durante 3 semanas, entre septiembre y octubre del 2014 usando Construct 2, versión r149. La idea de desarrollar un juego sobre la situación política de Lima en el contexto de las elecciones tan solo fue una reacción a esta foto:

No existió intención política más que la de llamar la atención sobre nuestra situación. Hemos recibido al correo amenazas e insultos varios. Gente que nos acusa de haber trabajado a sueldo para Susana Villarán o para otros políticos. Creo sinceramente que en el Perú se subestima el arte de joder por joder, la libre expresión de estar harto.

El Sistema

Roba pero Hace Obra es una rat race (no pun intended). Una alegoría a la aparente condena de los políticos y de la sociedad peruana de estar viviendo un bucle, un loop, una constante repetición.

Las herramientas

Construct 2 es una herramienta para el desarrollo de juegos y aplicaciones en 2D haciendo uso de la tecnología HTML5. Su versión básica es gratuita y basta para crear cosas muy interesantes. La versión pagada no es cara y vale la pena, ya que el equipo de Scirra (indie también) está constantemente renovando el software y toma en cuenta los problemas de los usuarios y sus opiniones sobre la herramienta. La comunidad de usuarios es muy activa y organizada, y esta es una cosa muy valiosa cuando se trata de aprender algo.

Si bien Scirra promociona su producto como un software para hacer juegos sin conocimientos de programación, se requiere que el diseñador tenga capacidad de abstraerse y comprender la forma en que se estructura y funciona un programa de computadora. Son importantes los conocimientos de lógica, una disciplina que en las escuelas peruanas es enseñada como una “forma de matemática”, léase, como un problema más que el alumno tiene que enfrentar.

Etapas

Lamentablemente, el proceso de diseño, desarrollo y publicación del juego no fue debidamente documentado. Este es un gran problema no solo mío, sino de muchas personas que buscan emprender una iniciativa, un negocio, o incluso un proyecto de mayor envergadura. En el Perú nos cuesta sistematizar, ordenar, cerrar procesos e ideas. Llevar la cuenta.

He logrado guardar casi 40 versiones diferentes del juego como si fueran una especie de reliquia, pero no he llevado un control detallado y ordenado de los cambios que he ido introduciendo. Grave error que ahora es imposible de enmendar.

Podría identificar, sin embargo, al menos 5 grandes etapas:

• Una primera etapa de conceptualización y elaboración de la idea. Le doy forma no solo a mi idea de juego, sino también al argumento, a lo que quiero mostrar.
• Una segunda etapa en la que empecé a plasmar mis ideas en un “canvas” (literalmente). Cree una primera pantalla del juego, lo hice funcionar, le di vida.
• Con el juego corriendo (y acá me refiero básicamente a un contador de segundos que establecía la fecha ficticia), es más fácil encariñarse con el proyecto y creer que se está aterrizando sobre algo concreto.
• Una tercera etapa en la que he ido estableciendo los límites del juego (cómo se gana, cómo se pierde, qué puede controlar el jugador). Esta etapa es sumamente complicada, porque implica se realista sin dejar de ser imaginativo.
• Una cuarta etapa en la que he ido perfeccionando los sistemas del programa, a la vez que he desarrollado el texto del juego, su propuesta narrativa y estética. Acá aparecen miles de bugs y uno se pregunta nuevamente por el género del juego ¿Es una simulación? ¿Es una ficción interactiva? ¿Es una rat race? Esta etapa termina con un profundo odio hacia mi criatura.
• Una quinta etapa que comienza con depresión pero puede terminar de manera positiva y alentadora. El juego se vuelve “jugable” y ya es posible terminar una partida entera. Aparecen preguntas sobre el final del juego y su duración. ¿Es entretenido? ¿Qué elementos pueden hacer que el jugador llegue hasta el final? ¿Quiero que llegue hasta el final? ¿Qué cosas puedo hacer para hacerlo más fácil/difícil, balanceado?

Hallazgos

• El conocimiento está descentralizado y es de fácil acceso para cualquier persona que tenga servicio internet y sepa buscar información.
• Las comunidades de programadores y foros son grandes fuentes de información. La gente está dispuesta a ayudar.

Falencias

• Aprendizaje empírico (ensayo, error, emulación).
• Perfeccionamiento de la técnica: programación con estilo, del proceso de diseño.
• Eficiencia (soluciones en programación, organización de tiempo, periodización del trabajo).
• No se llevó un registro adecuado de las actividades.

Diseño

• No tengo clara la propuesta estética.
• Hay elementos del juego que han sido implementados de manera rápida y parcial. (tutorial).
• Dedicación (¿parcial?).
• Estudio sistemático. (necesito tiempo para hacer un estudio sistemático de aquellas ramas del conocimiento o técnicas que me permitirían trabajar mejor).
• Probar soluciones. (se aprende demasiado cuando se le dedica un tiempo a probar aquellas soluciones no ortodoxas a los problemas que aparecen en todo sistema).
• Enfrentar frustración. (como en cualquier proceso creativo, es fundamental desarrollar mecanismos que le permitan al diseñador frustrarse “ordenadamente”, sin llegar a puntos límite).

Sobre la industria de los videojuegos

Es importante contar con una plataforma o backup institucional (estudio independiente, universidad, prensa). Es una forma de soporte, legimitidad.

Falta una sistematización real sobre nuestra propuesta estética y tecnológica. El game design document no basta. La review no es análisis.

Existe un gran potencial. El modelo de producción independiente de videojuegos responde a otras lógicas, que no son las lógicas predominantes del mercado en el país: segmentado, discriminador, argollero. Estamos hablando de producir ficciones, experiencias, para un público que ya goza con el producto que buscamos explotar. El mercado de videojuegos en el Perú ya tiene la importancia de otros mercados tradicionales como el de la literatura, el cine, o el teatro. Y no solo a nivel económico, sino también a nivel cultural. El nuevo mercado de videojuegos no segmenta, sino que une en una misma lógica a millones de consumidores distintos, y a diversos grupos de productores y distribuidores (legales o ilegales).