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.).
fuente
Respuestas:
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:
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.
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.
fuente
Como autor de la segunda publicación, me gustaría aclarar algunos puntos.
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.
fuente
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 .
fuente