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

49

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.

Refinamiento vs. exploración
(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.

Jonas Byström
fuente
1
Esa es una muy buena foto. ¿De dónde es?
Superbest
Creo que lo que estás haciendo se llama formalmente "prueba de unidad", especialmente si quieres modificar una pequeña parte del juego a la vez. Desafortunadamente, los juegos son difíciles de probar en la unidad, porque es difícil aislar componentes y es difícil automatizar la prueba en sí (para que pueda decidir si pasa / falla). Sin embargo, leer acerca de las estrategias de pruebas unitarias puede darle ideas útiles.
Superbest
55
@ Superbest: conozco las pruebas unitarias de adentro hacia afuera, y no se puede comparar la exploración de comportamiento con las pruebas unitarias. Al explorar el comportamiento, necesita cargar la mayor parte de su motor de juego, junto con activos relevantes. Las pruebas unitarias son solo cuando sabes a dónde vas; En este caso nadie lo sabe. Es por eso que es "exploración", no "refinamiento". Foto del blog de Intercom .
Jonas Byström
Cuando está probando en modo de depuración, puede cambiar su código, cuando lo pausa (al menos en Visual Studio). siempre y cuando no cambie demasiado (encabezados de función, etc.), puede cargarlo en su juego en pausa con solo un breve tiempo de compilación
Tobias B
@TobiasB: en la práctica, desafortunadamente, me pareció inútil. Especialmente porque normalmente tienes tu mecánica de juego distribuida en guiones, objetos de juego ya instanciados, activos, etc. Ni siquiera estoy seguro de que el Visual Express gratuito lo admita, ¡en realidad no lo he usado en 14 años! :)
Jonas Byström

Respuestas:

30

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.

Trevor Powell
fuente
3
¿Podrías dar más detalles sobre tus modos de juego de "prueba"? ¿Creas una porción del juego aquí y allá para cada parte cada vez que quieras iterar sobre ella? ¿Cuánto tiempo necesitas para configurar tu "sector"? ¿Qué queda afuera y cómo? ¿Tiene una especie de funcionalidad de "guardar juego" y "cargar juego" para este tipo de cosas, o es menos genérico?
Jonas Byström
2
@ JonasByström No sé sobre él, pero cuando tengo un buen control sobre los estados de mi juego, a menudo puedo tener versiones alternativas de "Depuración" (a menudo IF DEBUGdirectivas del compilador literal ) que van directamente a mi estado de "prueba" (omitiendo el menú del juego etc.), que es solo un área de juego básica con los activos que estoy probando en ese momento. Así que básicamente compilo un ejecutable alternativo que carga automáticamente un nivel muy reducido (menos recursos para cargar + sin perder el tiempo con el menú del juego cada vez).
Superbest
@ JonasByström Divido mis juegos en "modos". Básicamente es solo una gran máquina de estados. Por lo tanto, normalmente tendré un modo "Pantalla de título", un modo "En juego", un modo "Desplazamiento de créditos", etc. Son como juegos incrustados dentro del ejecutable. Mis modos de "prueba" son cosas como "UITest", que simplemente cargará y dibujará una parte de la interfaz de usuario, sin cargar ningún otro contenido del juego. O "RenderTest", que cargará y dibujará algún objeto en particular, sin cargar nada más.
Trevor Powell el
@ JonasByström Cuando necesito crear un nuevo modo de prueba, normalmente me llevará unos minutos escribir el código que configura la cosa particular que quiero probar y las dependencias que pueda tener. O, alternativamente, a menudo puedo adaptar un modo de prueba existente en unos pocos segundos (por ejemplo. En general, modificaré mi modo UITest existente para cargar una parte diferente de la interfaz de usuario, en lugar de crear uno nuevo). Sin embargo, en realidad no importa mucho cuánto demore la configuración; El punto es que una vez que está configurado, puedo iterar a velocidades absurdamente rápidas, lo que me mantiene productivo durante ese tiempo de iteración.
Trevor Powell
1
@ JonasByström También vale la pena señalar que "comprar una computadora más rápida" es una solución completamente legal a la pregunta "¿Cómo puedo reducir mi tiempo de iteración?" Y a menudo puede ser la solución más barata, en comparación con invertir su tiempo en implementar plataformas de prueba especiales. Reducir el tiempo de iteración es una inversión que invierte mucho tiempo / dinero / esfuerzo por adelantado, pero que paga muchos dividendos en el futuro.
Trevor Powell el
20

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.
Anko
fuente
1
Lua no parece ser compatible con el código de hotswapping. ¿Eso significa que necesitas reiniciar tu juego / prototipo para probar tus cambios?
Jonas Byström
66
El código Lua de Hotswapping es definitivamente posible.
Josh
1
@ JonasByström Es posible, pero solo en el entorno adecuado. Si no puede encontrar uno, escriba uno, el código fuente de Lua está escrito en C, por lo que es portátil para cualquier cosa que acepte llamadas de función de estilo C. Mézclelo con OpenGL, SDL 2 o alguna otra biblioteca de envoltura de gráficos / hardware y construya un IDE de intercambio dinámico.
Pharap
2
@ JonasByström He aquí cómo hacerlo con soporte IDE y sin él .
Anko
2
@ JonasByström: ... excepto volver a la luna, aparentemente. :(
Mason Wheeler
11

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.

No importa
fuente
Estoy pensando que las características son diferentes de la exploración del comportamiento. Quiero explorar "la sensación". Las características son más bien hermosas para mí: no esenciales y no están relacionadas con lo divertido que será el juego. Minecraft, Candy Crush, Tetris y juegos similares demuestran que en mi humilde opinión.
Jonas Byström
@Jonas Byström Para aclarar: aquí por "características" me refiero a cambios esenciales en el juego. Es decir, NO es una representación hermosa, sino algo así como "agregar una forma de crear bloques" o "agregar mobs que atacan y matan al jugador" cuando se crea un prototipo de un Minecraft.
importa
1
No se puede exagerar la importancia de su segundo punto, "dejar ir las funciones". Muchas fases exploratorias fallan por no decir "no" a esa característica fallida que tardó 2 semanas en implementarse.
Kostas
Una nota sobre el punto 4. Creo que la clave para esto es entender qué necesitará cambiar rápidamente en el código. Asegúrese de exponer los valores que sabe que va a querer ajustar. Deje enterradas otras secciones del código si sabe que no afectan tanto el juego y expongalas más tarde cuando sea necesario. Tienes que resolver esto rápidamente, pero si puedes tratar de diseñar tu arquitectura desde el primer momento, de modo que las cosas del "diseño del juego" estén orientadas hacia el frente y estén limpias cuando sea posible, el resto puede ser desordenado.
sydan
1
@sydan, la desafortunada verdad es que su idea de qué código es "frontal" está mal. Quiero decir, SIEMPRE resulta que algo que nunca deberías cambiar es en realidad algo muy dinámico. Al crear prototipos, es mejor que esté preparado para cambiar literalmente cada aspecto y hacerlo rápido.
importa
5

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.

Kostas
fuente
1
La foto en papel y el "banco de banco" son excelentes consejos; y sí, las listas también me ayudan. "Identifique sus tres prioridades principales. Deseche los números dos y tres". :)
Jonas Byström
4

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 .

Don Kirkby
fuente
1
He visto el video antes, pero lo olvidé. Hm. La interacción inmediata es realmente algo por lo que luchar; Trataré de seguir tu consejo. Buen trabajo en el interesante plugin Live Coding por cierto!
Jonas Byström
2

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.

Jonas Byström
fuente
1

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.

helena4
fuente
La creación de prototipos solo es necesaria si está creando algo nuevo, eso es un hecho. La falta de herramientas es como la falta de lápiz y papel, y seguro que puedes dibujar en la arena, pero es ineficiente. Construí Trabant para evitar tener que usar GIF + JS o Scratch .
Jonas Byström