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…...

Ron Gilbert en el Gamelab

Recientemente, del 29 de Junio al 1 de Julio, se celebró en Barcelona el Gamelab, el congreso internacional del videojuego y el ocio interactivo. Si bien se trata de un encuentro a la medida de todo amante de los videojuegos, resulta especialmente interesante para los nuevos desarrolladores, ya sea tanto como expositor para sus creaciones como para aprender de los consejos de los expertos a través de conferencias y talleres. Como cada año, los asistentes pudimos disfrutar de un seguido de ponentes destacados. Entre ellos, se encontraba Ron Gilbert, creador aventuras gráficas en LucasArts, entre ellas grandes éxitos todavía vivos en el imaginario popular como Maniac Mansion o la saga Monkey Island. Por algo de aquí sale el nombre de los 3HM. En este caso, no se trató tanto de una conferencia en toda regla como de una charla de café con público, en la que poder explicar vivencias y anécdotas. El punto de partida de la charla fue su percepción intemporal de algunas de sus aventuras gráficas. El poderse sorprender de ver jugar a un niño de cinco años que todavía no sabe leer a un Monkey Island y ver que le tenía totalmente fascinado. Ligando este hecho con su experiencia en Humongous Entertainment, fundada por él para crear  programas educativos, llegaba rápido a una primera conclusión: que los niños pequeños son grandes evaluadores de videojuegos. Por una parte, porque (como los borrachos), no mienten. Son directos y sutiles como una maceta que cae sobre tu en tu cabeza. Y por otra parte, porque a ellos no les puedes distraer con cuestiones tecnológicas (número de polígonos, framerates, etc)....