Ajustes y configuraciones: modificación y persistencia de la variable de tiempo de ejecución

La mayoría de las empresas tienen un editor o un sistema de control variable para ajustar cosas en los juegos, pero ¿hay alguna solución de middleware para este problema? He escrito dos de estos sistemas en el pasado y trabajé con cinco, tal vez seis diferentes, pero ninguno de ellos estaba listo.

Cada una de estas soluciones de origen tenía problemas, que iban desde tener que seguir buscando valores hasta no poder guardar el estado actual de las variables.

¿Hay alguna biblioteca / aplicación de control de configuración / tiempo de ejecución maduro?

Generalmente codifico en C ++, pero creo que un editor maduro de configuraciones / variables probablemente estaría basado en sockets (y, por lo tanto, agnóstico al lenguaje en cierta medida) ya que todo el hardware de desarrollo actual, aparte de las cosas de Nintendo, proporciona un mecanismo para hablar con los servidores. La implementación del código también debería ser bastante simple (me gusta el artículo hot_var / TweakableConstants compartido por Oskar, pero no es un paquete)

Me gusta lo que Noel propuso en su blog. Un tweaker variable basado en telnet . Al usar telnet pudo usar cualquier cliente de telnet para editar las variables. Más tarde construyeron una interfaz gráfica de usuario en torno al protocolo. Parece lo suficientemente simple, que probablemente no valga la pena una biblioteca de middleware, pero mirar su código podría ser útil.

Sin embargo, no estoy de acuerdo con su sentimiento anti-Lua. Una consola remota de Lua parece increíble.

Tal vez la idea de las constantes ajustables se ajuste a sus necesidades. De hecho, es tan útil que pensaría que necesitaría una solución compleja para tener un control efectivo de las variables de tiempo de ejecución, pero en realidad la implementación es casi demasiado simple. La discusión original de esta técnica también es una lectura interesante.

Ejemplo:

glClearColor( H(1.0f), H(1.0f), H(1.0f), H(1.0f) );

La Hmacro se expande a algo así HotValue(x, __FILE__, __LINE__, __COUNTER__). Esto registra el valor en algún registro global. Luego tenga una función como RefreshHotValues()esa que llame a intervalos regulares. La función busca cada entrada en el registro, analiza el archivo fuente específico y vuelve a cargar el valor activo.

A medida que modifica el código fuente real, tiene persistencia allí mismo.

Obviamente, esto no funcionará donde H()no se evalúa cada cuadro, pero hay formas de resolver esto como se discute aquí .

Podría ampliar esta idea a una solución basada en socket, tal vez. Podría haber una sobrecarga de rendimiento significativa para llamar a HotValue()cada trama, pero como puede compilar fácilmente la macro reemplazándola por completo con la constante, esto no es un problema.

AntTweakBar es realmente útil para lo que quieres hacer, sin embargo, la mayoría de las veces, querrás tener métodos que se 'compilen' en el lanzamiento con algunas macros o similares.

De una pregunta sobre depuración en tiempo real , llega la respuesta de David McGraw sobre AsyncSocket para desarrolladores de iOS. Vea su respuesta para más información.

La administración de la configuración parece ser una de esas cosas que se rehizo desde cero para cada juego, probablemente debido a lo relativamente simple que es y la alta variabilidad en los tipos de configuración necesarios. Suponiendo que tiene una configuración de back-end de almacenamiento decente (SQL / lo que sea), puede codificar una solución sólida para la administración de la configuración en un día o dos, por lo que no parece haber una necesidad comercial real de una solución de middleware. Pegarlo encima de lo que sea que use para almacenar información del jugador es, creo, la mejor manera de hacerlo en la mayoría de los casos.

De hecho, he estado pensando en tal cosa últimamente, y creo que sería un gran candidato para un aplicación de Android combinada con una pequeña biblioteca en el idioma que desee . La aplicación sería un conjunto personalizable de botones, conmutadores, menús desplegables, etc. (cualquier widget que desee), y enviaría las acciones a través de WLAN (o USB si quisiera complicar las cosas) a la biblioteca. La biblioteca habría generado un hilo separado del juego y sabría qué controles en el teléfono Android corresponden a qué variables en el juego (las establecerías en tu código de inicio) y tendrían una conexión a la aplicación de Android.

Luego, jugar con tu juego es tan fácil como tocar cosas en tu teléfono. Incluso podría tener algunos cuadros de texto en el teléfono que muestren valores variables en tiempo real del juego, o podría hacer que la biblioteca reenvíestdin o stderrhacia un área de texto desplazable en el teléfono. ¡Las opciones son ilimitadas!

La única preocupación real es con la velocidad. Si la velocidad y el tiempo de reacción son cruciales, simplemente conectará el teléfono a través de USB y adb (depurador de Android) admite puertos de reenvío a través de USB al teléfono. Pero de lo contrario, WLAN solo tendría un retraso muy pequeño que creo que sería bastante aceptable para este propósito.

No creo que se haya escrito algo como lo anterior, pero he estado considerando escribirlo.(Simplemente no he llegado lo suficientemente lejos en el desarrollo de mis propios juegos para necesitarlo todavía)

Por supuesto, aquellos de ustedes que son usuarios de Apple probablemente puedan hacer lo mismo con sus iDevices. Personalmente, considero que el desarrollo de iOS es mucho más difícil que el desarrollo de Android, y por supuesto, la aplicación anterior podría publicarse fácilmente en el mercado de Android para una distribución fácil, mientras que Apple probablemente no permitiría una herramienta de desarrollador en la tienda de aplicaciones, por lo que siente que la plataforma Android se adapta mejor a esta herramienta.