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.
fuente
just making every unique dungeon (content) its own class.Eso me hizo temblar. La separación de los datos de la lógica es un principio tan fundamental para mí que me sorprende que todavía haya desarrolladores que los violen.Respuestas:
Hay varias razones para eso. Solo voy a tocar algunos:
if,switchetc. Lo que resulta en un código propenso a errores, difícil de leer y más difícil de depurar.fuente
constmatrices con duración de almacenamiento estático). Esto le ahorra todo el código, y el costo de la memoria de tiempo de ejecución, de cargar / convertir una representación de datos externos en tiempo de ejecución. Por supuesto, todas sus otras razones para mantener los datos externos aún se aplican.Don't Starvesigue este enfoque y es uno de los juegos mejor escritos que he visto. Muchos otros juegos en el pasado y el presente también hacen esto, así como aplicaciones (y raramente utilidades). Yo diría que, en general, fuera de pequeños proyectos y pequeñas utilidades, las capas pesadas y la separación son siempre su amigo.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.
fuente
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)
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente
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).
fuente
Supongo que las licencias también pueden ser una razón para no incluir contenido en el código.
Por ejemplo,
fuente