Al crear prototipos, ¿cómo puedo explorar más fácilmente el comportamiento del juego?

Yo mismo construyo juegos independientes, pero generalmente me quedo sin energía una vez que llevo un juego desarrollado recientemente a un nivel en el que es posible jugar con el comportamiento, por lo que me conforma con el refinamiento en lugar de la exploración. Con pésimos resultados.

^{(imagen del blog de Intercom )}

Por ejemplo, encuentro que los ciclos de iteración para modificar el comportamiento (es decir, vincular y reiniciar una aplicación C ++) son tan largos que matan toda creatividad. Estoy construyendo una herramienta para lidiar con esto.

¿Qué otras formas existen para explorar rápidamente el comportamiento del juego? Estoy interesado en las metodologías utilizadas por los desarrolladores independientes, así como por las grandes empresas.

Como has notado, cuando trabajas en la mecánica del juego, la velocidad de iteración es crítica. Cuanto más tiempo pase entre pensar en una modificación y poder probar con esa modificación, menos productivo será y más distraído se volverá. Como resultado, definitivamente desea administrar su tiempo de iteración.

Para mí, encuentro que mi productividad realmente comienza a disminuir cuando el tiempo para probar un cambio simple supera los cinco segundos. Entonces, cuando experimentas para perfeccionar la forma en que se siente el juego, uno de tus objetivos es descubrir "cómo puedo hacer un cambio y luego jugar usando ese cambio en menos de cinco segundos". Realmente no importa cómo lo hagas, siempre que puedas mantener ese tiempo de iteración por debajo de ese nivel.

Muchos motores modernos grandes (Unity, Unreal, etc.) tienden a hacer esto poniendo su editor dentro del motor del juego, para que puedas hacer la mayoría de las modificaciones en vivo, sin tener que reiniciar el juego. Los motores / juegos más pequeños generalmente enfocan el trabajo en la otra dirección; haz que el juego se compile y se inicie tan rápido que no importa si tienes que reiniciar el juego para cada cambio; aún estará dentro y probando antes de que finalice ese período de cinco segundos.

En mi proyecto actual, me lleva unos diez segundos hacer una pequeña recompilación, vincular, iniciar el juego y luego alcanzar el juego (la mayor parte de eso genera geometría mundial representable al cargar un juego guardado). Y eso es demasiado largo. Así que he creado modos de juego "de prueba" separados que me permiten probar diferentes partes del juego sin cargar todos los activos reales del juego, para poder entrar y salir mucho, mucho más rápido; típicamente en aproximadamente dos o tres segundos. Si quiero probar alguna interfaz de usuario, puedo hacerlo sin cargar en el juego real. Si quiero probar el renderizado, tengo otro modo donde puedo probarlo, nuevamente sin cargar todo el sistema del juego.

He visto a otras personas que han abordado el problema colocando la lógica del juego en una DLL y permitiendo que el ejecutable del juego que ya está en la memoria vuelva a cargar la DLL mientras el juego se está ejecutando, para que pueda reconstruir la DLL y volver a cargarla dentro de un ejecutable ya cargado, por lo que no necesita volver a cargar / reconstruir los activos artísticos de su juego. Esto me parece una locura, pero lo he visto hecho.

Mucho más simple que eso sería especificar los comportamientos y / o la configuración del juego en scripts o archivos de datos, y proporcionar una manera de hacer que su sistema vuelva a cargar esos archivos, ya sea a pedido, o tal vez simplemente mirándolos para modificaciones, sin necesidad de cerrar el juego está inactivo, vuelve a vincularlo y luego vuelve a iniciarlo.

Hay muchos enfoques. Elige lo que funcione mejor para ti. Pero una de las claves para el perfeccionamiento exitoso de la mecánica del juego es la iteración extremadamente rápida. Si no tienes eso, casi no importa qué más hagas.

Para realizar un buen prototipo, reduzca el costo de probar ideas.

Mi flujo de trabajo está ajustado para juegos pequeños, pero he encontrado útiles estas cosas:

• Tecnología amigable con los prototipos  Me ha resultado útil usar un lenguaje y marco de programación dinámico, como Lua ( LÖVE es bueno para 2D), JavaScript o Lisp / Scheme, donde hacer que el programa haga algo requiere pulsaciones de teclas mínimas, incluso a un costo de todo lo demás. Una vez que sepa lo que quiere y quiera refinarlo, optimizarlo o transferirlo a otro motor.
• Control de versiones  Mantenga los prototipos en un repositorio de revisión controlada . Se ramifica temprano, se ramifica a menudo. Esto te mantiene cómodo probando cosas sin preocuparte de perder u olvidar algo. ( Git tiene el modelo de ramificación más barato).
• Automatización de compilación  Asegúrese de que debe hacer lo menos posible para que realmente funcione. En mi opinión, incluso tener que presionar un botón es demasiado: generalmente tengo Makefileun make watchobjetivo que se ejecuta inotifywaiten un bucle, reaccionando a los cambios del archivo compilando / ejecutando automáticamente el juego. En un lenguaje interpretado o compilado JIT , esto es instantáneo.

Como desarrollador centrado principalmente en la creación de prototipos, he aquí algunos consejos de mi experiencia.

1. Use un motor que le permita realizar cambios RÁPIDAMENTE. Esto incluye cosas como "No esperar la compilación", sino también "cambiar las cosas en tiempo de ejecución", "facilidad de depuración", "disponibilidad de activos de prueba", etc. Personalmente, amo Unity3D, pero no es la mejor herramienta que existe. La mejor herramienta depende del juego: por ejemplo, Unreal Engine compila el código mucho más lento que Unity3D, pero puede iniciar rápidamente varios clientes conectados. Para un juego en red, esto a menudo compensa los costos de compilación. Considere también la familiaridad. Si eres un genio con C ++, incluso el mejor motor de Javascript no servirá de mucho, y viceversa. No pierdas el tiempo luchando con tecnología desconocida (quiero decir, aprende otros idiomas / marcos, pero no al mismo tiempo que haces prototipos importantes).
2. Aprenda a desechar las funciones existentes sin piedad. Aferrarse a cosas que ya implementó es un anatema para la creación exitosa de prototipos, pero dejar su trabajo es difícil.
3. Si no trabaja con un diseñador de juegos, ponga una línea clara entre "usar un sombrero de programador" y "usar un sombrero de diseñador". Agregar una nueva función de juego genial parece muy tentador, pero no lo hagas cuando estés en la posición de diseñador. En lugar de eso, intenta crear un juego divertido (preferiblemente múltiples variantes) con lo que tienes; haga una lista de características que ayudarían y luego implemente (algunas de ellas).
4. La creación rápida de prototipos implica el equilibrio entre dos opuestos. Desea hacer las cosas lo más rápido posible, por lo que escribe un código incorrecto. Pero desea cambiar las cosas tanto como sea posible, por lo que debe escribir un buen código. Aprende a equilibrar estos dos. Lo siento, no puedo pensar en ningún consejo concreto sobre cómo hacer esto, pero al menos sé consciente de este problema (-8

Mira cuánto tiempo requiere tu creación de prototipos. En mi experiencia, quieres tener una versión jugable de cualquier cosa en dos días como máximo, comenzando desde cero; y desea probar una o dos funciones nuevas todos los días. Si no cumple con estos objetivos, busque formas de ser más rápido.

Uno puede dividir el desarrollo del juego entre estas cuatro fases:

• creación de prototipos
• refinamiento del juego
• desarrollo
• refinamiento del rendimiento

La exploración del juego creo que ocurre principalmente en la fase de creación de prototipos y estos son algunos consejos que trato de seguir:

• Comience a diseñar con un prototipo de papel. Una vez que tengas una idea clara de lo que podría ser el juego, comienza a codificarlo para que realmente puedas sentir las interacciones. Tal vez esto sea inútil para los juegos en 3D, pero personalmente me ha ayudado mucho en el pasado.

• Codifique sabiendo que tirará su código una vez que haya terminado. Esto te permitirá ser liberal cuando se trata de qué motor de juego elegir.

• Los ciclos rápidos de iteración son importantes (como otros han señalado anteriormente). Elija un motor de juego basado en su capacidad de mostrarle rápidamente lo que codificó. Tampoco tiene que preocuparse por el rendimiento o la fidelidad gráfica en esta fase.

• Limite su alcance. Si el juego real es 2D (juego de estrategia habitual, JRPG), prototipo en 2D. En esta fase solo te interesan los comentarios sobre el juego .

• No pierdas el tiempo puliendo o buscando activos. Garabatea algo en un papel, toma una foto, córtalo en Photoshop, quizás coloréalo y úsalo como un sprite. Encienda su micrófono y diga "banco de banco". Pon dos cubos y una esfera juntos y tendrás un robot. Siempre ten en cuenta que explorar tus posibilidades de juego es tu primera y única prioridad.

Después de decidirse por un prototipo que sea divertido, comience a refinarlo. No creo que haya una razón para cambiar de tecnología aún, excepto si hay un elemento de juego que lo necesita.

Más adelante en la fase de desarrollo, mantendrás el prototipo refinado a la mano mientras desarrollas un juego nuevo, mucho mejor, con mucho mejor sonido y mucho mejor. Aquí tienes que elegir el motor de juego real para usar.

Al final, toma lo que tienes y ajústalo para usar menos recursos.

La mayor parte de lo que describo anteriormente es de conocimiento común, pero ponerlo en una lista, compartimentar todo el proceso de desarrollo, me ayuda a poner cada paso en perspectiva. Espero que te ayude a ti también.

Estoy de acuerdo con la respuesta de Trevor Powell de que la velocidad de iteración es crítica para que mantengas el estado de ánimo creativo en lugar de solo pulir. Una gran fuente de inspiración para mí es la charla de Bret Victor, "Inventing on Principle" . Desafortunadamente, es difícil encontrar herramientas reales a ese nivel. Intenté construir uno para el desarrollo de Python que me permite ejecutar mi código Python mientras lo escribo. Se llama Live Coding en Python .

Construí una herramienta de creación de prototipos llamada Trabant que:

• es 3D y mecánica de juego SOLAMENTE (sin interfaz de usuario, sin texto, nada);
• requiere muy poco código y ningún activo para construir un prototipo;
• Los modelos 3D se crean en código utilizando el arte ASCII ;
• permite iteraciones por debajo del segundo;
• tiene soporte de simulación de cuerpo rígido;
• funciona en Windows, Mac, Linux e iOS;
• utiliza un lenguaje de uso general bien conocido, Python;
• tiene un IDE para Windows e iOS.

Construí 30 prototipos de prueba para verificar lo anterior.

Como Trevor Powell enfatizó, las iteraciones deben ser <5 segundos, y encuentro <1s iteraciones casi cinco veces mejores.:)

Anko mencionó que usar un lenguaje dinámico es una buena idea, elegí Python ya que es uno de los más utilizados . Con respecto a la automatización de compilación, las pruebas en Trabant son tan rápidas como presionar F5 en el IDE (o F6 para probarlo en su iPad), y dado que no hay un paso de compilación involucrado, no es más instantáneo que esto.

Desechable código fue uno de de de Nevermind comida para llevar . Estoy totalmente de acuerdo, y Trabant lo hace cumplir.

Además de la velocidad de iteración de Trevor Powell, que es realmente importante, aquí hay algunas otras consideraciones útiles:

Es como un buen código ...

Un montón de IFs allí.

Cuanto más sólido es el concepto, menos necesita jugar. Si sabe qué es lo que está tratando de hacer, la creación de prototipos se convierte en qué poner y cómo organizar las cosas en relación con el pilar central (lo principal).

Si está comenzando como muchos otros, no está muy seguro de lo que quiere hacer, se dirige en una dirección y explora mucho en el camino de la imagen que mostró.

De cualquier manera, el compromiso con una tecnología es irrelevante si lo que está buscando se puede simular sin mucha profundidad: prototipo en lo que quiera / pueda.

No malgastes ni un segundo extra en recursos. Descarga todo de internet. Propietario o no. Está buscando tener una idea de su concepto en el trabajo: a menos que los gráficos sean su característica principal, nadie lo demandará por experimentar con los sonidos, las texturas y todo lo demás, todavía no lo está poniendo en el estante de la tienda. A menos que ya esté financiado, convencer a la gente de que el concepto vale la pena es lo que le va a dar el dinero para obtener los recursos que desea. He visto a gente de estudio de juegos presentar conceptos de juegos con versiones modificadas de juegos propietarios a los que no tienen derechos.

Es como si estuvieras construyendo un modelo a escala. Si bien es increíble tener una réplica de vida en miniatura de lo que quieres. A veces es suficiente para cortar revistas, hacer manualidades y pegar las piezas. Todo el mundo con una mancha de imaginación no va a asumir que realmente construirás el rascacielos con el mismo cartón con el que mostraste el modelo a escala. Y en las industrias creativas, es más preferible trabajar con personas con algo de imaginación. Si no pueden mirar más allá de algunos problemas preliminares para ver el potencial detrás de un concepto completo, rara vez apreciarán un producto. Ninguna apreciación significa que están menos dispuestos a comprometerse y eso es una espiral descendente. Es la diferencia entre configurar la actitud de tus hijos para conquistar el mundo y decir "No puedes ni atarte los zapatos correctamente, pequeño imbécil,

Lo que sea que esté haciendo, siempre recuerde que la actitud sola es más que suficiente para arruinar absolutamente cualquier cosa, independientemente de su potencial tecnológico o económico.

Una vez realicé un prototipo de un juego usando exclusivamente imágenes gif y dándoles algo que ver con JavaScript. No es deslumbrante, pero sirvió para mostrar lo que quería mostrar. No importa si luego lo desarrollas exclusivamente para Xbox.

Si su idea es más compleja que un simple prototipo, entonces tendrá que investigar sobre la tecnología que usará, ya que el prototipo será el andamiaje para lo último (simplemente porque se invierte mucho en y no se puede tirar a la ligera), si lo apruebas obviamente.