Loot Boxes

En el proceso de diseño de un juego, podemos elegir entre distintas mecánicas o técnicas con el objetivo de “enganchar” al jugador y que quede prendado. Lejos de ser un proceso ad hoc, detrás hay un importante trabajo de trasfondo psicológico, no tecnológico, y de comprensión de qué cosas nos motivan a actuar, o qué nos parece o no “divertido”, aun cuando este concepto es totalmente subjetivo. El quid de la cuestión en todo esto, y una parte de la responsabilidad del diseñador, es el enfoque que va a dar en la elección de una mecánica concreta: si se centra en una visión que desea apoderar al jugador (por ejemplo, empujarlo a dar lo mejor de si mismo, darle capacidad de elección) o simplemente  aprovecharse de sus debilidad en ciertos aspectos compulsivos, que todos tenemos, como humanos que somos (en palabras simples, ludopatía). Esta dicotomía está bastante bien presentada, por ejemplo, en el framework de Octalysis de Yu-Kai Chou, donde se diferencian los impulsos de un jugador en su matiz “whitehat” y “blackhat”. Y como decían en una cierta película, el lado oscuro no es necesariamente más poderoso, pero sí más rápido, fácil, seductivo… Un ejemplo que en los últimos meses ha dado mucho que hablar es el concepto de “loot box” o “loot crate”. Una mecánica basada en que el jugador invierte recursos en adquirir una “caja sorpresa”, y por lo tanto, no puede garantizar que va a obtener aquellos objetos del juego que realmente desea. Los motivos por lo cuales un objeto concreto es deseado pueden variar, y pueden ir desde simplemente una cuestión de ‘completismo’, para...

GDC 2017 – Trabajando con RNGs en videojuegos

Otro de los ejes temáticos del pasado GDC 2017 (ver entrada anterior) fue el tutorial dedicado a revisar fundamentos matemáticos para programadores. Éste estaba soportado por un grupo de interés sobre este tema (Math for Game Programmers) y, evidentemente,  se alejaba ya bastante de la visión conceptual del game design y se adentraba en las entrañas de la programación de los videojuegos. Concretamente, me parecieron interesantes a título personal las dos charlas que llevaron acabo por Squirrel Eiserloh (SMU Gildhall) y Shay Pierce (Dire Wolf Digital). Ambas trataban sobre distintos aspectos de los generadores de números aleatorios (o RNG, Random Number Generator) que se deben tener en consideración cuando se usan en un videojuego. Un tema que me apasiona y del que ya escribí hace bastante tiempo en una breve entrada anterior. Sobretodo por el hecho que los RNGs suelen ser clave en el campo de la seguridad, pero las reglas para usarlos, y lo que queremos de ellos, en el contexto de los videojuegos puede ser un poco distinto. Por una parte, la presentación de Shay, titulada “Dark Secrets of the RNG“, se enfocaba hacia el uso de un RNG como herramienta para el cálculo de probabilidades y dar algunas lecciones sobre aspectos en su aplicación en videojuegos.  Por ejemplo, en un juego de estrategia o rol, una unidad o personaje ataca a otra y por las reglas se decide que tiene un 90% de probabilidades de acertar al adversario y causar daño. Con un RNG se genera un valor al azar entre 0-99, y si el valor es inferior a 90, se considera que el ataque tiene...

GDC 2017 – Diseño de niveles

Recientemente, se ha celebrado la Game Developers Conference (GDC) de este año en la ciudad de San Francisco, a la que he tenido la suerte de poder asistir. En esta conferencia se realizan ciclos de charlas sobre los aspectos más variopintos del desarrollo de los videojuegos: diseño, programación, monetización, audio, RV/RA, post-mortems, narrativa, etc. Lo que tú quieras, seguro que hay su ciclo de charlas. Si bien tiene una importante componente a nivel presentación de productos de la industria, con su correspondiente zona de expositores y stands de turno, lo más importante aquí son las charlas por parte de los profesionales, algunos de gran nivel (Sid Meyer, Warren Spector). De hecho, la cantidad es tal que resulta imposible asistir a todas. En cada turno se pueden solapar tranquilamente más de diez o doce (por ejemplo, ¡el primer día ya empezaba con 18 en paralelo!), todas ellas interesantísimas. No había más remedio que elegir… Durante los dos primeros días, normalmente se celebran distintos “summits”, o reuniones temáticas sobre aspectos muy concretos, dónde normalmente se reúne gente del mismo ámbito dentro del desarrollo de videojuegos. En mi caso, asistí a una parte del taller sobre diseño de niveles. De las distintas charlas, un par me parecieron especialmente interesantes. Por una parte, la realizada por Steve Lee (Arkane Studios), que trataba de una visión holística del diseño de niveles a través de los Dishonored (AN APPROACH TO HOLISTIC LEVEL DESIGN). Por otra parte, la de Clemence Maurer (Eidos-Motréal), que compartía su experiencia en el diseño de las recompensas por exploración en el juego Deus Ex: Mankind Divided (REWARDING EXPLORATION IN ‘DEUS EX:...

Sistemas anti-trampas (anti-cheating)

El hecho de jugar es algo natural en muchos seres vivos, no solo los humanos. Pero si hay algo que seguramente sí que es una característica nuestra es el hacer trampas. Saltarnos las restricciones impuestas en el contexto del juego con tal de obtener una ventaja. Como comentábamos en un conjunto de entradas anteriores, existen diversos sistemas para poder hacer trampas. Pero analicemos el problema desde la perspectiva del “defensor”. ¿Podemos evitar que un jugador haga trampas en nuestro videojuego? Antes de plantearnos proteger nuestro juego contra los tramposos, y dedicar un esfuerzo a ello, sí que es interesante hacer antes la reflexión de si vale la pena. El caso más interesante para un debate es el de un juego de un solo jugador. Por un lado, hacer trampas no es más que el equivalente a “mirar las soluciones del crucigrama” en el reverso de la página. Aún así, también vale la pena tener en mente que el sentido de la diversión y la dificultad es muy personal. ¿Qué tiene de malo dejar que alguien obtenga ciertas ventajas, o se salte una parte, y así no abandone el juego? Al final, cada uno es dueño de su propia diversión y escapismo. Sin embargo, y por otra parte, sí que existen juegos que dentro de ciertos contextos sociales o colectivos, aún cuando se platean como experiencias individuales, se considera que conseguir ciertos hitos otorga “derechos al fanfarroneo” (bragging rights). Para la comunidad de jugadores, los tramposos, en cierto modo, devalúan los logros de los jugadores “legales”. Por lo tanto, se valora que el juego esté protegido contra tramposos igualmente, para...

¿Qué debería aprender un desarrollador de motores de videojuegos?

En el pasado GameLab, y más allá de las charlas de grandes gurús explicando sus batallitas, también fue posible asistir a ponencias más de tipo orientación para aquellos interesados en dedicarse al mundo del desarrollo de videojuegos. Todas eran muy interesantes, pero quizá la que más me llamó la atención  por su título fue la ofrecida por Mike Acton, director de motores (Engine Director) en Insomniac Games, creadores de sagas con tanta solera como Spyro o Ratchet & Clank (de éste último hay hasta una película de animación relativamente reciente). La ponencia llevaba el título “Process I wish they taught engine programmers in school” (Procesos que desearía que enseñaran a programadores de motores en la escuela). Un tema interesante no solo para los estudiantes, sino toda una llamada a los propios docentes. Su punto de partida era el hecho que, una vez tras otra, se encontraba que desde que un nuevo miembro se incorporaba a su equipo hasta que estaba listo para valerse por si mismo pasaban al menos dos años en los que debía ser formado. Desde su punto de vista, este problema venía dado por algunas costumbres o prácticas de programación que se enseñan en las escuelas técnicas o de ingenierías, que si bien sobre el papel o en una gran cantidad de proyectos funcionan, para la programación de  motores de videojuegos deben ser corregidas. El meollo del asunto según su punto de vista es que a menudo tendemos a sobrecomplicar las cosas bajo la justificación de la escalabilidad. Se nos plantea un problema y enseguida hacemos API’s o capas de abstracción que permitan resolver ese problema…...