Fallos épicos de Simutrans

Todo proyecto, y más si se trata de software, tiene algún fallo de los que denominan épicos por inesperados y catastróficos. Muchos recordareis las famosas pantallas azules de la muerte en Windows, por ejemplo. Pues bien, Simutrans tampoco ha sido la excepción a esta situación y ha tenido su epic fail..

Leer más...

No son pocos los que lo han sufrido en algún momento de alguna de sus partidas, y más si han osado rotar el mapa. Esta característica apareció no hace mucho, y ciertamente no sé hasta que punto es usada habitualmente por la gente, pero si usas la versión 102 deberías tener mucho cuidado..

"Cometer un error y no corregirlo es otro error" Confucio

El error en cuestión tiene que ver, como ya hemos dicho anteriormente, con la rotación del mapa. Resulta que en la versión 102, si rotas 90º o 270º un mapa que no sea cuadrado y a continuación salvas la partida, Simutrans no guarda correctamente las coordenadas de los distintos elementos y después no sabe como leer esos datos. Y entonces ocurren cosas como estas...



Con suerte, parece que la cosa ha sido felizmente solucionada en las últimas versiones de compilación nocturna, disponibles en nightly.simutrans-germany.com y serán incorporados en breve a las versiones estables.

De todas formas, si alguno sufre este problema, en el foro los chicos del equipo de desarrollo os pueden arreglar la partida, y como última solución podeís no intentar rotar el mapa.. :P

Simutrans, connecting people..

Por todos es sabido que Simutrans se ofrece tanto para distintos sistemas operativos como Windows, Linux o Mac, hasta diferentes arquitecturas como PPC, x86 y algunos hasta han conseguido ejecutarlo en plataformas de 64 bits, pero esto va un poco más allá.

Leer más...

Hace tiempo ya apareció en el foro un usuario que estaba trabajando en un port de Simutrans para el iphone, y si mal no recuerdo hizo algunos progresos pero nunca mostró imágenes. Pues bien, hace poco otro usuario del foro Internacional de Simutrans llamado helifino, colgó esta imagen de Simutrans v100 corriendo en su Nokia N810 con arquitectura ARM y sistema linux propio (maemo)

Imagen cortesía de helifino, desde su galería de Flickr

Debe ser genial poder jugar en el metro o en el autobús, o en los descansos de clase o el trabajo a Simutrans. Lo malo, según dice helifino en el foro, es que la pantalla táctil al ser tan pequeña, los botones del interfaz apenas se pueden usar y terminas tirando del teclado...supongo que en parte se debe a que no hay un pakset adaptado a este tipo de dispositivos. Bueno existe el pak32, pero no es jugable... P

¡¿Alguien me puede dejar su HTC, iphone o similar para trastear?!

La importancia de llamarse Instalador

Si os dijeran que es lo más importante en un juego, seguro que para muchos la respuesta sería los gráficos, la historia o la mecánica de juego. Sin embargo hay una parte muy importante que habitualmente no se menciona: la accesibilidad, entendida como la facilidad del usuario para acceder al juego.

Leer más...

Solemos partir premisa de una premisa, a veces errónea: los usuarios tienen los conocimientos suficientes como para instalar el juego. Personalmente no creo que instalar Simutrans sea complicado, solo tienes que descomprimir dos archivos zip, pero parece que hay gente que eso le resulta muy complicado. Por esto, a lo largo de estos años han surgido varios proyectos en este sentido, el último que ha encendido nuevamente la mecha es STIUP (Simutrans Installer UPdater) auspiciado por Aglezabad continuando el trabajo inicial de Frank Penz.

La postura oficial es no ofrecer instalador, por una serie de razones que Prissi, el lider del proyecto, ya ha expuesto en el foro Internacional, pero en principio no está en contra de que existan proyectos satélite que cumplan dicha función. A tenor de lo leído en el foro, está clara la necesidad de hacer algo en este sentido, pero antes hay que tener en cuenta varios aspectos y factores.

Un aspecto importante, que condiciona el proyecto, es el modo del instalador: offline u online. Esto quiere decir si el instalador descargará los ficheros necesarios para jugar con Simutrans o será el jugador quien los descargue y se los suministre al programa. La situación ideal sería tener disponibles ambos modos, que en el fondo no difieren mucho, ya que la finalidad de proceso es la misma: el instalador es el que se encarga de descomprimir e instalar los archivos. Es más, debido a algunos problemas que trataremos a continuación, es casi imprescindible que funcione de ambos modos.

En los primeros proyectos de instalador, como SimuSetup de Robofish, el modo de trabajo era online, es decir, el instalador descargaba los ficheros y los instalaba para el usuario. Esto no suponía conflicto entre las licencias del instalador y de los archivos de Simutrans, ya que no se suministraban dichos archivos en conjunto con el instalador sino que este último solo los manipula. Esto implica que su licencia no tiene por qué ser compatible con la licencia de Simutrans.

En la siguiente etapa de diseño, se partío de la idea de suministrar el instalador y los archivos de forma conjunta (offline), pero el problema surgió debido a que Simutrans es compatible con la GPL, y eso implica que si distribuyes todo el paquete, en teoría esto fuerza a que el código del instalador deba ser de libre acceso. En principio no habría problemas, porque el liberar el código permite que otros puedan continuar el proyecto pero trae problemas en las etapas iniciales.

Además, apareció otro problema adicional: la incompatibilidad de licencias entre los distintos paksets. El pak64 está bajo licencia AL v1.0, al igual que el pak96.comic pero el pak128 aún está en proceso de liberalización, esto implica que aún contiene elementos que no se pueden liberar debido a que no se tiene permiso del autor. Por tanto, en caso de querer crear un paquete con instalador todo en uno, habría problemas para ofrecer todos los paksets disponibles.

Otra de las facetas a considerar es la tecnología usada para implementar este proyecto de instalador. Existen varias opciones como Inno setup, MSI, NSIS o crear tu propio instalador con Delphi, por ejemplo. Cada uno tiene sus ventajas e inconvenientes. Inno es más sencillo de implementar, NSIS ocupa muy poco, MSI da una mayor compatibilidad y la solución casera puede aunar todas pero implica un desarrollo desde cero, lo cual es más costoso. No sé cual de las opciones será la ganadora, y desconozco si se pueden combinar las distintas opciones pero supongo que será necesario hacer bastantes pruebas antes de tomar una decisión.

Por otro lado, hay un punto fundamental que puede pasar desapercibido, y que se ve influido por otros aspectos; el tamaño del instalador. Está claro que el usuario no se bajará un archivo de 60 MB, aunque todos los ficheros que contenga estén comprimidos. Incluso hay quien dijo que sobrepasar los 19 MB estaba fuera de los límites tolerables para el usuario. Lo ideal sería un fichero 1 o 2 MB, que contenga unicamente el código del instalador, descartando incorporar el resto de ficheros relativos a Simutrans. El instalador debe ser simple, manejable y rápido de descargar.

En resumen, el instalador es necesario, pero es un proyecto en el que aún quedan muchas cosas que discutir. Esperemos que la comunidad lleve a buen puerto el instalador y se pueda mejorar la experiencia del usuario con Simutrans.

De propina, os daremos una primicia. Un pajarito nos ha chivado que Frank ha preparado un CD de Simutrans con todos los paksets existentes y jugables para Simutrans (ppak64, pak128, pak.german, pak128.japan, pakHajo, etc..) pero no está disponible de cara al público por los motivos anteriormente expuestos. Esperemos que en un futuro la situación cambie.. :)

Voy despacio, pero jamás desandando lo andado.

Con el crecimiento de la comunidad de Simutrans en estos últimos tiempos hay mucha gente que se ha animado a crear nuevos objetos, pero como muchas veces ocurre, se tienen muchas ideas y poco conocimento. Es totalmente normal ya que las ansias por crear muchas veces no nos dejan ver posible complejidad de la tarea. Por esto, vamos a dar algunos consejos acerca de qué tipos de objetos son más adecuados.

Leer más...

Con esto no quiero asustar a nadie, sino dar una visión general para que la gente se dé cuenta de que hay montañas muy altas, y a veces sin la preparación adecuada es mejor empezar por colinas.

En principio, cualquiera pueder hacer de todo, pero si tuviera que dividir y clasificar de menos a más dificil, todos los objetos de Simutrans, la lista sería la siguiente:

• Vehículos


• Objetos del sistema (menus, apariencias, cursores)


• Otros (arboles, humo, peatones)


• Edificios


• Carreteras/Paradas

En este esquema podeís observar los distintos tipos y subtipos de objetos organizados según su complejidad, de dentro(más facil) hacia afuera(más difícil)



Los vehículos son uno de los objetos más fáciles de crear. En el peor de los casos, necesitan de 16 imágenes (carga y descarga) por lo demás, los atributos son prácticamente iguales para todos los vehículos. Más que complejidad, los vehículos requieren sobretodo mucho dibujo.

Los objetos del sistema son ligeramente más complejos, pero gráficamente necesitan de pocas imágenes. Los cursores y botones del menú solo requieren dos imágenes, y para las apariencias (skins) es necesario dibujar los botones. En cuanto a los archivos dat, tal vez el menú sea lo más complejo, ya que hay que indicar la ubicación del nuevo botón.

Por último, los objetos tipo terreno requieren un ingente trabajo gráfico, ya que es necesario dibujar todas las posibles representaciones de una cuadrícula con todas sus orientaciones (S-SE-E-NE-N-NW-W-SW) sus variaciones a media altura y demás. Es una tarea bastante laboriosa.

En la categoría de otros se agrupan todos esos tipos de objetos que no encajan en ninguna de las otras categorías. El principal obstáculo de desarrollar objetos de esta categoría, es que son completamente diferentes entre sí. Tienen sus propios formatos e imágenes necesarias, y lo que vale para uno, no suele valer para el resto. Los peatones, objetos móviles y el humo son practicamente iguales, mismo número de imágenes necesarias pero distinto tipo de atributos. Los pasos a nivel necesitan de menos imágenes pero se basan en dos animaciones (abierto, cerrado) y necesitan de imagen frontal/trasera. Por último los árboles necesitan de 4 representaciones de distinto tamaño por cada una de las estaciones del juego (primavera, verano, otoño e invierno)

A continuación vamos con los edificios. El principal obstáculo de este tipo de objetos no es la parte gráfica, ya que en la mayoría de los casos basta con dibujar una vista (Sur o Este) sino que suelen ser edificos grandes, que ocupan más de una cuadrícula, requieren de pequeños detalles, y la creación del fichero dat depende de varios atributos, sobre todo en el caso de las fábricas. En otros casos es necesario crear más de un objeto para que el edificio tenga sentido, me refiero a las cadenas industriales. De nada sirve crear una central lechera si no creas una granja, un supermercado y los distintos vehículos para llevar la leche de un lado a otro. Esto implica que lo que iba a ser un solo edifico se convierte por necesidad en al menos 4 o 6.

Por último, hablaremos de los objetos tipo vía/parada. Los túneles son los más sencillos, en todos los aspectos. Pocas imágenes y atributos. Las paradas y estaciones son más o menos sencillas también. Dos vistas con imagen frontal y trasera, cursor y botón, eso es todo. Las carreteras y vías, requieren bastante trabajo gráfico ya que requieren unas 32 representaciones sin contar con las versiones de invierno. Lo más complicado es sin duda los puertos y los puentes, especialmente estos últimos. Gráficamente necesitan varias representaciones distintas, con imágenes frontales y traseras, pilares, inicios y fines llanos y en cuesta (en subida o bajada) y todo esto unido a un fichero dat lleno de particularidades. Un trabajo titánico, si se empieza desde cero.

Y esto ha sido todo. Espero que esta pequeña guía os sirva para ayudar a decidir por donde hincar el diente al desarrollo de objetos para Simutrans.