Simutrans por un puñado de dolares

Tras unos meses de inactividad, ya estamos de vuelta con una curiosa noticia. Simutrans, un juego de codigo abierto y gratuito se vende en ebay por un puñado de dólares, algo sorprendente cuando Simutrans es libre y gratuito...
Leer más...
Antes de todo, hay que decir la licencia de Simutrans (Artistic License) no permite vender el juego por dinero y tampoco permite cobrar los gastos de envío, pero si se puede cobrar por el soporte en que se distribuya el juego. Además, esta empresa está distribuyendo también los paksets, algunos de los cuales tienen su propia licencia que establece claramente que no pueden ser vendidos por cantidad alguna de dinero. Aquí tenéis los extractos de la licencia donde se menciona el aspecto del cobro:

* "Package" refers to the collection of files distributed by the
Copyright Holder, and derivatives of that collection of files
created through textual modification.
...
* "Reasonable copying fee" is whatever you can justify on the
basis of media cost, duplication charges, time of people involved,
and so on. (You will not be required to justify it to the
Copyright Holder, but only to the computing community at large
as a market that must bear the fee.)
* "Freely Available" means that no fee is charged for the item
itself, though there may be fees involved in handling the item.
It also means that recipients of the item may redistribute it
under the same conditions they received it.
...
1. You may make and give away verbatim copies of the source form of the
Standard Version of this Package without restriction, provided that you
duplicate all of the original copyright notices and associated disclaimers.

...

5. You may charge a reasonable copying fee for any distribution of this
Package. You may charge any fee you choose for support of this Package.
You may not charge a fee for this Package itself. However,
you may distribute this Package in aggregate with other (possibly
commercial) programs as part of a larger (possibly commercial) software
distribution provided that you do not advertise this Package as a
product of your own.

Primero se establece lo que es un paquete de software(Package) y que significa exactamente cargo razonable por copia(Reasonable copying fee) y disponible de forma gratuita(Freely Available). El primer término implica que puedes cobrar una cantidad razonable por los costes de distribución y el segundo explica que no puedes cobrar por el producto en si mismo, pero si de las actividades derivadas de su manipulación (almacenamiento en soportes físicos como CD o USB, por ejemplo)

El primer punto de la licencia permite distribuir copias del software incluyendo todos los documentos relativos a licencias y copyrights. El quinto punto establece claramente que puedes cobrar por el soporte en que vas a distribuir la copia, pero no puedes cobrar por el software en si mismo. También establece que puedes incluirlo en compilaciones de software siempre que no lo presentes como una creación propia.

La empresa en cuestión cobra $7 dolares por grabar el juego en un CD. Además esta compañía ofrece "100% satisfacción garantizada" y por el resto de artículos que ofrece, me parece mucha casualidad que en su mayoría sean juegos o programas de software libre (Torcs, Freecol, Glest, Scorched 3D) De hecho, hacia el final menciona que tiene derecho a vender y comerciar con estos juegos apelando a que están bajo la licencia GPL o MPL.

Ya se ha mandado varios avisos y notificaciones a ebay para que lleve a cabo las acciones pertinentes, y de momento la contestación ha sido que investigarán el posible fraude o infracción, pero nada mas.

Parece que la solución pasa por ofrecer el mismo artículo por $0 y advertir que se puede descargar de forma gratuita en la página oficial. Otra opción de cara al futuro sería registrar la marca Simutrans para que no pueda ser usada, algo parecido a registrar un dominio en Internet.

Enlace a las ofertas de Simutrans en ebay.

Crecer, reproducirse y urbanizar

En muchas ocasiones no nos damos cuenta de la cantidad de algoritmos y fórmulas que subyacen bajo la mecánica de juego de Simutrans. Desde fórmulas estadísticas hasta algoritmos de cálculo de rutas, grafos y diferentes mecanismos de optimización. Uno de los aspectos donde se hace un uso intensivo de elementos de este tipo es en la generación de los mapas. Hoy vamos a hablar un poco de la generación de las ciudades y su tamaño.
Leer más...

Hace poco se abrió un discusión sobre el tema de tamaño de las ciudades que se generan al inicio de un mapa de Simutrans. Inkelyad, un miembro reciente de la comunidad de Simutrans, sugirió que el tamaño de las ciudades debería seguir una distribución basada en la Ley de Zipf

Puede parecer un tema secundario, pero es más importante de lo que parece, ya que el tamaño de ciudades condiciona muchos de los otros elementos del mapa. Desde el emplazamiento de las ciudades y las industrias, hasta el tamaño de las mismas, las necesidades energéticas del mapa, etc...

La ley de Zipf está más relacionada con el campo de la linguística, pero se aplica también a otros campos cuando se contempla el aspecto de las frecuencias. Esta ley viene a establecer la frecuencia de los elementos de un determinado conjunto, en este caso el conjunto es los distintos valores de los tamaños de las ciudades.

En definitiva viene a decir que en todas las lenguas conocidas la longitud de las palabras es inversamente proporcional a su frecuencia de aparición (cuantas más veces aparece una palabra en un idioma, más corta es)

Aplicando esto a la generación de ciudades, se podría formular como que el tamaño de las ciudades es inversamente proporcional a la frecuencia de aparición de su población. Es decir, cuanto más grande sea la ciudad, menos debería aparecer.

Aquí podéis ver una comparativa de la desviación de los tamaños de las ciudades respecto de la media usando la distribución Zipf y la estandar.



Para cantidades pequeñas de ciudades (menos de 15), ambas distribuciones se distancian bastante de la cantidad media que se supone, tendría que tener el mapa. Sin embargo, a medida que aumenta la cantidad, ambas distribuciones se acercan a la media teórica y prácticamente generan distribuciones y tamaños parecidos. En otras palabras, la fórmula estandar que usa Simutrans es bastante parecida a la distribución Zipf, incluso mejor en casos puntuales.

En esta otra serie de imágenes podéis ver los gráficos de barras que muestran la cantidad de ciudades por tamaño que se generan con distintas variaciones de la distribución Zipf y la estandar de Simutrans.



Como podéis observar, la fórmula estandar tiende a crear más ciudades pequeñas que grandes, mientras que la fórmula Zipf en sus distintas variantes tiende a crear más ciudades de tamaño medio y grande. En cierto sentido, la distribución Zipf tiene a ser más equilibrada en la generación de ciudades, pero eso también puede reducir las posibilidades de desarrollo del mapa. Si las ciudades ya están muy desarrolladas y tiene mucha población, el margen de crecimiento es menor y por tanto el mapa tendrá menos atractivo y potencial.

Aún se están afinando los detalles del algoritmo y la posibilidad de que aparezca como opción configurable a través del interfaz. Además, es posible que se incorpore primero a Simutrans Experimental antes de pasar a la versión estandar, para observar como se comporta y si gusta a los jugadores. En el hilo del foro tenéis un parche disponible. Personalmente creo que este tipo de discusiones son muy instructivas y muestran al resto de la comunidad que Simutrans no es solo gráficos, también hay una parte matemática muy interesante y que aún puede mejorar.

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.