¿Por qué es malo codificar el contenido?

Sé que la mayoría de los juegos almacenan texto de diálogo en archivos, pero también he visto algunos juegos basados ​​en texto que en realidad programan el contenido (mapa, opciones, posibles comandos del jugador, texto de la historia) en el código del juego.

Puedo pensar en algunas razones, pero ¿cuál es la razón principal por la que incluso los juegos de texto mantienen todo en archivos fuera del programa?

Los detalles de implementación difieren poco entre mantener el contenido en algo como el popular formato XML, analizarlo, luego representar mapas / mostrar texto en función de las variables creadas a partir del archivo XML y simplemente renunciar por completo al archivo XML. Ambos terminan con cadenas que salen a la pantalla. ¿No es la diferencia solo notación?

Algunos juegos incluso contienen los gráficos (¿arte ASCII?) Dentro del código. Sé que esto no está bien, y puedo adivinar algunas razones por las que es malo, pero tampoco sé cuál es la razón principal.

Es muy popular tener la mayor parte del contenido fuera del programa. Incluso Dwarf Fortress no usa caracteres ASCII reales, sino imágenes de caracteres ASCII cargadas en la memoria.

Principalmente pregunto porque es un poco PITA crear, analizar y trabajar con archivos XML. Ya sabes ... en comparación con la alternativa perezosa de hacer que cada mazmorra (contenido) única sea su propia clase.

Hay varias razones para eso. Solo voy a tocar algunos:

1. Hace que su código fuente sea un desastre. Si tiene muchos diálogos (árboles), una gran parte de su base de código es solo texto que no tiene nada que ver con su código de juego real.
2. Debería volver a compilar cada vez que cambie tanto un solo personaje.
3. El diálogo en sí es difícil de navegar. Me imagino que tratar de implementar un árbol de diálogo completo, y mucho menos varios, completamente dentro de su fuente dará como resultado un desorden anidado de espaguetis y anidados if, switchetc. Lo que resulta en un código propenso a errores, difícil de leer y más difícil de depurar.
4. Si quieres permitir que las personas modifiquen o expandan tu juego, es mucho más fácil si no tienen que lidiar con el código fuente para cambiar algo.
5. El punto anterior es aún más importante si trabajas en equipo. No desea que su escritor tenga que meterse con el código solo para ingresar una pieza de diálogo.
6. Analizar XML u otros formatos de archivo estándar es bastante fácil de hacer si usa bibliotecas existentes, por lo que el costo de implementarlo de esa manera es muy bajo y le brinda muchas ventajas y evita los problemas mencionados anteriormente y mucho más.
7. Como @MiloPrice señaló a continuación, también es mucho más fácil localizar el juego si su texto está en archivos externos. Puede agregar un idioma agregando un archivo, su equipo puede encargarse de la traducción sin tener que tocar la fuente (lo cual es especialmente importante si permite que las personas traduzcan y se supone que no deben ver todo su código; piense en freelancers, personas del comunidad que no pertenece a su equipo, etc.).

Poner los datos del contenido del juego en el código significa que para ver cualquier cambio potencial o iteración de los datos del contenido del juego, debe volver a compilar el juego en sí. Esto es malo por dos razones:

• Muchos idiomas en los que se escriben los juegos tienen largos tiempos de compilación. C ++ es particular, puede ser muy malo a este respecto, y C ++ es un lenguaje muy común para grandes juegos comerciales. No es un problema menor con lenguajes como C # y Java, pero aún así no es tan rápido como poder almacenar datos del juego en archivos externos que pueden volver a cargarse mientras el juego se está ejecutando para ver los cambios.

• Muchos juegos son desarrollados por equipos que a menudo consisten en desarrolladores no técnicos (diseñadores y artistas) que producen contenido. No solo las personas no técnicas no quieren tener que volver a compilar el juego, o tratar con "herramientas de programación engorrosas", para iterar sobre su contenido, puede ser conveniente minimizar la exposición del código fuente solo a los programadores (porque menos personas tener acceso al código fuente, menos personas pueden filtrarlo, accidentalmente o no).

Creo que está sobreestimando la complejidad de cargar datos de archivos de texto o XML. La mayoría de las veces debe usar una biblioteca para hacer esto, lo que hace que el proceso de analizar XML / JSON / lo que sea sea mucho más fácil. Sí, escribir un sistema de carga de nivel basado en datos conlleva un pequeño costo inicial, pero generalmente le ahorrará mucho tiempo a largo plazo en comparación con toneladas de clases únicas para representar cada nivel.

Es posible que los juegos más pequeños o más simples no tengan tanto que ganar con la inversión a largo plazo de un enfoque basado en datos, por lo que, a menos que los desarrolladores utilicen los marcos / motores existentes que lo admiten, puede ser más eficiente para ellos simplemente codificar los datos en El código del juego.

Por supuesto, hay una serie de razones por las cuales un juego determinado puede optar por colocar sus datos en archivos externos (o no); No es factible enumerarlos a todos. En algún nivel, generalmente todos se reducirán a la velocidad de iteración adicional o flexibilidad que puede proporcionar no tener que reconstruir el juego.

Como siempre, como siempre, depende. Pero primero, me gustaría argumentar que la codificación rígida no es mala en sí misma.

Tengo contenido codificado, específicamente texto de diálogo, en algunos juegos simples, y el mundo no terminó. A los programadores nos encanta abstraer las cosas, pero recuerda que cada capa de abstracción que hagas hará que tu programa sea más complejo y más difícil de entender.

Si tu juego es lo suficientemente simple como para que puedas codificar parte del contenido, sin duda lo consideraría por simplicidad.

Esto, sin embargo, en realidad no escala demasiado. Ciertamente, la razón más común para poner contenido en recursos externos es simplificar el trabajo en equipo, ya que una persona o equipo puede enfocarse en escribir el juego, mientras que otro puede enfocarse en crear y pulir el contenido.

Sin embargo, trazar la línea entre el programa y el contenido no siempre es realmente trivial. Se podría decir que las texturas son 100% de contenido; pero ¿qué pasa con las texturas generadas procesalmente? El texto del cuadro de diálogo podría considerarse contenido 100%; pero ¿qué pasa cuando el diálogo cambia dependiendo de tus acciones anteriores? Otros elementos que uno puede considerar que son 100% parte del programa, como scripts o sombreadores, también podrían considerarse parte del contenido del juego. ¿Deberían estar codificados? ¿deberían cargarse como un recurso externo?

Sin embargo, recuerde que cada tipo de contenido que admite en su juego debe tener un código de carga e interpretación relacionado con él, por lo que, en caso de duda, recomendaría codificar el contenido y solo llevarlo a un recurso externo cuando realmente necesito esa flexibilidad (no cuando crees que la necesitas, sino cuando realmente la necesitas)

Finalmente, una ventaja de almacenar datos en archivos de recursos es que puede cargarlos solo cuando los necesita (por lo tanto, posiblemente acelerar los tiempos de carga del juego) y descargarlos cuando ya no los necesite (lo que le permite tener más contenido) que puede caber en la memoria). (Rincón de Nitpickers: podría decirse que las DLL de recursos pueden considerarse recursos externos)

Una gran razón para almacenar archivos de texto es la reutilización. Crear un marco de juego de texto que lea sus mapas, diálogos y otros recursos de un archivo de texto le permite reutilizar su marco para otros juegos. Más allá de los juegos de texto, así es como títulos de gran presupuesto como Call of Duty lanzan un nuevo juego cada año.

Otra razón es la portabilidad. Puede usar los mismos archivos para web, PC, Mac, Android, etc. Todo lo que necesita hacer es simular su marco para estas diferentes plataformas, y la mayor parte de los datos del juego no se han tocado.

Al ir más allá de los juegos basados ​​en texto, tener un script y datos almacenados en archivos disminuirá los tiempos de recompilación y le permitirá crear una interfaz para manipular los datos más fácilmente.

En aras de hacer cambios más rápido, acelera el desarrollo en producciones más grandes por toneladas.

No necesita enseñar a todos a aprender cómo ingresar y editar la fuente para realizar cambios simples. Al arrastrarlo fuera del código real, más personas tienen la oportunidad de perder el tiempo, es más fácil descubrir con qué opciones puedes jugar y todo el proceso de ajustar varias partes de tu juego lleva mucho menos tiempo. Incluso las preguntas y respuestas pueden ayudar con eso.

No puedo creer que nadie haya mencionado esto todavía, pero una gran razón es hacer que la localización sea MUCHO más fácil. Si necesita admitir inglés, francés, alemán, español, portugués, italiano, ruso, chino y cualquier otro idioma al que esté apuntando, la codificación requiere que tenga un código de respaldo separado para cada idioma. También significa que si necesita eliminar cierto contenido (lea: censura), debe cambiar su código para evitarlo, en lugar de decir "solo reemplace este minijuego de sondeo anal con este banner pasivo-agresivo que explica gráficamente lo que está sucediendo ". También es bastante hostil para los consumidores, ya que es probable que necesiten reiniciar el juego para cambiar el idioma, ya que debe cargar otras bibliotecas. Finalmente,

Por otro lado, si está utilizando recursos externos, admitir diferentes idiomas solo significa cargar un archivo de recursos diferente. Esto se puede hacer fácilmente mientras se ejecuta el juego. significa que puede tener una única base de código, simplificando enormemente el desarrollo. Y también significa que puede agregar fácilmente soporte posterior al lanzamiento para otros idiomas. Finalmente, significa que puede permitir que el usuario opte por no instalar ciertos idiomas (una característica que no ocurre con tanta frecuencia en los juegos, pero que aún es posible) para ahorrar espacio en disco y ancho de banda.

Creo que una frase clave es la separación de las preocupaciones .

Si su código no incluye el texto, el código se vuelve menos complejo. El programador que escribe el código no tiene que pensar en el texto específico y puede centrarse en el código.

No tiene que pensar en la localización. La persona que realiza la localización no tiene que preocuparse por el código.

Creo que es demasiado fácil ser el tipo 'marchito que blanco' y recomiendo encarecidamente usar un archivo de recursos de texto externo.

¿Por qué? Porque aquí hay una opción que consiste en equilibrar el costo / problemas / ventajas de cada solución.

Cuando se usa un archivo externo ... Bueno, supongo que las otras respuestas explican los beneficios lo suficientemente bien. ¿Pero qué hay de los costos? Debe definir un formalismo válido, crear un intérprete, acordar un formato de archivo y, lo que es peor ... crear otra aplicación -un editor-. Lo cual es un problema de 0.00% si eres miembro de un equipo de 50 codificadores que está construyendo un proyecto grande. Pero si estás solo: estás estancado.

Nuevamente, no subestimo los enormes beneficios de flexibilidad de un recurso externo: la programación basada en datos me parece el camino a seguir para los videojuegos. Pero no olvidemos el costo.

Por otro lado, tener el texto dentro del código permite la creación rápida de prototipos, por lo que debería preferirse por primera vez. Entonces, mi consejo sería, a medida que el proyecto madure, analizar el tipo de datos necesarios para modelar los diálogos (estado de ánimo / historial-estado / ...). Luego, en algún momento, usted decide el formato de algunas clases / reglas / archivos y opta por lo real, permitiendo a otras personas editar / desacoplar el código del contenido, etc. O para un juego con diálogos simples (Mario ...) solo considera que el costo es demasiado alto y mantiene las pocas cadenas / comportamiento codificados.
Tu llamada.

(Observación sobre la localización: es solo una tabla hash, por lo que es un problema independiente y fácil de resolver).

Supongo que las licencias también pueden ser una razón para no incluir contenido en el código.

Por ejemplo,

• su código puede ser FLOSS , pero no desea licenciar su contenido (tal vez desee publicar su código de juego para que otros puedan usarlo para crear juegos similares con contenido diferente)
• su código puede ser FLOSS, pero desea utilizar una licencia Creative Commons para su contenido (ya que las licencias de software no funcionan muy bien para el contenido y viceversa)
• su código puede ser propietario , pero está reutilizando contenido gratuito
• su código puede ser propietario, pero desea publicar su propio contenido bajo una licencia gratuita / libre