Desarrollos en la tercera dimensión

Un de las decisiones más importantes cuando comienzas a desarrollar gráficos para Simutrans es qué método vas a usar: 3D o 2D. Sin desmerecer al resto, este artículo pretende romper una lanza a favor de 3D, y más concretamente al uso de Blender para la creación de objetos para Simutrans.

Leer más...
Este artículo es una traducción libre del original que aparece en el Blog de Zeno.

Usar software 3D para desarrollar gráficos para Simutrans tiene sus ventajas e inconvenientes. Vamos a analizarlos, a pesar de que personalmente apenas uso técnicas de pixel-art y hace mucho que no pinto nada con programas de dibujo, y en el caso de Zeno, nunca ha creado objetos usando herramientas en 2D.

Inconvenientes

Hay dos razones principales para no usar programas 3D:

• Tienes que aprender a usar una herramienta compleja.


• Tienes que aprender y practicar diferentes métodos de trabajo para crear gráficos.

Ventajas

Podemos destacar varias, algunas bastante interesantes:

• Puedes hacer cambios básicos en el objeto, por ejemplo reescalarlo, con relativa facilidad.


• Puedes reutilizar trabajos previos fácilmente, por ejempo versiones para diferentes mercancías, incluso para otros vehículos similares.


• Los modelos se pueden usar para diferentes paksets, o se pueden compartir con otros artistas gráficos.


• Gran parte del trabajo se puede automatizar: técnicas, renderizado, coloreado, etc...


• Trabajas con único modelo, sin importar el número de vistas que necesites.

Personalmente, comprendo que la gente tenga reparos hacia el software 3D por la dificultad de aprender y conocer una nueva herramienta. En realidad, creo que no es tan difícil como paree, pero debo admitir que no es del todo fácil. Por cierto, yo continúo aprendiendo nuevas técnicas básicas que no conocía tras dos años usando Blender.

Prissi, el gran jefe de Simutrans...

Hace tiempo ya charlamos con Hajo, el antiguo lider del Simutrans, y esta vez vamos a conocer más a fondo a la persona que está actualmente a cargo del proyecto, Markus "Prissi" Pristovsek.

Leer más...

Un poco de historia...

Primero, nos gustaría saber un poco más de ti ¿cuál es tu nombre real? ¿a qué te dedicas?
Me llamo Dr. Markus Pristovsek. Tengo cerca de 40 años, soy profesor adjunto de física aplicada (semiconductores) en la Universidad de Berlín (Alemania) actualmente. Berlín es también mi lugar de nacimiento y donde he pasado gran parte de mi vida. He estado dos años y medio en Japón, cerca de Tsukuba, donde también conocía a mi esposa, que es japonesa.

¿Cuándo te uniste al proyecto?
Bueno, en mi opinión, no se podría decir que te unes a Simutrans. Trabaje mucho para Simutrans cuando volví de Japón en 2003, incluyendo el pak.japan (tamaño pak64). En esa época, la inteligencia artificial solo escogía las locomotoras basándose en la potencia (960kW, 1920kW and 1280kW) y no podría manejar la electrificación. Le pregunté a Hajo, y me envió el fichero simplay.cc, intenté simplificar el sistema de elección e incluí el soporte para UTF-8, de mi diccionario de japonés del para PalmOS.

¿En qué momento asumiste el liderazgo del proyecto?
En 2005 yo era el único programador que quedaba. Yo nunca reclamé el liderazgo, solo programaba y si tenía tiempo, trabajaba en la mejora del pak64.

¿Cuál era tu relación con Hajo antes y después de asumir el liderazgo?
No much la verdad, sobre todo por correo elctrónico. Hajo me pasó todo bastante deprisa, antes de tomarse el largo descanso, pero aún estuvo colaborando otros dos meses más antes de dejarlo. En Febrero de 2004, yo, Hsiegeln y Dario éramos los únicos programadores que quedaban. Yo era el más productivo, aunque la mayor parte era por ensayo y error, y lo que es peor, el gdb no funcionaba en win98 y linux no funcionaba correctamente en mi PC - no tenía conexión de red.

¿Podrías hacer un breve resumen de los hitos más importantes en estos 12 años de Simutrans?
La verdad es que no, pero desde 2004 creo que podrían ser estos:

• soporte UTF8
• aviones (lo cual introdujo también la elección de parada)
• señalización basada en rutas
• climas
• interfaz extensible mediante scripts

En su mayoría son detalles de afinación e introducción de mayor flexibilidad, así como mejora del rendimiento; Simutrans ahora consume alrededor de una cuarta parte menos de recursos que la versión 88.10.5

Gestión y liderazgo

¿Te gusta Simutrans tal y como es ahora? ¿cuál es el rumbo que proyecto? ¿cambiarías alguna de las decisiones que tomaste en el pasado?
Simutrans está bastante maduro. Su código base es menos desastroso que hace cinco años atrás, y aún limpiando y depurando los últimos problemas sigue funcionando. En En retrospectiva, hubiera sido mejor si hubiera tenido más conocimientos de C++ cuando comencé a contribuir. Algunas de la aportaciones iniciales de código no son realmente buenas en absoluto.

Tener un juego maduro es difícil: por un lado no puedes hacer muchos cambios sin intentar no ofender a muchos jugadores. No puedes introducir muchas nuevas mejoras y características o los nuevos jugadores no superarán la barrera de la frustación. Pero el mundo cambia, y Simutrans también debe hacerlo. Así que estamos trabajando en el modo multijugador, y tal vez el 3D sean necesario para sobrevivir en el futuro.

El motor del juego está casi terminado. Actualmente estoy barajando la posibilidad de incorporar impuestos y tasas, lo cual convertiría la cuenta de resultados en un indicador útil del éxito. Esto podría mejorar la motivación a largo plazo y también podría ser muy útil para aumentar la competitividad del modo multijugador.

¿Sientes la presión con cada decisión que tomas? Como decía el abuelo de Peter Paker un gran poder conlleva una gran responsabilidad. ¿De alguna manera te arrepientes de haber tomado el mando? ¿qué es lo que te motiva para seguir trabajando en Simutrans?
Yo programo como un arte, asi pues hay una serie de objetivos y la cosa más bien depende de mi estado de ánimo, por ejemplo, si me apetece depuro, juego, perfilo, trabajo en el pakset o implemento nuevas cosas. Si me sintiese responsable de todo lo que hago, nunca haría nada. Las noches sin dormir tras la salida de las versiones estables casi han desaparecido, gracias al sistema de compilaciones nocturnas.

¿Qué criterios sigues para aprobar o descartar nuevas caracteríticas, aparte del sentido común?
No hay que subestimar el sentido común. Como reza la Navaja de Occam: descarta todo lo que no sea necesario para llegar al centro de la cuestión. El núcleo de simulación de Simutrans es mejor (o al menos más detallado) que cualquier otro juego de transportes. Cualquier cosa que añada más detalle, debe tener una recompensa equivalente. Además, las características difíciles de entender tampoco son buenas, ya que generan frustración en los nuevos jugadores y conlleva dar soporte perpetuo... Basta con recordar la famosa pregunta "¿por qué mi tren eléctrico no encuentra la ruta?" que se repitió cuando en los depósitos se pasó a mostrar las locomotoras y vagones eléctricos. Añadir nueva microgestión es sin duda un camino sin salida, ya que los juegos se hacen largos y complejos. Por otro lado, demasiada automatización puede matar el reto del juego. Es poco probable que la mejora gráfica sea incorporada, si no es por buenas razónes (como unir vía y velocidad en túneles). Por último, la reacción de la comunidad también me da impresiones de lo que gusta y lo que no.

¿Crees que a lo largo de todo este tiempo se ha formado lo que podría llamarse el estilo Simutrans, una estandar de lo que encaja y lo que no en el proyecto?
Hay una idea de "simutranidad" ahí fuera, la cual está en constante cambio y evolución.

Desde tu punto de vista, ¿qué es y qué no es Simutrans? por ejemplo, es un simulador de transportes pero no es un clon de TTD. Tampoco es un juego de gestión de ciudades.
Lo que Simutrans es y representa está en manos de la gente. Yo a veces lo uso como terrario electrónico, y admiro uno de esos deliciosos mundos complejos que crea la gente. Algunos lo usan para crear modelos ferroviarios. Creo que Simutrans da sobre todo mucha libertad: no solo trenes como TTD, no solo gráficos bonitos como Locomotion, no solo llanuras como Transport Giant. Es más fácil de modificar que cualquiera de ellos. Todo juego tiene sus ventajas, pero Simutrans no trata de superarlas todas, tan solo evita no restringir tu estilo de juego ni los gráficos que usas.

En porcentaje, ¿cuántas ideas se quedan fuera por falta de tiempo o soporte técnico?
Tal vez el 80% de las mías. Estoy lleno de ideas, pero muchas de ellas no superan el filtro o mueren por falta de tiempo (¿sabías que escribo relatos de ciencia ficción en alemán?)

Si pudieras, ¿le dedicarías más tiempo al proyecto?
Preferiría dedicarle más tiempo a mi familia y a otras cosas como escribir, leer, ir en bicicleta o tocar la guitarra...

Has dedicado mucho tiempo y esfuerzo, pero esto no deja de ser mas que un hobby ¿desde ese punto de vista, lo ves también como un segundo trabajo?
En el momento en que lo vea así, lo dejaré.

Dedicas la mayor parte de tu tiempo a programar. Recientemente se han unido al projecto nuevos programadores como Dwachs o Knightly, colaborando con parches y modificaciones. ¿Cuántos programadores activos forman parte del equipo de desarrollo en este momento?
Knightly y Dwachs. Honestamente, Knightly es brillante, en mi humilde opinión es mucho mejor que yo. Dwachs aprendió programación de forma adecuada (creo), mientras que you fuí autodidacta (comencé en 1984 con Pascal y un manual de programación, dos años después de comprarme el ordenador... )

Alguien en el foro comentó que no se puede saber que está pasando en la trastienda del equipo de desarrollo. No hay formas de conocer o ponerse en contacto directo con ellos, para intercambiar ideas ¿Hay realmente una comunicación interna o cada uno trabaja por separado y después se ponen en común las ideas a través del foro internacional?
Esto es un hobby. Forzar a alguien a trabajar en algo acabaría con ello, pero muy recientemente ha surgido un rincón del programador, donde hay un pequeño intercambio de ideas en la sombra. De todas formas, cerca del 80-90% se produce a través del foro, siendo visible a todos.

Simutrans experimental

Hablemos ahora sobre Simutrans Experimental (SE). No te pediré un análisis técnico pero me gustaría que nos dieras tu opinión acerca de lo que crees que ha aportado o puede aportar al proyecto de Simutrans..
Los proyectos de código abierto tiene estas cosas, así que SE es un derivado. Veamos como va creciendo la cosa. Sin duda, tiene una curva de aprendizaje más pronunciada que el Simutrans estándar.

Obviamente, Simutrans y SE son incompatibles aunque comparten elementos comunes en cuanto a código, pero si fuese posible ¿qué cosas de SE te gustaría incluir en la versión estandar de Simutrans?
Ya que SE incluye en su mayoría parches y modificaciones rechazadas para la versión estandar, yo diría que casi nada.

De desarrollador a jugador

Con tantas cosas que hacer, además de tu vida personal, ¿realmente tienes tiempo para jugar a Simutrans?
No, una vez al mes o a veces en congresos y seminarios.

A veces, no jugar al juego que estás desarrollando te hace perder el punto de vista del jugador(ocio y diversión) para aislarte en el punto de vista del programador(trabajo) ¿Compartes este punto de vista?
Por supuesto. Es por esto que llevo a cabo sesiones de juego una vez al mes (habitualmente una partida bien desarrollada). De esta manera surgieron los semáforos con estados personalizables.

¿Realmente te diviertes jugando a Simutrans como cuando solo eras un jugador más?
Si; también me divierto con TTD, pero a la media hora me aburre, mientras que Simutrans me entretiene durante mucho más tiempo.

¿Has probado alguno de los nuevos pakset como pak96.comic, pak192.comic o pak.german? ¿te gusta el estilo gráfico, la economía y el equilibrio del sistema de juego?
El pak.german era mantenido y empaquetado por mi antes de que lo dejara por falta de tiempo. No podía dibujar nada ni aunque mi vida dependiera de ello.

Sobre el pak96.comic, me gustan los edificios de Alexander Brose (echad un vistazo a la entrevista del blog alemán de Simutrans). No estoy muy satisfecho con el equilibrio y la elección de vehículos, pero han pasado unos meses desde que lo probé. Cualquier tamaño mayor de 96 es muy grande para mi gusto. No me gusta el pak128, muy complejo y con una economía desequilibrada, demasiados vehículos, camiones de poca capacidad...

Como jugador, ¿qué es lo que más te gusta y lo que menos te gusta de Simutrans?
Me encanta la profundidad de la simulación y no me gustan los gráficos (no en el caso del pak96.comic), mal soporte de sonido y fuentes de letra demasiado pequeñas para monitores grandes.

También gestionas el pakset ofical de Simutrans, el pak64, que crece despacio pero seguro añadiendo nuevos elementos. ¿Qué destacarías de este pakset frente a otros más o menos pujantes en este momento? ¿qué crees que le falta?
Consistencia, pero es difícil de conseguir tras 10 años de desarrollo...

Bueno, creo que ha sido una interesante entrevista donde Prissi ha dado su punto de vista sobre aspectos poco conocidos del desarrollo de Simutrans. Espero que os haya gustado.

Simutrans más difícil todavía

A veces llegas a un punto en el que crees dominar Simutrans totalmente. Te sabes todos los trucos y consigues dinero de forma fácil y rápida sin apenas esfuerzo ¿qué hacer entonces? ¿existe un modo pesadilla en Simutrans? ¿como consigo que Simutrans me siga atrayendo y proponiendo nuevos retos?
Leer más...
Esto es más o menos un resumen de lo comentado en el foro, por jugadores experimentados acerca de como aumentar el nivel de dificultad de Simutrans. Muchas de las soluciones están relacionadas con el archivo simuconf.tab que contiene los parámetros de configuración del juego, por tanto basta con cambiar los valores de algunos de dichos parámetros. Otras soluciones se basan en probar nuevos paksets u objetos.

Vamos allá con la lista de recomendaciones para añadir algo de complejidad extra a Simutrans:

• Aumentar los costes de mantenimiento, a través de simuconf.tab, para pagar más por las infraestructuras (carreteras, vías, canales, etc..) y las acciones básicas (modificación del terreno, demolición, reforestación)


• Usar determinados paksets más equilibrados como el pak.german, donde el sistema economico está más ajustado y las ganacias se producen a largo plazo, con necesidad de gran inversión inicial.


• Aumentar el pago por distancia total, modificando el parámetro pay_for_distance_total=2, lo cual elevará el gasto si la distancia total recorrida por las mercancías es muy grande. A mayor distancia, mayor coste y menos beneficio.


• Usar Simutrans-Experimental junto con Pak128.Britain-Ex, donde es más difícil obtener beneficios respecto a la versión estandar, sobre todo si se inicia una partida a partir de 1830-1870.


• Usar mapas rectangulares en vez de cuadrados, por ejemplo 256x4098, esto conllevará la creación de complejas redes de transporte cuyas rutas tendrán que evitar densos núcleos de población.


• Usar el modo principiante (beginner mode) para reducir los beneficios a la mitad, modificando los parámetros beginner_price_factor = 500 y first_beginner = 1

En mi opinión, el mejor consejo es el de la forma de los mapas, algo que parece que no influye hasta que te pones a construir en zonas estrechas sin margen de maniobra y al final el terreno acaba con más agujeros que un queso de gruyer.

Tenéis más información sobre el tema aquí.