¿Por qué colocar la configuración de la entidad fuera de los scripts?

He visto muchos juegos que definen los componentes de la entidad en los archivos de script, pero cuando configuran cada entidad y especifican qué componentes tiene, usan algún otro formato de archivo (como XML). ¿Por qué hacen eso?

Estoy pidiendo sobre todo para ver cuál era la razón de los demás para esto. Yo también configurar mi entidades fuera de los guiones (aunque no he elegido JSON XML). Mis razones para hacer esto son facilitarme la implementación de juegos guardados y también porque creo que este tipo de configuración está mejor organizada en algo como XML o JSON.

Respuesta de @ Christopher Larsen: demasiado tiempo para publicar como comentario

Me temo que podría haberse desviado un poco del tema de la pregunta. Los problemas que está describiendo están más relacionados con entidades basadas en la jerarquía; Nota en mi pregunta mencioné que estaba hablando de entidades basadas en componentes.

Aquí hay un ejemplo de lo que quería preguntar. A continuación hay dos formas alternativas de configurar una entidad: a través del script y a través de un archivo JSON externo. Mi pregunta fue, ¿por qué tanta gente prefiere configurar la entidad fuera de los scripts?

Una clase de entidad base:

class Entity:
    def __init__(self, name):
        pass
    def addComponent(self, comp):
        pass

El enfoque del guión:

orc = Entity('Orc')
orc.addComponent(PositionComponent(3.4, 7.9))

El enfoque JSON:

{
    "name" : "Orc",
    "components":
    {
        "PositionComponent": {
            "x" : 3.4,
            "y" : 7.9
        }
    }
}

Ya dije mis razones para usar este enfoque, que son técnicas y organizativas. Quería saber por qué tantos otros (por lo que he visto) usan esto.

La principal ventaja que me viene a la mente es que permite que la configuración sea editada / administrada por un no programador sin requerir que toquen ninguno de los scripts del juego.

Una razón por la que generalmente uso un archivo de configuración en lugar de un script para esto es:

La única forma de verificar la corrección de un script, por ejemplo, especificando todos los valores, es ejecutarlo.

Escribir código para permitir que los scripts configuren los valores significa escribir código para crear objetos de esqueleto para que los scripts completen los valores y luego validen que el script lo hizo y tal. Es más código y código más defectuoso que cargar desde un archivo de configuración plano, a menudo utilizando una biblioteca que admite algún tipo de mecanismo de validación.

La configuración de la entidad puede ser simplemente una serialización de una entidad específica. Esto le permite manejar la salida de las herramientas de edición y modificación de juegos de la misma manera que lo haría con un juego guardado. En particular, para los juegos en los que no se puede predecir en qué estado estará una entidad determinada durante el guardado del juego, por ejemplo, debido a su IA o porque en primer lugar se generan parcialmente por procedimientos, es útil poder volcar todo datos que definen lo que una entidad "es" (en oposición a lo que "hace") como una secuencia de bytes que se guardará.

El patrón que describe es una implementación de un sistema controlado por datos.

Los sistemas basados ​​en datos se usan comúnmente en el desarrollo de juegos, ya que permiten que la definición de contenido se encapsule externamente a la fuente. Esta representación externa puede modificarse fácilmente (e incluso actualizarse en tiempo real por una aplicación que busca modificaciones) para cambiar el comportamiento de una entidad.

Una vez que los datos se definen externamente, tiene todo tipo de posibilidades sobre cómo interactúan los diseñadores con ellos, desde editar directamente archivos de texto (¡uf!) Hasta sofisticadas interfaces de usuario que guían las elecciones del diseñador de forma lógica, consistente e incluso verificada para su corrección (desde la perspectiva del equilibrio del juego).

Si los datos se incrustan directamente en el código, cualquier cambio requeriría una reconstrucción de la aplicación, lo que para proyectos grandes requiere un tiempo moderado, así como el tiempo requerido para la implementación de los archivos binarios (por ejemplo, los nuevos archivos binarios deben implementarse e instalarse en el servidor).

Tomemos un ejemplo de una entidad esterotípica el "orco" ...

Una forma de implementar para nuestro orco sería escribir una descripción completa en código de todas las características y la lógica del orco.

• maxhealth = 10
• daño = 3 daños por segundo
• fugitivo = verdadero
• fugitivo cuando = salud <10
• agresivo = verdadero

Cuando instanciamos orcos, todos sus valores se inicializan exactamente igual (o tal vez son estáticos). El problema que surge es que algún diseñador aparecerá y dirá "Necesitamos un tipo diferente de orco para las áreas de novatos, que tenga menos salud, nunca huya y no sea agresivo. Eso permitirá que los nuevos jugadores se acostumbren a combatir sin el mayor dificultad y confusión al aprender el sistema de combate ".

Genial, ahora necesita una clase diferente o (tal vez estábamos mirando hacia el futuro) ajustar los valores que alimentamos a la "fábrica" ​​que crea orcos al crearlos en un área de "novato". Entonces hacemos los cambios, implementamos nuevos binarios. Solo para que los jugadores de prueba regresen y digan que los nuevos valores de salud son demasiado bajos, ya que matamos a los orcos de un solo golpe.

Si nuestros sistemas estaban basados ​​en datos (y puntos de bonificación para aplicaciones que admiten la recarga cuando se realizan modificaciones), entonces las modificaciones necesarias para satisfacer al diseñador y los probadores de juegos son simples cambios de datos sin necesidad de recompilación / implementación. Esto hace felices a los diseñadores porque no están atrapados esperando cambios en el código, y hace felices a los programadores porque constantemente estamos modificando el código fuente para ajustar los valores.

Llevar los sistemas basados ​​en datos a extremos permite que todo, desde niveles de juego, hechizos e incluso misiones se implementen mediante simples cambios en sus datos que no requieren ningún cambio en el código. Al final, se trata de facilitar la creación, el ajuste y la iteración del contenido del juego.

En su ejemplo, ya está utilizando dos lenguajes de secuencias de comandos. Esta es la forma en que diría que a la larga funciona mejor, pero sugeriría que unifique el lenguaje de script que está utilizando. Si el ejemplo de script que diste se hizo en Lua, en lugar de Json, diría que usa las tablas de Lua para construir tu objeto. La sintaxis en realidad sería similar y le permitiría admitir una interfaz para exponer sus componentes.

Tocar por qué la gente elige hacerlo generalmente en XML y luego en secuencia de comandos en lógica, es que esto tiene sentido cuando lo dices. Aquí está mi definición del objeto en los datos, ¿cuál es un buen formato de almacenamiento de datos? Casi siempre es XML (aunque también voy con JSON;). Y luego, cuando quieren agregar lógica, bueno, eso se codifica o se coloca en un archivo de script.

No es un pensamiento equivocado, pero en mi opinión la gente simplemente no va al siguiente paso. Mire cualquier lenguaje completo, c / c ++ / c # ,. Puede definir los objetos y su lógica en un solo idioma, ¿por qué no hacer lo mismo en su interfaz de scripting? Es casi como decir que deberíamos definir nuestras clases en XML y nuestros métodos en C # cuando lo piensa. Tal vez los lenguajes de scripting de juegos antiguos no eran lo suficientemente potentes y todavía se mantienen como lo hicieron.