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.
