Durante mucho tiempo, una de las mejores formas de utilizar procesadores potentes para el entretenimiento fue
Dwarf Fortress , un juego en el que todo el mundo consta de personajes ASCII, y que con gusto comerá un gigabyte de memoria y una gran fracción del tiempo del procesador.
Pero a diferencia de otros juegos, en el caso de
DF, el jugador siente que realmente necesita todo lo que necesita. Sus cálculos detallados crean un mundo entero con edificios, ciudades, comerciantes, ríos, volcanes, monstruos y, por supuesto, gnomos. Si una persona creara todo esto, este sería un logro excelente;
Dwarf Fortress es un programa que crea todos estos objetos por sí solo.
El autor del juego, Tarn Adams, accedió a responder nuestras preguntas sobre su creación, que, a pesar de la existencia de muchas imitaciones, sigue siendo un juego completamente único.
Gamasutra: escuchamos que Dwarf Fortress saldrá en Steam e itch.io en una versión paga con una interfaz simplificada. Dicen que esto se debe a los costos de su próximo tratamiento. ¿Es difícil para un desarrollador independiente mantenerse a flote?Adams: Sí, debe hacer un gran esfuerzo para no abandonar el negocio, y casi todos los desarrolladores se ven obligados a inventar formas creativas para poder pagar la vivienda de alquiler y otras necesidades primarias. Y a veces te encuentras con problemas que no puedes manejar. Tuvimos suerte hasta ahora, pero tenemos que cambiar con el tiempo: renunciar y conseguir un nuevo trabajo, cambiar a Patreon y ahora en Steam con picazón, o dibujar dibujos a lápiz, que está muy lejos de crear videojuegos.
¿Cómo es el trabajo de construcción de código del día a día para Dwarf Fortress ? ¿Qué idiomas usas? Que bibliotecas ¿Qué IDEs si los usas? ¿En qué computadora estás desarrollando el juego?Trabajo en una computadora portátil Toshiba normal y poco notable con Windows 10. Escribo código en una terrible mezcla C / C ++ en la comunidad MSVC. Para la versión heredada uso OpenGL, para la versión principal uso SDL y para el sonido uso FMod. No utilizo nada más en Windows, con la excepción de parte de los encabezados de MSVC (y anteriores), que he estado usando durante décadas. No soy completamente consciente de lo que está sucediendo en las versiones de Linux / Mac porque no las desarrollo regularmente.
Dwarf Fortress ha estado en desarrollo durante casi 17 años, y su código base debe haber alcanzado proporciones gigantescas. En mi máquina, crear un mundo con configuraciones estándar requiere más de 1.2 gigabytes de RAM. El problema con estos megaproyectos es que se vuelven demasiado grandes y no caben completamente en el cerebro. ¿Qué estrategias utiliza para mantener el proyecto inteligible y comprensible para el trabajo?Tengo un sistema de nombres estricto y no guardo nombres largos de variables y funciones, de modo que todo sea legible incluso después de unos años. En general, trato de cuidar el futuro yo mismo. Todos mis comentarios en el código están dirigidos a esto. Utilizo activamente la función "buscar en archivos". Pero hay situaciones en las que nuevamente tengo que averiguar qué sucede, por ejemplo, al expandir el sistema anterior o corregir el error; En este caso, puede llevar una hora o más investigar. Esto me permite dejar comentarios útiles adicionales en los que inicialmente no pensé.
Recuerdo que Threetoe (el socio de Tarn en el desarrollo de juegos) escribe historias, y luego intentas crear un motor de juego en el que puedan suceder. Todavía me parece que esta es una forma inspiradora de trabajar. ¿Fueron las historias que rechazaste demasiado complicadas de implementar? ¿Alguna vez ha sucedido que la trama de uno de ellos se repitió por completo en el juego?Ja, creo que, en cierto modo, son demasiado complicados. Motivaciones del personaje, establecimiento de objetivos, etc. sigue rezagado de cómo suceden en las historias. Sin embargo, este sigue siendo un proceso útil, porque siempre hay elementos más ligeros para generar historia; Además, podemos acercarnos a la mecánica básica de los personajes, incluso si nunca lo alcanzamos.
Wikipedia dice que el número de versión del juego (ahora .44) muestra qué tan lejos estás de completarlo (es decir, 44%). ¿Qué le espera a la fortaleza enana en el futuro? ¿Tienes alguna premonición sobre lo que sucederá? ¿Qué aspectos serios te quedan por implementar?Estoy terminando el lanzamiento con los villanos, que se lanzará en los próximos meses. Debería ser bastante curioso. Luego implementaremos los gráficos y aumentaremos la usabilidad del juego para las versiones en Steam / itch. Luego mejoraremos el proceso de asedio y haremos un poco más de trabajo, y luego pasaremos a Big Wait. Esta es la mayor reestructuración y expansión en la historia de
DF . Nos permitirá generar mitos sobre la creación y crear sistemas de procedimientos totalmente mágicos, así como abrir varias ventanas para ver diferentes partes del mundo, etc. Esta será una gran adición. Luego habrá un lanzamiento con propiedad / leyes / aduanas. Después de eso, el pedido aún no se ha determinado, pero trabajaremos en la economía, los barcos y otros componentes importantes que aún no están disponibles. ¡Todavía tenemos mucho por hacer! Ni siquiera hemos llegado a la mitad de la versión 1.0. Pero la versión 1.0, el desarrollo del juego en realidad no terminará ... tal vez, en el momento de su lanzamiento, simplemente no nos queda mucho tiempo.
En los juegos, hay un equilibrio entre la trama y la simulación, entre una historia preescrita que se encuentra en la mayoría de los juegos y la creación de un mundo profundo con un conjunto de reglas que permiten que surjan muchas historias diferentes. Diría que Dwarf Fortress es uno de los argumentos más serios a favor de la simulación. ¿Los personajes en la etapa de generar el mundo o durante el juego hacen algo que incluso te sorprenda? ¿Puedes dar algunos ejemplos interesantes / pegadizos?Sí, esto sucede todo el tiempo! Esto se debe en parte al hecho de que cuando juegas, es difícil tener en cuenta todas las reglas. Sin embargo, todas mis historias memorables son errores, porque rara vez tengo la oportunidad de jugar el juego durante un tiempo suficientemente largo, por lo que desde el punto de vista de la jugabilidad que ocurre independientemente, son de poco interés (incluso si me sorprenden). Se pueden encontrar buenas historias en foros, serpentinas, etc.
El límite entre lo micro y lo macro: ¿por qué lo hiciste así, entre lo que los gnomos pueden hacer ellos mismos y lo que el jugador ordena que hagan las fortalezas?Este es un equilibrio difícil, y no siempre es fácil de observar, pero en este momento el concepto es que el jugador es el "portavoz oficial de la voluntad de la fortaleza", y los enanos muestran autonomía, que debe estar presente fuera de sus funciones oficiales. Esto les permite ser actores en sus propias historias, que son la fuente principal de la narrativa emergente (emergente). Al mismo tiempo, el jugador debe poder controlar el flujo principal de su parte del juego (de hecho, esto no es crítico, pero a menudo es más interesante que observar la simulación).
Estos dos objetivos pueden entrar en conflicto, y esto a menudo se debe a que el jugador continúa disfrutando del juego; por ejemplo, si la palanca de emergencia realmente necesita ser bajada, entonces el sistema de prioridad de la tarea prácticamente puede hacer que el gnomo lo haga, de manera autónoma o no, dependiendo de si debe "saber" al respecto o no. En el pasado, tuvimos problemas para agregar demasiada burocracia cuando, por ejemplo, teníamos un enano de intendente involucrado en la entrega de equipos. Pero este sistema era demasiado lento, propenso a errores y jugadores confundidos. Es muy importante pensar en cómo cada mecánica de juego individual puede agregar historias potenciales, y el intendente casi no jugó ningún papel en esto.
¿Qué pasos toma el programa para construir el mundo?Ella asigna memoria para la tarjeta. Luego elige qué polo tendrá (por ejemplo, norte, sur) (o toma en cuenta los parámetros pasados por el jugador). La semilla del generador de números aleatorios establece los valores básicos de los campos del mapa (altitud, precipitación, temperatura, drenaje, actividad volcánica, vida silvestre) para una cuadrícula de tamaño variable, teniendo en cuenta varios parámetros (océanos, tamaños de islas, otra variabilidad), y luego el programa los llena fractalmente. El cambio de temperatura depende de los polos, y el programa selecciona puntos para los picos más altos. Aquí realiza el primer pase para ver cómo se realiza el proceso e intenta cambiar las alturas para que el mapa se ajuste a los parámetros deseados. En esta etapa, si el mundo no se puede corregir, se descarta y todo comienza de nuevo.
Luego se establece el primer campo derivado - vegetación - dependiendo de la altura, cantidad de precipitación, temperatura, etc. El programa verifica si los biomas corresponden a los intervalos especificados en los parámetros. En esta etapa, las alturas del nivel medio se suavizan para crear áreas más planas, y los volcanes se colocan de acuerdo con el campo de actividad volcánica.
Luego pasamos a la etapa de erosión y río. Los pequeños océanos se drenan, el programa encuentra los bordes de las laderas de las montañas desde donde puede correr ríos de prueba. Además, tiene una cámara en uno de ellos para que el jugador pueda seguir el proceso. Muchos ríos falsos fluyen desde estos puntos, rompiendo canales, si no pueden encontrar un camino hacia el mar. Las alturas demasiado altas a veces se aplanan para que todo el mapa no se convierta en cañones. Idealmente, sería necesario usar tipos de sustancias minerales para esto, pero hasta ahora no los estamos usando. Los lagos se cultivan en varios puntos de los ríos.
Las alturas se suavizan nuevamente desde las montañas hasta el mar, y para los picos y volcanes se realizan ajustes locales. Después de completar la creación de alturas, el programa realiza ajustes en la cantidad de precipitación basada en las sombras de lluvia y la precipitación en las regiones montañosas. En función de la altura y la precipitación, así como del efecto de restricción de los bosques, se restablecen las temperaturas, después de lo cual el programa utiliza los nuevos valores para finalmente establecer el nivel de vegetación. Los valores de salinidad se establecen para el océano y sus mosaicos vecinos.
Una vez decidido todo esto, ahora podemos encontrar los límites de las áreas finales de los biomas para darles nombres y personalidad. Aquí también agregamos capas geológicas y subterráneas, aunque, como se mencionó anteriormente, la información geológica debería haberse agregado antes. A continuación, el proceso de verificación final para el cumplimiento de los parámetros se lleva a cabo para asegurarse de que no nos desviamos demasiado de lo que el jugador quiere. Una vez terminado esto, el programa genera las poblaciones iniciales del mundo animal para cada región y establece las variables climáticas.
La historia misma comienza desde este momento. Luego se localizan civilizaciones y cuevas. Es bastante difícil explicar lo que sucede a continuación, pero la idea principal es que se simula un gran juego estratégico con cero jugadores con reglas de movimientos bastante arbitrarias y una IA pobre (pero con miles de agentes), en función de los cuales se escribe la historia. La generación procesal de historias usando el registro de simulación es un enfoque completamente funcional, pero también tiene sus inconvenientes. Esta es una gran cantidad de trabajo, es necesario realizar un procesamiento posterior y estudiar para encontrar buenos puntos que desee enfatizar, y si la dinámica y los mecanismos no son suficientes, entonces el resultado puede ser aburrido.
Lo que más me gusta de DF es que el juego no contiene ningún sistema explícito de puntos de golpe, todo lo relacionado con la fuerza y el daño del personaje es parte de un modelo complejo de partes del cuerpo. ¿Cuáles son las ventajas de tal sistema? Si alguien decide crear algo similar, ¿qué obstáculos pueden esperar?Este modelo crea momentos de trama más detallados, consecuencias a largo plazo y proporciona una mayor conectividad del sistema. Es fácil ir demasiado lejos, y realmente hemos ido demasiado lejos en algunos lugares, al menos en la etapa actual: algunas propiedades de los materiales no se utilizan en ningún otro lugar. Además, hay formas de mitigar el sistema, ejemplos de los cuales se pueden ver en juegos donde, por ejemplo, hay un grupo común de velocidad de obturación / energía / puntos de golpe, pero surgen heridas específicas como resultado de golpes críticos, o como consecuencia de alcanzar valores cero o cercanos a cero en el grupo. La elección correcta del sistema depende del juego. Nos esforzamos por usar los números lo menos posible, porque los números generalmente no encajan bien con las historias.
¿Cómo se ve el bucle principal del juego?Tomemos, por ejemplo, el modo gnomo. Comienza revisando anuncios y leyendo autoguardados, etc. La mayor parte del resto del ciclo no ocurre en todas las medidas. Por ejemplo, después de cada cien relojes, el programa verifica las tareas asignadas y los "estados de ánimo extraños". Los ejércitos se mueven por el mapa mundial. Después de cada cien relojes, el programa procesa las tareas asignadas a los enanos. Este es un tipo de subasta invisible que se utiliza para gestionar diferentes prioridades en conflicto. Cada diez tics cambian las estaciones, lo que afecta el clima y el mapa (tanto localmente como en todo el mundo), además de verificar el desarrollo de elementos de la trama (diplomáticos, asedios, etc.) y verificar que el fuerte aún esté vivo.
Luego, el programa toma lo que se hace en cada medida. Los movimientos de líquidos y otra información de los mosaicos del mapa cambian (sin embargo, hay varias optimizaciones para que no se verifique necesariamente cada mosaico en cada movimiento; además, hay banderas que le permiten omitir áreas enteras del mapa si no sucede nada en ellos). El movimiento de los depredadores se actualiza y procesa otros "eventos" del mapa, por ejemplo, incendios activos.
Si se establece la bandera, los gnomos heridos / sedientos / hambrientos que no pueden cuidarse reciben una actualización. Los gnomos muertos "piensan" en sus rituales funerarios para que estas tareas puedan asignarse a otros. Los seres encerrados en celdas y cadenas actualizan periódicamente sus pensamientos y situaciones.
Luego, si las criaturas cruzan los bordes del mapa, se eliminan de él.
Cada cincuenta medidas se actualiza la información de todas las tabernas, templos, bibliotecas, etc., dependiendo de otras medidas. Los suministros, que también dependen de otras medidas, funcionan de manera similar. Del mismo modo, la creación de tareas para el almacenamiento. A pesar de que este proceso se complementa con varias optimizaciones, todavía es bastante lento y en cierto punto más de 50 mil piedras pueden causar problemas.
Cada mil medidas, los objetos marcados para su eliminación del juego se eliminan realmente y se libera la memoria asignada para ellos. Esto ocurre más a menudo con objetos, una vez cada cincuenta medidas, así como también verificando el uso de edificios (básicamente, estas son actualizaciones para pozos y algunas otras banderas que deben verificarse con frecuencia).
A continuación, realizamos otra actualización que funciona en todos los sentidos. Los proyectiles disparados desde el arma se retiran. Las acciones (desde el entrenamiento de danza y artes marciales hasta la narración de cuentos) se actualizan según sea necesario. Los enanos y otras criaturas toman decisiones y realizan sus acciones instantáneas (moverse a una casilla vecina, trabajar en un taller, etc.): la parte principal de su IA (excepto para elegir tareas) se realiza aquí.
Cada cien medidas estropean los artículos. Se realiza cada medida de crecimiento de la vegetación (a pesar de que hay muchas dependencias y banderas). Si es necesario, el estado de los edificios se actualiza en cada medida y se mueven los carros. Avance en rutas de transporte. La temperatura se actualiza (hay muchos indicadores de optimización aquí, pero hasta ahora este es un proceso bastante lento).
Finalmente, la cámara se actualiza siguiendo a la criatura que el jugador está mirando.
Dwarf Fortress utiliza un mapa de mosaico basado en cuadrículas para representar el mundo, una forma simple y eficiente de representarlo. Noté que hay muchas maneras de dibujar fichas, y esto depende de lo que haga la criatura o cómo se sienta, cuántos elementos hay en la ficha, si hay algo encima, si la ficha está fluyendo agua o si está enterrada debajo de una piedra. Cuando DF decide cómo mostrar el mosaico, ¿qué hace? ¿Cómo optimizaste este proceso?Es solo un símbolo (byte) con unos pocos bytes más de color, por lo que el sistema no es costoso y podemos reemplazar la solución seleccionada antes de mostrarla en la pantalla, y no tratar de resolver todo al mismo tiempo, y para la mayoría de los mosaicos, solo un símbolo de tierra / pared es suficiente. El programa se ejecuta de abajo hacia arriba, en cierto sentido, utilizando la "altura" (las criaturas están por encima de los objetos, los objetos están por encima de la tierra), cambiando la decisión de vez en cuando. Sin embargo, a pesar de la presencia de varios indicadores y matrices auxiliares, se puede hacer mucho más. Hay una pequeña variedad de unidades posibles que se pueden mostrar en cada mosaico, por lo que el programa puede implementar una animación cuadro por cuadro que le permite ver cada elemento en el cuadro, incluso cuando el juego está en pausa.