¿Es una buena idea simplificar un motor de juego basado en personajes hasta el punto en que no sea necesario aprender scripting / programación?

Recuerdo, y sigo pensando, que uno ni siquiera puede hacer un juego 3D prototipo para probar comportamientos simples sin usar herramientas gigantescas como la unidad o conocer una amplia programación en C ++, patrones de diseño, un motor 3D decente o básico, etc.

Ahora me pregunto, ya que conozco programación, si tengo más suerte que aquellos que necesitan aprender programación antes de saber cómo hacer algo. Incluso los motores con secuencias de comandos como Unity no son para niños y, en mi opinión, tienden a dictar sus formas de hacer las cosas. Este no es el caso con motores como Ogre o Irrlicht.

Ahora estoy pensando que los juegos basados ​​en personajes ocupan una gran parte del mercado de juegos. ¿Crees que es una buena idea hacer un motor de juego orientado al control de personajes que solo permita construir IA con exclusión de cualquier otra cosa?

Cuando digo prototipo, también me refiero a "genérico" en el sentido de que uno puede elegir rápidamente entre un conjunto de parámetros de juego como el administrador de escena, el POV de la cámara del jugador, los controles, algunas colisiones / física muy básicas e integración de dirección básica (OpenSteer por ejemplo). La idea principal es hacer una caja de arena de IA pero en 3D, para que pueda demostrarse sin las restricciones 2D (y también hacer que sea más apto para prototipos en 3D para un proyecto 3D en lugar de 2D).

Me gusta mucho el motor de juego poco apreciado en Blender. (http://www.blender.org) El modelo sensor-controlador-actuador es realmente fácil de seguir incluso para los no programadores, y es posible hacer un juego razonablemente completo (mover un personaje animado, disparar un arma, destruir objetivos , mostrar puntuación, realizar un seguimiento de la salud, restablecer el nivel o pasar a uno nuevo) sin ninguna programación en absoluto.

Por supuesto, algunas cosas requieren programación (especialmente obtener la entrada del mouse para un FPS). Sin embargo, Blender ya incorpora Python, y las secuencias de comandos de Python están muy bien vinculadas en el modelo, por lo que nunca necesita reemplazar los actuadores de sensores con Python. En cambio, simplemente cambia de un controlador de 'paso' muy simple a un script completo de Python que puede leer todos los sensores en la escena y pasar el control a todos los actuadores.

Es bastante factible crear un prototipo de juego en unos días en Blender (lo hice para un proyecto en un museo infantil local el año pasado).

Por supuesto, nada reemplaza los buenos conocimientos de programación y, finalmente, un desarrollador necesita comprender la programación.

Independientemente del mecanismo de entrada, al final del día todavía debes configurar algún tipo de forma de decirle al juego cuál es la lógica. "Scripting" es un buen término coloquial para esto. Así que básicamente no estoy de acuerdo con la afirmación de que puedes simplificar algo hasta el punto en que no necesites saber "scripting".

Dicho esto, no todas las secuencias de comandos deben hacerse con un lenguaje de programación basado en texto. Ha habido algo de trabajo (pero no mucho) para crear un sistema visual de secuencias de comandos. La herramienta de scripting de nivel de Unreal, Kismet, es un muy buen ejemplo de una. El motor de origen tiene una mecánica similar, pero utiliza entidades en el mundo en lugar de en un plano.

Básicamente, tiene cuadros que arrastra en algún tipo de entorno que tiene entradas y salidas. Si necesita algún tipo de salida de ramificación, tiene un cuadro que tiene una entrada y múltiples salidas. Esos resultados pueden ir a acciones que tienen datos vinculados a ellos (es decir, "moverse a este punto", "decir esta línea", "hacer esta pregunta", etc.). Por lo general, es una barrera de entrada significativamente más baja para poner algo en funcionamiento en un lenguaje visual, ya que no tiene que conocer las palabras clave o la sintaxis, solo tiene un conjunto limitado de cuadros para elegir, todos tienen comportamientos definidos, y simplemente conectarlos juntos

Sin embargo, es mi opinión que los motores de secuencias de comandos visuales realmente no valen la pena. Debe poder pensar de manera estructurada y lógica para poder decirle al motor con éxito lo que desea hacer. Si puede pensar así, pasar de cuadros con entradas / salidas a declaraciones de ramificación básicas y llamadas a funciones en un lenguaje de script no es tan importante. De hecho, después de un tiempo, la parte visual probablemente sea un obstáculo. Además, es mucho más trabajo en el lado del motor de las cosas. Tienes que hacer cosas como implementar deshacer, copiar / pegar, quizás tener algunas características de nivel superior para organizar tus scripts. Con un lenguaje basado en texto, puede dejar todo eso al IDE.

En general, será una compensación. Si realmente desea eliminar la necesidad de realizar algún tipo de secuencia de comandos, generalmente estará hablando de crear una especie de interfaz que juntará las secuencias de comandos en segundo plano (o simplemente conectará objetos lógicos o no). Hay juegos completos en los que ese es el punto principal para ellos, un entorno bien definido donde arrastrar y soltar la funcionalidad para ver cómo interactúa con él.

Sin embargo, al final del día, siempre será una compensación. Cuanto más simple intente hacer que la interfaz sea más simplista, las cosas creadas a través de esa interfaz.