El enfoque de Chaos Goblin para el desarrollo de juegos en Unity

Una de las sensaciones más paralizantes al iniciar cualquier proyecto de desarrollo de juegos es la que se siente justo después de haber terminado el diseño inicial del juego, ya sean algunas ideas anotadas en servilletas para un game jam o el diseño tradicional de 10 páginas. documento.

Porque después de que hayas decidido que tu juego será un ROGUELITE-RTS-MMORPG, en realidad tienes que construirlo, ¿ves?

Y digamos que decidiste que lo primero que vas a construir es la parte de estrategia en tiempo real. Entonces, anota la historia del usuario, las tareas o cualquier unidad de trabajo que uses para organizarte.

Entonces digamos que el primer elemento de esa lista es "Implementar mapa desplazable".

¡Y ups! Nunca ha implementado un mapa desplazable. Pero no te molestes, Google al rescate, ¿verdad?

Pero, ¿qué sucede si la solución que encuentra en línea no hace exactamente lo que necesita? ¿O la solución que encuentras tiene 15 años? ¿O hay muchos comentarios debajo que dicen cuán mala es la solución, pero ninguno especifica una mejor [^0]?

Por lo tanto, no puede encontrar una referencia de código para lo que sea que esté tratando de construir. ¿Qué debe hacer un desarrollador de juegos?

La respuesta es entrar en el modo Chaos Goblin.

Entrando en el Modo Goblin del Caos

Para aquellos de ustedes que no están familiarizados con los goblins, son una raza que aparece a menudo en varias obras de fantasía, típicamente representados como un primo más pequeño del orco o hobgoblin más serio. En algunas otras propiedades, se los describe como mecánicamente competentes de una manera muy específica. Y de esa manera no es confiable. Lo que significa que las cosas que hacen los goblins a veces funcionan, no tanto porque estén bien diseñadas o hechas, sino más bien por puro ingenio y terquedad.

Esa es la esencia del enfoque de Chaos Goblin para el desarrollo de juegos. Ahora, estoy seguro de que estoy empezando a perderte un poco aquí, así que déjame volver y resumir la esencia de Chaos Goblin:

Para ilustrar mejor este punto, déjame contarte sobre Presidential Metro Head de Fallout 3 (puedes leer la historia completa aquí ). La esencia de esto es que durante una escena en el juego donde el jugador cree que está parado dentro de un metro, el casco del jugador en realidad ha sido reemplazado con el modelo de un vagón de metro, y es el propio modelo del jugador el que se está moviendo en un pista predeterminada.

Algunos jugadores pueden leer esto y pensar que los desarrolladores estaban siendo flojos. Pero la verdad del asunto es que los desarrolladores hacen este tipo de cosas todo el tiempo.

Y es precisamente ese tipo de prácticas las que forman los principios del modo Chaos Goblin, que son los siguientes.

Lo que el jugador no sabe no puede hacerle daño.

Digamos que en una parte de tu juego, el jugador está parado dentro de la torre de un castillo y está disparando flechas a un dragón que está volando afuera. De vez en cuando, el dragón se acerca y empuja su cabeza a través de la ventana para tratar de morder al jugador.

Ahora, en lo que respecta al jugador, el dragón está volando por ahí. Pero nosotros, como desarrolladores de juegos, podríamos haber empleado algunos trucos para ayudar con esta ilusión y optimizar la situación.

Algunas cosas que se podrían hacer son las siguientes:

• Usa diferentes modelos dependiendo de qué tan lejos esté el dragón del jugador. El jugador solo puede ver los detalles del dragón cuando está cerca, entonces, ¿por qué no reemplazar el modelo 3D del dragón con algo que tenga menos detalles, pero que también ocupe menos espacio en la memoria?

  
  

• Apaga el dragón cuando el jugador no lo esté mirando. Al realizar un seguimiento de dónde mira el jugador, podemos activar y desactivar selectivamente los modelos 3D para ahorrar en el renderizado.

  
  

• Evita que el jugador vea el trabajo sin terminar. Digamos que, por la razón que sea, el arte del entorno exterior de la torre está inacabado. Entonces, si el jugador alguna vez sale al borde de la ventana, no verá nada. Para ayudar con esto, los diseñadores del juego decidieron que la repisa de la ventana se convertiría en un punto de muerte instantáneo. Entonces, cuando el jugador se para en la repisa, se reproducirá un sonido de 3 segundos del rugido de un dragón y la pantalla del jugador comenzará a oscurecerse. Una vez que termina el sonido de 3 segundos, reproducimos una animación rápida del dragón que se come al jugador (quizás reutilizando una que ya teníamos). En lo que respecta al jugador, la cornisa es solo un lugar donde el dragón puede eliminarlo; no necesitan saber que se hizo para evitar que vean el trabajo sin terminar.

  
  

• Tal vez cuando el dragón asoma la cabeza por la ventana, reemplazamos el modelo de dragón completo con un modelo de cabeza más pequeño pero más detallado. Esto nos permitiría liberar memoria de un modelo que no estamos usando y nos permitiría brindarle al jugador una experiencia mejorada.

  
  

Si ha estado en la industria de los juegos durante algún tiempo, probablemente reconozca lo anterior como prácticas estándar, pero hubo un momento en que estas técnicas se consideraban trucos inteligentes y bastante innovadores.

Ahora depende de usted encontrar nuevas formas de engañar a sus jugadores para que piensen que hay mucho más en lo que están viendo.

La mejor solución es la que está funcionando actualmente.

Muchos desarrolladores de juegos se atascan porque intentan encontrar soluciones que cubran todos los escenarios futuros posibles. Esta actitud puede ser valiosa en las circunstancias adecuadas, pero cuando estás en modo Chaos Goblin, el objetivo es hacer que algo funcione lo más rápido posible.

Un apéndice a esto:

Un prototipo defectuoso es más valioso que cualquier obra maestra sin terminar

Similar al punto anterior, muchos desarrolladores se congelan cuando intentan implementar una función porque intentan optimizar demasiado pronto.

La optimización debe dejarse hasta que el proyecto tenga la necesidad de ejecutarse en máquinas fuera del control de los desarrolladores[^1].

¿Cuánto necesito saber antes de hacer X? La respuesta es, cualquier cantidad de conocimiento que tengas en este momento es suficiente.

Este es otro obstáculo con el que se encuentran muchos desarrolladores de juegos principiantes. Pospondrán la implementación de una función para poder tomar solo un curso más, un tutorial en línea más, ver un video más y luego estarán listos para implementar su juego.

Soy particularmente culpable de esto y sé lo insidioso que puede ser.

Para darte un ejemplo más concreto, supongamos que te han encargado programar un juego de Pong desde cero.

Dependiendo de lo que sepa o no sepa, podría haber diferentes enfoques para esto:

• Si está familiarizado con el sistema de física de Unity, es un esfuerzo relativamente simple. Puedes usar un par de cuerpos rígidos y colisionadores, aplicar fuerzas y velocidades, usar un material físico para el rebote de la pelota y eso es todo. Un clon básico de Pong.

  
  

• Pero digamos que no está familiarizado con el sistema de colisión de Unity, solo sabe cómo usar los componentes de transformación de Unity, por lo que todo lo que puede obtener es la posición y el tamaño de un objeto.

  • ¡Pero! Eso es suficiente para implementar Pong, puede escribir un script que realice un seguimiento de la posición y el tamaño de la pelota y lo compare con la posición y el tamaño de la paleta para verificar si hay una colisión.

    
    

• O tal vez ni siquiera conoce Unity, todo lo que sabe es C++ y cómo imprimir en la consola.

  • ¡Pero eso también es suficiente! Puede usar trucos de terminal para imprimir filas y columnas de símbolos para representar la pelota, las paletas y el área de juego. Eso, junto con el concepto de un bucle de juego, es suficiente para programar una interfaz de usuario refrescante que responda a la entrada.

    
    

• ¿O ni siquiera tiene experiencia en informática o no tomó una clase de C ++, y solo sabe Javascript?

  • ¡Ningún problema! Puede usar Phaser , que usa JS como lenguaje principal y viene con componentes físicos y de representación.

    
    

• ¿Ni siquiera puedes programar? Absolutamente ningún problema.

  • Gamemaker es un motor de juego comercial con una versión gratuita y tiene una opción sin código.
  • GDevelop es un motor de juego gratuito de código abierto con una opción sin código también.

Has descubierto a dónde voy con esto, ¿verdad?

No hay proyectos fallidos, solo montones de chatarra esperando ser reutilizados

La mayoría de los desarrolladores de juegos suelen tener uno o dos (o 10.000) proyectos abandonados por ahí. No tiene sentido desperdiciarlos. Si hay un código allí como un sistema de pausa, reutilícelo. No tiene sentido volver a escribir lo mismo. Incluso si recuerda exactamente cómo escribirlo, cópielo; si es difícil adaptarse, entonces reitere para que sea más fácil la próxima vez.

Tal vez incluso tenga un proyecto de taller[^2] que tenga varios fragmentos de código que pueda reutilizar.

¿Ves algo brillante? Toma una cosa brillante

¿Necesita un sistema de diálogo? Busque uno de código abierto y reutilícelo. ¿Cumple con todos tus requisitos? ¿No? ¿Cumple con más del 50%? ¿Sí? Entonces vale la pena usar eso en lugar de crear uno nuevo desde cero.

¿Sistema de inventario? Encuentra un juego de código abierto en itch.io y adopta su sistema.

¿Necesitas una cámara en primera persona? Utilice un activo precompilado para manejarlo[^3].

Hay muchos desarrolladores de juegos brillantes, sin duda más competentes que tú o yo.

A menos que tenga una razón particular, todo debe considerarse candidato para usar un sistema preconstruido. Sin embargo, existen excepciones sensatas, como: No utilices código que simplemente has copiado y pegado como la columna vertebral de tu juego (al menos asegúrate de que lo entiendes, limpias y comentas), y evita usar un módulo que tiene una década de antigüedad, con su autor presumiblemente descansando en algún lugar tropical, bebiendo Mai Tais con Elvis, Tupac y Marilyn Monroe en un paraíso libre de paparazzi.

En caso de duda, copie

Si no estás seguro de implementar una función, encuentra un juego que haya hecho algo similar a lo que quieres e imítalo.

Por "copiar" me refiero a los aspectos de diseño como el manejo del control, las vistas de la cámara y la mecánica, en lugar del estilo artístico, la historia o los personajes.

Por ejemplo, ¿qué tan rápido debe ser el desplazamiento en nuestro ahora olvidado hipotético ROGUELIKE-RTS-MMORPG?

En lugar de adivinar, podrías ver cómo lo ha logrado otro RTS. Suponga que observa Age Of Empires II (un RTS históricamente significativo) y descubre que permite a los usuarios controlar la velocidad del movimiento del cursor. Incluso puede colocar su juego junto con AoEII y ajustar el cursor hasta que se sienta equivalente. Se sorprendería de cuántos desarrolladores confían en soluciones simples y de baja tecnología como esta para lograr sus objetivos.

pensamientos de despedida

Entonces, ¿qué deberías hacer después de haber concluido tus travesuras de Chaos Goblin? Bueno, tómate un respiro, prepárate una taza y regresa a tu código más tarde.

Después de dejar que su código descanse (bajo una toalla húmeda si el clima es demasiado seco), debe arreglarlo un poco y compartirlo. ¡Sí! Compártalo, idealmente con un desarrollador sénior, un colega, un compañero de estudios o, en el peor de los casos, con una comunidad en línea[^4].

¿Por qué lo compartes? Porque ser un Chaos Goblin no se trata de crear algo duradero u óptimo; se trata de construir algo que FUNCIONE. No tiene que funcionar perfectamente o verse hermoso, solo tiene que FUNCIONAR. Este tipo de desarrollo produce resultados, pero los resultados rara vez están inmediatamente listos para la producción. Por lo tanto, consultar con alguien para proporcionar retroalimentación es de vital importancia.

Dependiendo de la etapa de su proyecto, es posible que no tenga tiempo para implementar los comentarios de esta persona de inmediato. Si ese es el caso, al menos debería documentar esos comentarios en el código[^5].

¡Y eso es! Ahora posee la técnica número 1 utilizada por los desarrolladores de juegos profesionales en todo el mundo para resolver problemas.

Sugeriría que es hora de una segunda taza, ¿no?

notas

[^0] - Este es un fenómeno sorprendentemente común y se denomina "La parábola de Denver". Para obtener más información, consulte el siguiente artículo académico .

[^1] - Esto es un poco una generalización y, como la mayoría de las generalizaciones, puede que no sea tan útil como un análisis exhaustivo de los requisitos de su proyecto. Sin embargo, es una buena regla general posponer la optimización hasta que sea realmente necesaria. En estos días, optimizar los videojuegos es considerablemente menos desalentador de lo que solía ser. Algunas empresas de motores de juegos, como Unity, incluso podrían ofrecerte asistencia con consultas gratuitas. Después de todo, lo mejor para ellos es que inicies tu juego con éxito.

[^2] - El taller es uno de los katas o prácticas que utilizo para aumentar mi comprensión de Unity. Puedes leer más sobre esto y otras técnicas aquí .

[^3] - Puede encontrar un paquete de controlador FPS realmente bueno junto con otras herramientas útiles en este artículo

[^4] - Esto conlleva la advertencia de que aproximadamente el 95 % de los comentarios que recibirá en línea pueden ser inútiles, estar incompletos, desactualizados o reflejar las creencias profundamente personales del autor, sean las que sean. Por lo tanto, siempre aborde tales comentarios con cierto grado de escepticismo. Trate de buscar comentarios útiles, ignore o elimine el resto, y haga un esfuerzo genuino para encontrar a alguien con quien pueda compartir su código.

[^5] - Diferentes equipos mantienen diferentes normas con respecto a dónde mantienen la documentación de su código, y usted debe cumplir con eso. Sin embargo, en general, recomendaría que la documentación del código resida junto al código en sí. Si eso no es factible, considere usar un submódulo git o su equivalente en su sistema de control de versiones de código elegido. Si la documentación no puede estar en el repositorio principal, al menos debería residir en el submódulo de git.