Motor de juego y diseño basado en datos.

He escuchado sobre el diseño basado en datos y he estado investigando al respecto por un tiempo. Entonces, he leído varios artículos para obtener los conceptos.

Uno de los artículos es Data Driven Design escrito por Kyle Wilson. Como él describió, me parece que el código de la aplicación (es decir, el código para controlar recursos como la memoria, la red ...) y el código lógico del juego deben estar separados, y el código lógico del juego debe estar impulsado por fuentes de datos externas. En este punto, puedo imaginar que el desarrollador escribiría algún tipo de editor de juegos que acepte datos externos sobre objetos en el juego (como información de personajes, información de armas, información de mapas ...). El diseño del escenario estará escrito por un lenguaje / herramienta personalizada escrita por un programador para permitir que el diseñador del juego cree interacción entre los objetos del juego. El diseñador del juego usará un lenguaje de secuencias de comandos existente / personalizado para escribir secuencias de comandos para el juego o una herramienta de arrastrar y soltar para crear el mundo del juego. Un ejemplo de enfoque de herramienta que se me ocurre es World Editor, que generalmente se incluye junto con los juegos de Bliizard.

Sin embargo, otro artículo está en contra del uso de Data Driven Design, The Case Against Data Driven Design . El autor sugiere no dejar que el diseño del juego se base en datos, ya que llevaría más tiempo desarrollar un juego, ya que el diseñador del juego tiene la carga de programar. En cambio, habrá un programador de juegos para programar el juego libremente desde el diseño del boceto, y el diseñador del juego lo verificará una vez que la programación del juego haya finalizado. Él llama a esto es impulsado por el programador. Lo que pienso de este método es similar a la forma en que solía hacerlo: la lógica del juego es la aplicación en sí misma, según lo expuesto en la idea anterior, la aplicación es el editor del juego y el juego real está diseñado en función de la herramienta.

Para mí, el primer método parece ser más razonable, ya que los componentes del juego pueden reutilizarse para muchos proyectos. Con el segundo método que se opone al diseño basado en datos, el código del juego pertenece solo a ese juego. Es por eso que creo que Warcraft tiene tantos géneros de juego, como el Warcraft original y varios mapas personalizados, y uno de los más famosos: DOTA, que en realidad define un nuevo género. Por esta razón, escuché que la gente llama al World Editor es el motor del juego. ¿Es así como debería ser un motor de juego?

Entonces, después de todo esto, solo quiero verificar si hay alguna falla en mi comprensión sobre estas ideas (impulsada por datos, unidad de programación, secuencias de comandos, etc.).

Hacer que su juego (o cualquier producto de software) se base en datos es casi siempre un beneficio. La única desventaja real es que puede pasar un poco más de tiempo construyendo los sistemas relevantes por adelantado; sin embargo, dará sus frutos durante el resto de su carrera como programador (incluso si no reutiliza esos mismos sistemas durante todo ese tiempo, reutilizará las técnicas que empleó para construirlos).

El desafío, y donde entra en juego la desconexión en esos dos artículos que vinculaste, es lo que eliges poner en los datos y a quién eliges para dar acceso a esos datos. Básicamente, el diseño y el desarrollo basados ​​en datos solo significan que usted coloca la información en un almacenamiento externo, carga esa información en tiempo de ejecución y actúa sobre ella. El código de su aplicación hace lo que le dicen los datos externos, en lugar de escribir el código de la aplicación que hace directamente lo que cree que debería ser el resultado final. No es una idea compleja.

No tiene que construir complejas "arquitecturas basadas en componentes" (como es la moda en estos días). Poner constantes para ajustar la física (fuerza gravitacional, coeficientes de restitución) en un archivo de texto depende de los datos. Las secuencias de comandos (en Lua u otra cosa) están basadas en datos. Describiendo sus datos de nivel en XML. Cualquier cosa como eso.

Puede manejar casi cualquier componente de software con datos, y puede elegir con cuáles desea hacerlo. El tiempo del desarrollador es costoso; tiempo programador especialmente así. Si puede ahorrarle tiempo a usted u otros programadores poniendo el comportamiento y los datos en un almacenamiento externo y no requiriendo que el juego se vuelva a compilar para cada pequeño cambio, debería hacerlo. Ahorrará dinero y hará las cosas más rápido.

Además, corre un gran riesgo al intentar hacer que el "diseño de los diseñadores" y hacer que los programadores "hagan realidad esos diseños", lo que obliga a un programador a existir en el ciclo de iteración para el trabajo de un diseñador: corre el riesgo de hacer que el programador se sienta como él es solo un mono código, haciendo pequeños ajustes triviales para el diseño constantemente. Esto puede ser enormemente desmoralizante para una gran mayoría de programadores, que desean trabajar en desafíos técnicos interesantes y no en ser un representante del diseñador.

Para sus preguntas específicas:

¿Es así como debería ser un motor de juego?

Un "motor de juego" en realidad no tiene una definición fija. En general, es la colección unificada de tecnología subyacente utilizada para hacer un juego, generalmente respaldada por un montón de herramientas relacionadas (y por lo tanto basadas en datos). Pero varía bastante de un contexto a otro.

Entonces, después de todo esto, solo quiero verificar si hay algún defecto en mi comprensión sobre estas ideas (datos, unidad de programación, secuencias de comandos, etc.).

Parece que está más o menos en el camino correcto, aunque quizás esté complicando demasiado el diseño y el desarrollo impulsados ​​por los datos al combinarlo con sistemas basados ​​en componentes.

Como autor de la segunda publicación, me gustaría aclarar algunos puntos.

1. Como sugirió Josh Petrie, estructurar su código para usar datos en lugar de solo codificar todo siempre es una victoria. No estaba sugiriendo lo contrario. Estaba señalando que empujar todo sobre el diseñador no es una buena idea. El término "diseño basado en datos" significa cosas diferentes para diferentes personas, por lo que probablemente debería haber sido más específico cuando escribí el artículo original.
2. En cada lugar en el que he trabajado, creamos estructuras de datos que son ajustables en el motor. Para hacer un cambio, no tenemos que volver a compilar el juego. Podemos cambiar el número dinámicamente en tiempo de ejecución. Las estructuras de datos a menudo se almacenan en código, pero dependiendo de quién las cambie, se pueden cargar fácilmente desde un "archivo de datos".
3. La mayoría de los entornos de desarrollo admiten alguna forma de edición y continuación o recarga de módulo para C / C ++.
4. La mayoría de los estudios de desarrollo de juegos tienen programadores de juegos. Su trabajo es a menudo trabajar con el diseñador para crear una experiencia divertida. Su principal preocupación no son los desafíos técnicos, sino la diversión del código. He trabajado como programador de juegos durante muchos años, y me parece más interesante que solo tratar de resolver desafíos técnicos. Mis responsabilidades han variado, pero he encontrado que mi trabajo es más satisfactorio cuando estoy a cargo de la implementación y trabajo con los diseñadores para elaborar algo genial. El problema con los diseñadores que codifican o crean secuencias de comandos es que los programadores a menudo tienen que solucionar los errores, que es una de las cosas menos divertidas que puedes hacer como programador.
5. Lo que funciona mejor para un estudio depende del juego. Si tienes mucho tiempo para hacer un juego, y quieres dar las piernas a la comunidad de mods y crear algo de gran alcance, entonces tiene sentido hacer un juego que esté completamente basado en datos. Muchos juegos no tienen ese objetivo. Tienen que producir un nuevo juego en dos años, y a menos que tengan una franquicia exitosa, es probable que sea un tipo de juego diferente a su trabajo anterior
6. Lo que hace un "diseñador" puede variar de un estudio a otro. He oído hablar de un estudio de desarrollo que contrata a programadores de juegos de otros estudios, los llama diseñadores y les hace escribir el comportamiento del juego. Esto evita el problema de tener personas que no están capacitadas para programar codificación / scripting.
7. Siempre debe haber una delineación entre el código lógico del juego y el código del motor. Además, normalmente desea tener algún tipo de editor visual para la colocación de objetos. Nunca he trabajado en un estudio donde las ubicaciones enemigas están codificadas. Se colocan en un editor. Permítanme proponer un ejemplo de lo que estoy hablando. Digamos que el diseñador piensa en un enemigo. ¿El diseñador escribe el comportamiento de este nuevo tipo de enemigo? Eso es lo que considero diseño basado en datos (en términos de lo que Tim Moss escribió al respecto). En la forma en que propongo, el programador trabaja con el diseñador, hacen un enemigo divertido, quizás con parámetros ajustables, y luego se colocan en el nivel.
8. El código nativo escrito por un programador se ejecutará más rápido en tiempo de ejecución que un script escrito por un programador, que se ejecutará más rápido que un script escrito por alguien con menos conocimientos técnicos. Este rendimiento puede o no ser importante dependiendo del tipo de juego que estés haciendo y de lo que estés haciendo, pero es algo a tener en cuenta.
9. Puede compartir el código del juego entre juegos, independientemente del método que elija. No estoy realmente seguro de lo que está llegando con este punto. Incluso si no está utilizando un lenguaje de secuencias de comandos o una herramienta visual para definir algunos comportamientos, debe diseñar su código de juego en componentes reutilizables tanto como sea posible. Siempre habrá cosas que no sean aplicables a tu próximo juego, pero en todos los lugares en los que he trabajado, cuando comenzamos el próximo juego, comenzamos con la base de código del anterior, incluso si no es una secuela. Luego guardamos las cosas que tienen sentido y eliminamos las cosas específicas del juego.

Al final, no hay una respuesta correcta o incorrecta. Se trata de cómo usted y sus compañeros de trabajo se sienten cómodos trabajando. Cuando escribí ese blog hace un tiempo, se habló mucho sobre cómo se debería llevar todo el trabajo a los diseñadores, y quería escribir sobre la cantidad de compañías de juegos exitosas que conocía encontraron un equilibrio diferente.

Además, como nota al margen, mi entrada de blog tiene 5 años. Parece que muchos más estudios se están moviendo hacia los lenguajes de script y otras cosas en estos días, pero están creando herramientas maduras para depurarlos, que fue mi principal queja. Cuando escribí esto, no creo que existiera Unreal Kismet, que no he usado, pero parece que están tratando de simplificar las secuencias de comandos y aparentemente tiene un depurador. (No tengo idea de qué tan bien funciona)

Para juegos de menor escala, definitivamente no creo que quieras probar y utilizar un lenguaje de script o una funcionalidad similar en tu tecnología, pero si tienes un gran equipo y mucho tiempo para dedicar a la tecnología, es posible hacer esto correcto y la inversión de tiempo puede tener sentido dependiendo de cómo le guste trabajar a su equipo de desarrollo. Personalmente, probablemente me aferraré a C ++ el mayor tiempo posible porque, para mí, es el más fácil y rápido, ya que a menudo tengo que tratar de solucionar "características" como la recolección de basura.

Debe buscar el motor de tecnología BitSquid . Se construye utilizando conceptos DOD. El blog de Niklas Frykholm es muy interesante. Hay muchos artículos sobre cómo está diseñado este motor.

En el GDC 2011, Niklas realizó una presentación sobre Data Driven Renderer .