JimsViewer, el destripador

Comenzamos el año con el descubrimiento de otra interesante herramienta en las catacumbas de la comunidad de Simutrans. Esta vez ha sido en la sima del foro alemán de Simutrans y el afortunado ha sido bautizado como JimsViewer, el destripador de paksets.

Leer más...

Tengo que confesar que el conocimiento de esta herramienta me llegó gracias a un soplo de Frank, que también es administrador del foro alemán de Simutrans. La herramienta en cuestión se llama JimsViewer y es obra de Jim Knopf. Está disponible unicamente para windows 95/98/XP pero posiblemente se pueda usar en Linux mediante Wine.

El programa es básicamente un editor/visor de la información contenida en los ficheros pak del pakset. Carga la información extraída y permite clasificarla, ordenarla y filtrarla. Además muestra estadísticas y te permite visualizar las cadenas industriales en forma de árbol, con productores, intermediarios y consumidores, vehículos y mercancías implicadas. Todo bastante claro e intuitivo.

Entre las futuras mejores que se preveen incorporar en el futuro está la ordenación avanzada de los datos, visualización de los contenidos gráficos, representación gráfica de las cadenas industriales con control de factibilidad, bocadillos de información y presentación sencilla de estructuras de datos complejas como los waytype.

Aunque ahora mismo solo funciona en modo visor, en mi opinión puede llegar a ser una herramienta muy útil para los diseñadores de paksets, y en general para aquella gente que gusta de analizar las cifras para conseguir el máximo rendimiento de todos los elementos de los paksets en sus partidas. Habrá que estar atentos a las nuevas versiones.

Podeís descargarlo aqui y teneís la traducción al español aquí.

Hay un largo camino hasta la cima

No se puede negar que últimamente, digamos desde hace un año, la popularidad de Simutrans ha aumentado notablemente. Hay más usuarios y más descargas, lo cual nos permite abordar nuevos proyectos y consolidar algunos ya existente. La pregunta es ¿conocemos realmente cuan relevante es Simutrans? La respuesta y las cifras a continuación.

Leer más...

Una forma de saber la popularidad y relevancia de algo, es comparándolo con otro elemento similar que esté más consolidado. En el caso de Simutrans, el archienemigo siempre ha sido Open Transport Tycoon Deluxe (OTTD) un clon libre del afamado Transport Tycoon. Lo que hemos hecho en Escala Real es hacer una comparativa en terminos de búsquedas en google de ambos videojuegos. Estos son los resultados desde 2004 hasta hoy.



Como podeís comprobar, OTTD siempre ha estado por encima de Simutrans, ya que al estar basado en un famoso juego comercial, está más asentado y aceptado por los jugadores.

En el periodo 2006-2008 la distancia entre OTTD y Simutrans ha ido creciendo al inicio y decreciendo al final, y aún así Simutrans siempre se ha mantenido más o menos constante, entorno al 30-40%, lo cual indica que el potencial de crecimiento es enorme.



En cuanto a las zonas del mundo de donde provienen más búsquedas sobre Simutrans, es curioso comprobar que casi coinciden con aquellas comunidades más activas en Simutrans. Tenemos Alemania, Japón, República Checa y Eslovaquia, Brasil y sorprendentemente Finlandia. En general, se puede decir que el juego de momento interesa más a los europeos. Es curioso que al ejecutar la simulación de tiempo, a partir del segundo trimestre de 2007 hasta final de año, en Alemania se produjo un aumento del 100% en las búsquedas, posiblemente motivado por la salida del pak.german entre otros. Después en los primeros trimestres de 2008 y 2009, en Japón se produjo un aumento similar, lo cual no se explica mucho ya que a pesar de que la comunidad japonesa ha hecho grandes aportaciones al juego, estas son anteriores a dichas fechas. Parece que la gente de pronto recuperó el interés ante las nuevas versiones del juego que salieron en esas fechas.

Entre los términos más buscados en relación con Simutrans están download(descarga), cheats (trucos), simutrans 2(el ferrocarril contraataca), online (la gente como siempre loca por el modo multijugador). Es curioso encontrar el término descargar simutrans en español entre los diez más usados, lo cual indica que si hay gente hispano parlante interesada en el juego.

¿Y cual es la conclusión de todo esto? Pues podríamos decir que Simutrans tiene aproximadamente el 30% del "mercado", y parece que seguirá así a lo largo del año que viene. Quién sabe si cuando salga el ansiado modo multijugador, sirva esto como espaldarazo definitivo que lo propulse a la cima de la popularidad entre los simuladores de transporte.

Podeís consultar todos los datos en Google trends

¡Escala Real os desea feliz navidad!

Como veo que es costumbre felicitar la navidad en todos los blogs, en Escala Real no íbamos a ser menos. Que todos tengaís una feliz navidad, con mucho amor, descanso, regalos y felicidad junto a vuestros seres queridos.

Y como esto último ha quedado un poco cursi, os dejo una imagen de lo que no debeís hacer en Nochevieja si os poneís al volante tras un par de copas.

¡¡Felices fiestas a todos, y feliz 2010!!

En la energía verde está la solución.

Como ya sabreís, últimamente estoy jugando a un reto con el pak128, y me he dado cuenta de una importante carencia que tiene el pakset. Solo hay una central energética que funciona sin materias primas, carbón o petróleo, que se corresponde con el aerogenerador. Vamos a analizar un poco como influye esto en la economía y jugabilidad del pakset, así como algunas posibles soluciones.

Leer más...

La electricidad en Simutrans se usa para estimular la producción y el consumo de los distintos elementos de las cadenas industriales.

No he llegado a corroborarlo completamente pero tengo la sospecha de que algunas de las cadenas del pak128 no están adecuadamente equilibradas en cuanto a producción y consumo. Esto no es un problema tan grave ya que en gran medida depende de cuantos elementos de la cadena tengas en la partida, pero si hay una descompensación como por ejemplo, más productores que consumidores, las paradas se saturarán a no ser estimules el ritmo de consumo de la parte final de la cadena (consumidor final)

Por tanto la cuestión es que casi todas las cadenas industriales de producción de energía eléctrica en el pak128 depende de materias primas como carbón y petróleo, y si no hay minas o pozos, o no quedan cerca de las centrales se hace muy difícil producir energía eléctrica.

Esto se traduce en una dependecia, en un círculo vicioso, donde para hacer uso intensivo de materias primas (consumo o producción) debes producir energía eléctrica, pero a su vez necesitas dichas materias primas para producir electricidad.

La solución es muy simple: hacer uso de centrales de energía "verde", es decir, aquellas centrales que no necesitan de materias primas para producir electricidad. Lo mejor es que esto ya se ha llevado a cabo en otros paksets, especialmente en el pak64 donde de las ocho centrales energéticas disponibles, seis de ellas son de energías renovables (solar, térmica y geotérmica) y funciona a las mil maravillas. La economía no se resiente tanto como puede parecer a primera vista. La electricidad es algo más fácil de conseguir por parte del jugador y esto conlleva aumento de producción en casi todas las fábricas de los mapas, sin necesidad de recurrir al servicio público ni al editor de mapas para acceder a las fuentes de generación de electricidad.

Esta son algunas de las fábricas que se podrían crear:

• Centrales solares: En el pak64 disponen de hasta 4 tipos diferentes con distintos tamaño y ritmos de producción. De menor a mayor producción, tienen la huerta solar, central solar con heliostato, la torre solar y la torre solar térmica. Si se quiere ser realista, estas solo deberían aparecer en climas cálidos, donde se supone que hay más días de sol. Otro detalle curioso para los creadores de gráficos es que se pueden hacer animaciones relacionadas con los ciclos dia-noche del juego.


• Centrales geotérmicas: se pueden ubicar en climas fríos o calientes, y su ritmo de producción de energía es de nivel medio, aproximadamente equivalente a un pozo petrolífero.


• Centrales hidroeléctricas: la prinpical ventaja de este tipo de central es que a nivel realista, se puede colocar en casi cualquier clima del juego, pero a nivel gráfico suele encajar mejor si hay ríos cerca. Otra ventaja es que la capacidad de producción puede ser variable en función del tamaño, aún así se podría considerar una central de tamaño medio en cuanto a producción de electricidad. Diegote ya hizo una central de este estilo que se podría aprovechar.


• Centrales mareomotrices: este tipo de centrales generan energía eléctrica a partir de las mareas y las olas, situándose preferentemente en la costa. Y es ahí donde radica la principal dificultad, ya que no sé si se puede forzar a que el motor del juego coloque una fábrica en la misma costa, con parte de ella en el agua. Sería una opción interesante.

No hemos hablado de otras tecnologías mixtas como centrales de biomasa, ya que requieren de basura, o molinos de viento en alta mar, ya que en Simutrans no se puede transportar energía electrica bajo el mar, al menos de momento.

Espero que esto os haya dado algunas ideas para futuros proyectos, y quien sabe si con un poco de suerte incluyen alguna de estas centrales en el pak128, sobre todo para mejorar la jugabilidad y porque no, dar algo más de variedad al parque energético del pakset.

Referencia: Wikipedia: Energías renovables
Imágenes cortesía de la wikipedia.

De vuelta al juego (I)

En el foro hispano de Simutrans, Derajjared ha lanzado un nuevo reto en forma de juego colaborativo. Es para el pak128 y yo, aunque soy más del pak64, me he apuntado al tema, más que nada para recuperar esas sensaciones de cuando jugaba más a menudo a Simutrans. Así pues voy a ir contando la experiencia de un veterano que se reencuentra con su amado juego.

Leer más...

La verdad es que hace muchísimo que no juego con el pak128. Creo que en todo el tiempo que llevo con Simutrans, habré jugado apenas media docena de veces con él. Simple cuestión de gustos pero aquí estamos dispuestos a probar casi todo.

Por lo que he leído en el foro y por las conversaciones con Zeno, cuando estaba con el tema del equilibrado de costes de los vehículos del pak128, la economía de dicho pakset es más dura, pensada sobre todo para obtener beneficios a largo plazo en la mayoría de los casos. Por tanto, como inexperto jugador, voy a optar por una estrategia conservadora.

Las claves serán no gastar mucho, rentabilizar al máximo cada vehículo y conectar elementos cercanos. Después poco a poco iré invirtiendo en trayectos largos y formando acuerdos con otros países.

Pero desde el primer momento, me he dado de bruces con la cruda realidad. Los trenes son muy caros, carísimos pero los costes operativos son muy bajos, justo al contrario que en el pak64, al igual que la cadena industrial del petróleo no es tan rentable como en el pak64. En resumen, que para emprender cualquier aventura debes contar con un buen colchón de dinero, al menos el doble de lo que tengas previsto gastarte, por si las cosas se tuercen y tienes que volver a empezar.

Intenté conectar unas plataformas petrolíferas con dos refinerías de la costa, pero acabé en números rojos a la primera de cambio. Los barcos también son muy caros y lentos, pero en el foro me ha sugerido que opte por las barcazas que también son rentables.

En la parte derecha he conectado todos los elementos de la cadena del etanol (campos de maíz, refinería y gasolinera en Rio de Janerio) pero las paradas se saturan y el tren no da abasto.

En Sao Paulo se concentra toda la industria pesada del acero y el carbón, que va a parar directamente al mayorista de la construcción, pero en un futuro espero poder exportar la madera y tablones sobrantes a las ciudades del sur como Buenos Aires y Montevideo, transportando el excente por la costa hasta el delta del río.

Esto ha sido una primera toma de contacto, pero estos son los planes que tengo programados para el futuro:

Estrategia a corto plazo(-2 años):

• Dividir la ruta del oeste de maiz en dos, para intentar terminar con la saturación de las paradas. Ahora es muy ineficiente.


• Construir centrales eléctricas para aumentar el consumo de bienes por parte de los consumidores finales. Se produce muchísimo más rápido de lo que se consume.

Estrategia a medio plazo(2-5 años):

• Conectar las explotaciones con los aserraderos, para obtener más tablones.


• Conectar plataformas petrolíferas con refinerías para empezar a producir plásticos.

Estrategia a largo plazo(+5 años):

• Instalar lineas de transporte en Rio de Janeiro y entre ciudad e industrias cercanas.


• Pedir más maíz a Argentina y crear otra gasolinera en Sao Paulo.


• Construir el Amazonas, para poder sacar el maíz por rio.


• Tener en cuenta diseño de red ferroviaría para expansión de ciudades. Ambas son ciudades grandes, y espero que crezcan mucho así que probablemente tendré que diseñar una red subterránea de metro y mercancías, para no entorpecer su crecimiento.

¡Nos vemos en el próximo turno!...

Con estas herramientas conquistamos lo imposible.

Es increíble la de cosas que aún se pueden encontrar en las páginas relacionadas con Simutrans. Últimamente he estado curioseando por las páginas japonesas y el foro checo, para ver que se traen entre manos y he descubierto estas dos herramientas que pueden ser muy útiles para aquellos que se dedican a la creación de gráficos.

Leer más...

La primera de ellas es resizeobj, una herramienta que básicamente sirve para trasladar objetos de escala pak128 a pak64. Antes de nada, más vale que useís un traductor online, porque el programa y la página del autor están en japonés. Dicho esto, tengo que destacar que la herramienta es muy interesante.

Si quieres jugar con algún objeto del pak128, solo tienes que obtener el archivo pak y convertirlo a escala pak64 mediante esta sencilla herramienta. La pega es que funciona por línea de comandos MSDOS y sólo está disponible para windows pero en la mísma página el autor pone a disposición el código fuente para compilarlo en otras plataformas.

La herramienta da la opción de controlar la cantidad de antialiasing (suavizado) que queremos usar, la cantidad de colores especiales (nocturnos), puede eliminar las animaciones durante el proceso de conversión así como algunos otros atributos dependiendo del tipo de objeto que queramos convertir.

Tras hacer unas pruebas con edificios, he de decir que el resultado no es malo pero no siempre funciona bien. Resizeobj suele tener problemas cuando el objeto, sobre todo si es un edificio, tiene más de una vista. Podeís ver los resultados en esta imagen (usé un estadio realizado por Diegote)



La verdad es que no está nada mal la conversión. No se ve borroso y tampoco hay problemas de transparencia. Una herramienta muy recomendable para aquellos que quieran disfrutar de parte del mundo pak128.

Desde el foro checo, donde hay tanto movimiento pero nadie sabe qué ocurre exactamente, nos llega una herramienta llamada Protomissume Software Box Shot Maker que casualmente es de código abierto y sirve básicamente para crear objetos 3D a partir de cajas ¿y por qué lo menciono si es para crear cajas? por una sencilla razón, hay un buen montón de plantillas de objetos que están desarrolladas como cajas. Por tanto, si tenemos el desarrollo de las distintas caras del objeto, a partir de una simple caja podemos recrear dicho objeto. No he podido probar con objetos complejos pero el resultado puede ser algo parecido a esto.



En principio, parece una interesante herramienta fácil de usar para aquellos que quieran crear gráficos para Simutrans pero no he podido probarla en profundidad.

Cual Indiana Jones, seguiremos en la búsqueda de nuevas herramientas... :)

Problemas en la torre de babel

Como habreís notado, desde hace un par de horas el foro internacional de Simutrans no responde. Los gente de la web está trabajando en ello, intentando averiguar donde está el problema. Podeís seguir en contacto a través de Escala Real, el foro de emergencia o el canal IRC de Simutrans.



Esperemos que se solucione lo antes posible.

Si deseas crear un pakset, ¡hazlo!

En alguna ocasión hemos dado claves acerca de cuales son los elementos necesarios para crear un pakset. Pues bien, ahora os traigo una pequeña entrevista con James "The Hood", uno de los artistas gráficos y gestor del pak.Britain. Veamos que nos cuenta de su experiencia creando los gráficos para este pujante pakset.

Leer más...

Adelante con la entrevista..

Escala Real: ¿Prefieres Pixel-art o 3D?
The Hood: Sin duda 3D. Lo creas o no, en realidad soy bastante malo dibujando, pero aún así puedo modelar en 3D y dejar que el ordenador haga el resto del trabajo.

ER: ¿Cuáles son tus fuentes de inspiración para el pakset?
TH: Cualquier cosa británica de hecho. Hay cosas que ya conozco (trabajo en la industria del transporte), pero para otros, especialmente el material antiguo, uso google o wikipedia para averiguar la historia y obtener material gráfico.

ER: ¿Podrías describir brevemente el proceso creativo? ¿usas plantillas para los diferentes objetos? ¿crear las texturas por ti mismo? ¿y que me puedes contar acerca de la iluminación?
TH: Empecé usando plantillas, pero ahora que he pillado el tranquillo a Blender y sé como van a quedar los objetos, generalmente hago las cosas a ojo. Las texturas son una combinación de imágenes reales (como texturas de paredes de ladrillo) y otras de producción propia usando Blender, por ejemplo la suciedad o el humo.

ER: Ya sabemos que usas Blender para crear los gráficos ¿qué es lo que aporta al proceso de creación de gráficos? ¿hace que sea más fácil o rápido?
TH: ¡ya lo creo! como dije anteriormente, yo no sé dibujar bien pero puedo crear modelos 3D aceptables. Así que realmente es Blender quien hace posible el proceso, al mismo tiempo que le da consistencia. Si no usara Blender, no dibujaría nada de nada ¡me llevaría años y aún parecería una porquería!

ER: ¿Usas algún tipo de técnica especial a fin de mejorar la calidad de los gráficos (UV Mapping, Ambient Occlusion, motores de render externos como Yafray)?
TH: Unicamente uso el motor de render de Blender. Para serte sincero, no soy un experto en estas cosas, me metí con Blender para ayudar a keirongreen en las etapas iniciales de desarrollo del pak128.Britain. Él ya había adoptado un estilo en Blender así que por mantener la consistencia, usé el mismo.

ER: ¿Utilizas algún programa como GIMP o Photoshop para dar los últimos retoques a las imágenes renderizadas?
TH: Todas las imágenes finales se limpian y alinean adecuadamente con GIMP. Esta es la parte más aburrida y costosa del proceso, pero es necesario.

ER: el pak.Britain ha apostado fuerte por la cronología en los gráficos ¿Como afecta esto al proceso de diseño de los gráficos?
TH: No estoy seguro de comprender bien la pregunta...¡una linea cronológica larga significa más necesitas pintar más vehículos! principalmente, intento contemplar una serie de vehículos para cada periodo de tiempo, pero depende de lo que haya podido averiguar acerca de la historia y de como lo pueda dibujar.

ER: ¿Qué crees que es más importante: un estilo gráfico coherente o que haya variedad dentro de cada tipo de objeto (vehículos, edificios, etc..)?
TH:Creo que tener un estilo coherente es muy importante. El pak128.Britain solo ha tenido dos artistas gráficos (kierongreen y yo), lo cual ayuda. Ambos nos hemos preocupado de asegurarnos que todo se ve bien dentro de un estilo consistente. He hablado con otros miembros de la comunidad y casi todos comparten esta misma idea.

ER: ¿Por qué elegiste un estilo tan oscuro para el pakset? parece tener una apariencia un poco industrial.
TH:Realmente fue decisión de kierongreen antes de que yo me involucrara en el proyecto. ¡Tal vez sea porque en Inglaterra llueve mucho y el sol nunca brilla! Puede que también sea porque hasta cerca de los años 50, gran parte de Inglaterra tuvo graves problemas con la contaminación industrial por humo y hollín. Personalmente, encuentro que el resto de paksets son demasiado luminosos (especialmente el pak128), pero es cuestión de gustos personales.

ER: En mi opinión, la guía de estilo del pak.BR es algo estricta ¿no crees que eso puede desanimar a la gente que quiera colaborar?
TH: Es estricta, y probablemente eso eche para atrás a algunas personas. Me gustaría que hubiese más gente que ayudara, pero preferiría tener una pakset que fuese consistente en cuanto a estilo y se viera bien, incluso si ello conlleva un largo proceso de desarrollo. ¡Después de todo, la gente siempre puede dibujar sus propios objetos extra con el estilo que quiera!

ER: Sabemos que a veces es dificil conseguir un estilo gráfico para un pakset. ¿Has recibido contribuciones de algún tipo?
TH: Algunos de los objetos del pak.Britain han sido tomados del pak128 con pequeñas alteraciones para que encajen con el estilo, por ejemplo, las señales son de Fabio, pero alteré un par de ellas para reflejar algunos aspectos específicos de las señales inglesas. Otras contribuciones las he tenido que dejar de lado, ya que era más rápido para mi dibujar el elemento que encajara con el estilo, pero la mayoría han sido dibujadas por Kieron y yo, así que los problemas de estilo han sido mínimos.

ER: Si no me equivoco, la parte gráfica del pakset está gestionada y desarrollada principalmente por ti ¿qué estilo de gestión crees que es mejor para desarrollar un pakset? ¿hombre orquesta o grupo de gente? por ejemplo, el pak96.comic tiene un artista principal y otro secundario, además de las contribuciones extra.
TH: Oficialmente, Kierongreen es aún el jefe, pero no ha tenido mucho tiempo en los últimos dos años como para dedicárselo a Simutrans, así que esencialmente todo recae sobre mi. Él es como el "Hajo" del pak.Britain..¡si tiene alguna sugerencia o comentario, yo le escucho! asi que generalmente, yo hago los gráficos con colaboraciones esporádicas de otros. Recientemente, ha habido algunas personas que me ha ayudado con el equilibrado pero en última instancia todo pasa por mi, ya que soy el encargado de liberar las nuevas versiones.

ER: ¿Como planificaste las diferentes etapas de desarrollo del pakset? ¿tenías alguna prioridad? los vehículos antes que los edificios, fábricas antes que cualquier otro tipo de edificios, etc...
TH: Todo empezó a raíz del conjunto de objetos ferroviarios de Kierongreen para el pak128, al cual estaba jugando en ese momento pero quería trenes más antiguos, así que me puse a ello y los dibujé. Al mismo tiemo, Kieron comenzó a trabajar en el pakset y dibujó algunos edificios junto con carreteras y vías. Así que todo comenzó a partir de ahí. El plan era usar el pak128 como base y después poco a poco ir reemplazando todos los objetos originales por los nuevos con estilo, pero para inicialmente lo hicimos de forma algo aleatoria.

Hace cosa de un año, me puse en serio con ello y encaminé mis esfuerzos a crear todos los objetos que necesitaríamos para tener un pakset que se pudiera cargar sin necesidad de usar objetos del pak128, lo que me llevó a publicar la versión 1.0 a principios del verano de 2009. Eso significó tener listas todas las vías, cocheras, árboles y algunos otros objetos aleatorios, pero no todos los vehículos ni las industrias, los edificios urbanos o atracciones turísticas eran limitados. Ahora el objetivo es conseguir más vehículos. Ya completé los vehículos de carretera y ahora estoy trabajando en los barcos, después será el turno de los aviones, etc... En último lugar, nuevamente volveré a crear más edificios y puentes.

ER: En tu opinión ¿es mejor desarrollar un pakset concentrándose en cada una de las partes o mezclando todo al mismo tiempo? Por ejemplo, en lo relativo a vehículos ¿primero los camiones, después los autobuses y por último las barcazas o todo al mismo tiempo?
TH: Desarrollar un pakset conlleva mucho esfuerzo, así que lo mejor es hacer aquello que contribuya a aumentar tu interés. Si necesitas variedad, yo diría que hicieses muchas cosas diferentes, pero en mi caso prefiero tener una lista e ir tachando cosas, así me concentro en una sola cosa al mismo tiempo. Primero autobuses (hecho), después camiones (hecho), ahora barcos(en desarrollo), después aviones(por hacer), etc, etc...

ER: Acerca del estilo del pakset, prefieres un cambio de tamaño (pak128, pak192), estilo (pak32, pak96.comic or pakHD) o tema (pak.german, pakJapan y obviamente pakBritain)
TH: No estoy muy seguro de a que te refieres, pero pienso que una de las mejores cosas de Simutrans es la variedad de tamaños y estilos que te permite elegir. No he tenido tiempo para jugar, he echado un vistazo a algunos de los diferentes paksets para ver como hacen las cosas. Me gusta el pak96.comic porque es tan diferente al pak.Britain que el cambio me resulta agradable, pero también me gustan el tipo de escenarios realistas del pak.German. Espero que el pak.Britain termine teniendo su propio estilo, una opción más entre las que poder elegir y con las que poder disfrutar jugando, ¡especialmente para aquellos que estén interesados en los transportes ingleses!

Por otro lado, como bien has dicho el pak.Britain es temático. Ahora que he empleado mucho más tiempo en proyecto, cualquier cosa más pequeña de 128x128 me parece enana, pero creo que el pak96 tiene el justo equilibrio entre detalle y tamaño. Tal vez, si hubiese empezado todo de nuevo, optaría por una escala estilo pak96, pero creo que la escala pak128 permite algo más de detalle así que en este aspecto estoy contento.

Pues esto es todo por hoy. Espero que os haya resultado interesante esta pequeña entrevista, y sobre todo que os haya dado una idea de por donde van los tiros en el desarrollo gráfico de nuevos paksets. No quiero terminar sin antes agradecer a James "The Hood" su tiempo y ganas de compartir su experiencia con Escala Real y el resto de la comunidad de Simutrans.

Manifiesto en defensa de los derechos fundamentales en Internet

Este no es un artículo estrictamente relacionado con Simutrans, pero me pareció importante apoyar esta causa, porque hay mucho en juego para el futuro de España y quién sabe si no se extenderá a otros países...

Leer más...

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de Internet manifestamos nuestra firme oposición al proyecto, y declaramos que:

1.Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.Los autores, como todos los trabajadores,tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Más información en la Asociación de Internautas

Acciones, no palabras

Desde el inicio de los tiempos en Simutrans, una de las características más demandadas por los jugadores, más los nuevos que los viejos, ha sido el modo multijugador. En las últimas versiones Prissi ha ido filtrando información a cuenta gotas acerca este tema, pero realmente todos nos preguntamos ¿como va el desarrollo del modo multijugador? pues vemos que se puede averiguar...

Leer más...

Antes de nada vamos a repasar un poco los antecendentes. Hasta hace unos cuatro años, hayá por la versión 0.88.xx, el modo multijugador estaba en tercer lugar en la lista de prioridades del equipo de desarrollo (fuente) por debajo debajo de temas como la correción de errores y los gráficos. En su momento la gente propuso intentar hacer cosas estilo Ogame para el modo multijugador, pero había otras prioridades.

Los usuarios seguían demandando dicha funcionalidad, y durante bastante tiempo, el meme de Is it multiplayer yet?, algo así ¡¡pero como!!¿aún no tiene multijugador? fué lo más repetido en el foro de Simutrans.

La idea inicial era, y supongo que sigue siendo, una arquitectura cliente ligero y servidor, donde todos se conectan al servidor y este actúa como sincronizador de eventos. Si algo ocurre en alguna parte de la partida, se manda al servidor y este lo propaga al resto, para que todos los clientes obtengan la misma imagen de la partida.

Si tuviéramos que usar un símil, diríamos que el servidor sería el motor del juego y los clientes tendrían unicamente el interfaz. El servidor no haría más que enviar datos al interfaz del cliente, para que refleje los cambios y reciba cualquier dato de entrada del cliente que se deba propagar al resto. Esto supone que el tráfico entre todos los elementos puede ser bastante frecuente, pero no con tanta carga como puede parecer a primera vista. La ventaja de esto que los clientes pueden tener unos requisitos modestos mientras que las características de la partida, por ejemplo tamaño del mapa o número de ciudades, dependen exclusivamente del servidor. Podrían jugar clientes con PC viejos apoyándose en otros jugadores con mejores ordenadores. Teneís más información acerca de algunos de los detalles técnicos aquí.

Pero entonces, ¿en qué estado se encuentra la cuestión? Pues bien, repasando los últimos comentarios de Prisi, podemos sacar en claro varias cosas:

• Parte del código existe y está operativo, pero solo se puede probar descargando, modificando y compilando el código del repositorio. Mas detalles aquí


• Bastantes de los comandos y eventos se transmiten entre los jugadores y el servidor, pero aún hay que pulir detalles en el inicio y cierre de conexión.


• Falta la parte más crítica, la sincronización de todos los eventos que tienen lugar en una partida de Simutrans: vehículos, edificios, terrenos, etc..


• El cambio de jugador será mediante contraseña, y el servicio público no estará disponible de forma libre, como ocurre en la actualidad.


• Habrá un jugador servidor, y el resto serán clientes que recibirán el fichero de la partida y se conectarán a ella, verificando que todos tienen los mismo objetos y en caso contrario, intercambiándolos.


• En todo momento, los jugadores de la partida estarán sincronizados. Lo que ocurra en cualquier cliente, se propagará al resto a través del servidor.

Si tuviera que mojarme con una cifra, un porcentaje, diría que está como al 10-15%. Sé que no es mucho, pero Prissi no suelta prenda y en los comitts del repositorio de código no aparece nada relevante últimamente en relación a este aspecto. Supongo pues que de momento todo está en fase experimental, y que se va trabajando poco a poco. Hay que tener en cuenta que hay otras muchas cosas que atender como corregir los errores que surgen o revisar nuevos parches.

Por otro lado, en algún momento pasado se sugirió hacer algo parecido al famoso Ogame, con una arquitectura de cliente ligero, donde Simutrans estaría corriendo en un servidor de forma contínua y persistente mientras los usuarios se conectaban a dicha partida infinita e interactuaban. Evidentemente esta es una solución cara, por el coste del servidor y en cierto modo más orientada a los MMORPG que a los juegos de simulación. Sin embargo, existe una forma de juego que más o menos se aproxima a ello, llamada juego colaborativo, del cual ya hablamos largo y tendido hace tiempo.

El caso es que hace unos días, un nuevo miembro de la comunidad llamado Rodrigo Soracco, se interesó por el estado de desarrollo del modo multijugador y comentó que estaba desarrollando una especie de programa para automatizar las partidas colaborativas, a medio camino entre el estilo Ogame y el mundo persistente. Funciona usando un repositorio, donde los jugadores se conectan, descargan el juego, juegan y después se guarda cada nueva partida jugada. De esta manera tienes distintas versiones de la misma partida, y puedes engancharte en cualquier momento. Teneís todos los detalles aquí

Bueno, esperemos que poco a poco la cosa vaya tomando forma y en un futuro no muy lejano, digamos un año o dos, estemos todos conectados jugando de sol a sol... :D

Imágenes:
- network cortesía de Binkiexxx en Flickr
- Disconnected !!! cortesía de agelakis en Flickr

Hasta el infinito y más alla...

Si no recuerdo mal, en más de una artículo os he hablado aquí de uno de mis proyectos pendientes para Simutrans: crear mi propio pakset con temática espacial. Es algo a lo que llevo dándole vueltas hace tiempo, pero no acabo de decidirme por falta de seguridad acerca de a viabilidad del proyecto, pero viendo el pak.Excentrique que Hajo está desarrollando, me ha vuelto a picar el gusanillo y la idea del RetroSpacePak ha empezado a tomar forma en mi mente. Hagamos pues un ejercicio de imaginación.

Leer más...

Mi obsesión con crear un pakset de temática espacial viene fundamentalmente de mi afición a la ciencia ficción, tanto literaria como cinematográfica. Devoro cualquier cosa que huela a tecnología y ciencia.

Tengo que destacar que ya había antecedentes de paksets con esta temática, al menos uno. El olvidado pak.Mars, obra de Robofish, fue el pionero al llevar Simutrans más allá de la Tierra. Fueron muchas las discusiones en las que tomé parte acerca de todas las posibles particularidades y aspectos de Marte que podrían influir en los diseños de vehículos, edificios y demás objetos presentes en Simutrans. Si quiereís más información, podeís echar un vistazo en el archivo del antiguo foro

La idea del SpacePak siempre habia sido el espacio, inspirado un poco en películas como 2001, Star Wars, Star Trek o similar, pero hace poco descubrí unos enlaces con ilustraciones retro futuristas de los años 60-70. Me quedé maravillado por todas las escenas que se representaban, y en ese momento decidí un cambio de rumbo en la temática del pakset. Ya no sería sobre el espacio profundo, sino que incluiría planetas con civilizaciones y colonias.

El punto de partida es simplemente cambiar las texturas del terreno, reemplazando el agua por vacío estelar con estrellas y la parte terrestre por gráficos similares a asteriodes o planetas. Esto elimina el agua de la parte gráfica y cambia totalmente la sensación visual, ya que en teoría parecería que las partes terrestes estarían flotando en el espacio.

Una de las parte más interesantes serían los vehículos, y aquí se abre un amplio abanico de posibilidades. Desde coches voladores, mini platillos volantes hasta autobuses helicóptero, pasando por camiones con motores de cohete. Digamos que la franja de vehículos de carretera serían objetos que se mantendrían en tierra y para cortas distancias. Para tramos de longitud media, entre colonias cercanas pasaríamos a los trenes con propulsión a chorro, los monorrailes colgantes, trenes levitantes por tubos, teleféricos o funiculares en las ciudades para ir de una punta a otra.

Por último tendríamos los barcos y los aviones, ambos adaptados para trayectos de larga distancia. Los barcos serían de formas redondeadas para el espacio o muy afiladas para la parte de los ríos, que actuarían como grietas del terreno, a través de las cuales se vería el núcleo del planeta o directamente el espacio. En cuanto a los aviones, obviamente serian todos o casi todos naves espaciales, sondas, aviones supersónicos a reacción o con hélices para trayectos terrestres. En realidad, el resto de vehículos incluirían siempre detalles de los aviones como hélices, alas, motores a reacción y posibilidad de volar.

En el caso de los edificios la cosa se complicaría un poco, no por falta de ideas sino todo lo contrario, por la cantidad de diseños y formas distintas que puede llegar a haber. Tendríamos colonias mineras, campamentos base, espacio puertos, plataformas de despegue, ciudades espaciales dentro de anillos, esferas de Dyson, estaciones espaciales, enormes edificios isla interconectados, inmensas ciudades con enormes edificios hiperpoblados 5 o 6 pisos mínimo, rascacielos comunicados mediante pasarelas, arcologías, edificios colmena, ciudades con vida subterránea y cimientos a gran profundidad, colonias aéreas que flotan entre las nubes de gas, apartamentos individuales a las afueras donde dejar tu nave y disfrutar de la calma y tranquilidad. En general, grandes estructuras interconectadas para concentrar a los habitantes en inmensos núcleos de población.

Las atracciones turísticas se concentrarían básicamente en fenómenos naturales de espacio como púlsares, supernovas, estrellas gigantes, nubes de gas, galaxias, agujeros negros,etc.. pero también se podrían incluir edificios peculiares como museos, jardines, estaciones espaciales, ruinas de antiguas colonias, vestigios de otras civilizaciones, arcologías y casi cualquier cosa que tenga cierta rareza.

Por último, en lo referente a materias primas, lo habitual serían minerales de metal sacados de asteroides o colonias mineras, gases como oxígeno, hidrógeno o gas tibanna que serían recolectados en campos mediante cosechadoras o plantas extractoras, agua, plantas y semillas para producir CO2 y terraformar las distintas zonas.

En fin, en mi cabeza todo tiene un pinta estupenda. Tal vez algo falto de coherencia por la enorme variedad de estilos y elementos, pero sin duda será un pakset muy atractivo, si es que algún dia se llega a hacer...¡alguien se anima!

Referencias:

• Viajar a mundos lejanos


• Alucinantes medios de transporte retro futuristas


• Glorioso urbanismo retrofuturista


• Retro futurismus

P.D: Por cierto, en relación con este tema, pronto publicaremos un entrevista con The Hood, el co-creador del pak.Brittain, para que nos dé su punto de vista acerca de como desarrollar la parte gráfica un pakset.

Quien tiene la información tiene el poder.

A veces tengo la sensación de que la comunidad de Simutrans se mueve menos de lo que debería, es poco activa. Si embargo te pones a escarbar entre los mensajes de los foros locales, y realmente te das cuenta de que hay algo que se mueve bajo la alfombra pero ¿como estar al tanto de las últimas novedades?

Leer más...


Ciertamente no existen tantas fuentes de información en la comunidad de Simutrans, pero posiblemente estén algo ocultas o adolezcan de la barrera del idioma. El que muchos de los intercambios de información se hagan en inglés puede desanimar a los nuevos usuarios, especialmente a los de las comunidades locales (PT, ES, CZ)

La primera fuente de noticias es el foro, tanto el actual como el archivo. Este inmenso monstruo genera toneladas de información, pero hay que prestar especial atención a las secciones de Information and announcements donde se publican los anuncios importantes y en Download Simutrans donde se anuncian las nuevas versiones. En la parte de desarrollo y parches (Development and Bug Reports) hay una sección llamada parches incorporados y errores corregidos (Incorporated Patches and Solved Bug Reports) donde podeís estar al día de las nuevas características y los errores corregidos en futuras versiones.

Esto no lleva a la siguiente fuente de información, en mi opinión una de las más importantes actualmente, que es la página de Simutrans en Sourceforge. Allí encontrarás un canal de noticias con los últimos movimientos(noticias, nuevos ficheros y versiones, etc..)

Algunas de las comunidades locales de Simutrans tienen un hilo o un subforo de Avisos y Últimas noticias donde se publican anuncios de cosas interesantes como nuevos objetos disponibles, rumores, enlaces a retos, nuevos servicios de la comunidad, etc... En un futuro se espera hacer lo mismo a nivel general, para toda la comunidad. Es más, ahora mismo se está discutiendo la posibilidad de crear una especie de blog de desarrollo de Simutrans, donde la gente pueda tener su espacio para publicar anuncios y cosas interesantes. En definitiva, otro espacio público más visible que el foro donde exponer ideas.

Desde hace poco tiempo, también están disponibles dos nuevos canales de noticias RSS, relacionados con el repositorio de código y gráficos, para estar informado sobre las últimas novedades en cuanto a código y paksets oficiales (suscríbete) y otro canal relacionado con Simutranslator, para no perder detalle acerca de las novedades relativas a las traducciones (suscríbete)

No es mala idea pasarse de vez en cuando por el canal IRC, sobre todo los lunes a partir de la 19:30 que es cuando se habla español, para cotillear un poco y compartir ideas.

En última instancia, siempre podeís daros un paseo por Escala Real, o cualquiera de los blogs satélite de Simutrans...

Imagen: Information cortesía de racho holmes

La única verdad es la realidad.

Ya hemos hablado en otras ocasiones acerca de los usos alternativos que se le pueden dar a Simutrans, especialmente en el campo de la enseñanza. Las anteriores propuestas se han basado en la idea de usar Simutrans como entorno simplificado de la realidad, donde podemos reducir y muchos aspectos del mundo real para obtener un modelo simple. En este caso, la propuesta es justo al contrario; queremos igualar realidad y ficción ¿es posible?

Leer más...

Hace unos días, en el foro apareció un mensaje de un ingeniero de Delhi (India) que quería saber hasta que punto era posible simular el comportamiento de una ciudad como la propia Delhi en Simutrans. Ante todo, creo que todo el mundo tiene claro que Simutrans es un juego, un medio de entretenimiento y no pretende ser un simulador realista del mundo real. El modelo de simutrans es una versión simplificada, donde muchas de los aspectos y acciones se han descartado, dejando únicamente lo más básico y primitivo.

En concreto, la parte que afecta al desarrollo y crecimiento de las ciudades es totalmente ajena al jugador. Cierto, se puede influir en el ritmo de crecimiento, pero no se puede dirigir. De hecho, la simulación está más centrada en regiones y países, que en ciudades o áreas urbanas. Las industrias influyen en su entorno, no en las ciudades.

Por otro lado, hay detalles de la planificación urbana que el juego no llega a reflejar, como las canalizaciones, tuberías y cableado. En el foro resumieron, a groso modo, el algoritmo de crecimiento de las ciudades con la siguiente frase:

"Donde existan carreteras, casas y espacio libre, habrá nuevas carreteras y casas"

Vladimír Slávik

Como podeís comprobar, la cosa no es muy realista, sin embargo, en mi opinión creo que si es posible usar Simutrans para realizar una simulación del tráfico de una ciudad. Puedes controlar los parámetros del tráfico en la ciudad, el algoritmo de encaminamiento de los pasajeros establece destinos y orígenes previamente por tanto existe un flujo de gente a determinados lugares establecidos, tienes señales para controlar y dirigir el flujo de trafico, y herramientas para modificar el terreno y hasta cierto punto reproducir muchas de las estructuras existentes en el mundo real.

Estos son algunos de los modelos de ciudades o zonas reproducidos en Simutrans:

• Praga es un mapa algo antíguo (para v99.17 - pak128) pero impresionante. La ciudad está completamente recreada con suburbios, farolas, industrias, calles, conexiones, metro, etc..


• Londres simula toda la red de transportes publicos de la ciudad inglesa. Trenes, metros, tranvías e incluso el servicio de barcos del Támesis.


• Europa es una simulación de todas las ciudades importantes del viejo continente. Es para Pak 128. La cantidad de vías y conexiones ferroviarias os puede servir para haceros una idea de lo que se puede llegar a simular en cuanto a trenes.


• Superbus es un pequeño mapa para pak64 que recrea un red de transporte de buses con un 100% de eficiencia. Todas las paradas están cubiertas.

Un detalle, algunos de los mapas pueden no funcionar correctamente. Había también una simulación del metro de Londres, con todas las paradas pero se ha perdido..

Como podeís observar, las posibilidades son enormes. Espero que con esto alguien se anime e intente recrear su ciudad o zona con Simutrans, al máximo nivel de detalle posible, tanto que hasta uno mismo aparezca en alguna de las paradas.

Imagen the border between fiction and reality de 3views

Sé agua, amigo.

Una de las fórmulas básicas de tener y conservar el éxito de un proyecto es crear una mecánica de uso sencilla, directa y propia. No se trata de inventar la rueda, pero si ofreces cosas nuevas, es razonable que las uses de otro modo. Pero esto no es siempre es beneficioso, ya que a veces aparecen reticencias por parte de potenciales usuarios.

Leer más...

"No te establezcas en una forma, adáptala y construye la tuya propia, y déjala crecer, sé como el agua. Vacía tu mente, se amorfo, moldeable, como el agua. Si pones agua en una taza se convierte en la taza. Si pones agua en una botella se convierte en la botella. Si la pones en una tetera se convierte en la tetera. El agua puede fluir o puede chocar. Sé agua amigo mío"

Bruce Lee

Hace unos días estaba curioseando por la página de Simutrans en SourceForge cuando centré mi atención en las breves reseñas sobre Simutrans que hacen algunos usuarios, la gran mayoría anónimos. Algunas eran negativas pero tampoco es para obsesionarse. Sin embargo hubo una que me llamó la atención.

Traduciendo, más o menos venía a decir que el juego no desplazaba el mapa cuando acercabas el ratón al borde de la misma, sino que debías usar el teclado lo cual es raro en Windows (¿?) Por otro lado, el anónimo destacaba el hecho de que no fue capaz de construir una vía ferroviaria con puente. Decía que aparecía un mensaje diciendo que debía conectar la vía, pero no funcionó. Y se preguntaba por qué no podía simplemente construir el puente y más tarde conectarlo. La conclusión final es que es un buen juego si sabes como jugar, pero él o ella no tenía la suficiente paciencia para aprender a jugar, así que le resultaba muy complicado empezar a jugar desde cero.

Analicemos pues, esta interesante a la par que peculiar crítica. Por un lado, hay que reconocer que Simutrans, como casi cualquier juego de estrategia, tiene una mecánica profunda la cual hay que aprender dedicando tiempo y algo de esfuerzo. No es el típico juego de tiros o coches, donde tienes 10 teclas y 5 acciones básicas que sirven para seguir la mecánica del juego. Con esto simplemente quiero destacar que cada género tiene sus métodos, mecánicas e interfaces dependiendo del rango y complejidad de las acciones a realizar. No puedes pretender, al menos así lo entiendo, empezar a jugar a Simutrans tan rápido como lo harías con Quake, por ejemplo.

Entiendo que si vienes de otro juego similar como Transport Tycoon, tengas ciertos vicios y a primera vista haya cosas que te parezcan poco lógicas, pero si eres nuevo en esto, al menos tendrías que aceptar las cosas como son inicialmente. Si el juego te dice que hagas la carretera, y conectes ambos extremos mediante un puente, no seas cabezón e inténtalo de esa manera. Si tienes problemas, acude a la ayuda, las guías o el foro, pero no te ofusques porque la manera que tu crees más lógica no es la que usa el juego. Supongo que en este caso concreto, los puentes solo tienen sentido si hay carreteras y no al revés, por tanto no tiene sentido que te deje construir el puente antes de tener la vía.

La pregunta de millón es ¿debe adaptarse el juego al usuario o el usuario al juego? ¿la mecánica debe ser intuitiva y lógica o se deben forzar una serie de acciones? ¿por qué hacer las cosas de una forma y no de otra? ¿existen alternativas?

Mi opinión personal, y esto es algo que gente ligada a la coordinación del proyecto como Hajo han mencionado en más de una ocasión, es que no hay que guiarse completamente por las preferencias de los usuarios. En algún momento hay que establecer la línea entre la lógica y los gustos, porque sino se puede perder el rumbo y se termina actuando como una veleta, que cambia de dirección según sople el viento. Lo que parece lógico hoy, mañana puede parecer completamente irracional. Lo que está de moda hoy, mañana puede ser defenestrado. Personalmente, no creo que esa sea la forma de llevar a cabo ninguna tarea. Uno debe encontrar un estilo sencillo, directo, lógico y propio cuando sea posible, intentando que el usuario ponga también algo de esfuerzo por su parte. Hay que adaptarse y poner los medios para que se adapten a tí.

Tenemos nuevo chico en la ciudad

No quiero convertir esto en un blog rosa, pero de vez en cuando no viene mal hacerse eco de algún que otro cotilleo. El rumor es un secreto a voces, y es que parece que muy pronto tendremos una nueva versión de nuestro juego favorito.

Leer más...

Según parece la fecha elegida será el 18 de Octubre, osea que a lo largo de este fin de semana estára disponible la nueva versión. Prissi ha cerrado ya todos los cambios en el repositorio de código y todo está listo y dispuesto. Antes del verano ya se confirmó que no habría nueva versión hasta finales de Septiembre o principios de Octubre y desde entonces se han producido muchos nuevos parches y se han corregido bastantes errores. Parece que finalmente tendremos plenamente operativo el modo subterráneo, con puentes y pendientes a todos los niveles. Además se ha incorporado una nueva herramienta para el control de tráfico ferroviario, conocida como agujas o rail switch, pero falta pulir los gráficos de este objeto. Cuando saquen la nueva versión os podré dar más detalles de todas las novedades.

Otra de las razones para sacar esta nueva versión es que posiblemente Simutrans será incluido en el CD de la revista Computertechnik, más conocida como C't. Personalmente he de confesar que hace mucho que no leo una revista de informática. La red es casi exclusivamente mi fuente de información sobre casi todos los temas que me interesan pero entiendo que hay gente con menos experiencia que de alguna forma aún está atada a la prensa tradicional. C't es la cuarta revista alemana más popular y la revista europea sobre informática con más subscriptores, llegando a los 239.000.

Objetivamente es una gran oportunidad para captar nuevos jugadores y colaboradores, y de hecho Simutrans ya fue incluido en otro CD que ofreció dicha revista en el 2000, así que parece que han vuelto a confiar en Simutrans, y me temo que más de uno se llevará una sorpresa porque las cosas han cambiado mucho en 9 años... :)

Solo decir que aguanteís un poco, porque la espera merece la pena.

Ya encontraron la ruta

Parece que finalmente el problema con el foro se ha arreglado y casi todo vuelve a la normalidad. Según parece es posible que algunas cuentas de usuario se hayan borrado, pero no se podrá saber nada definitivo hasta que se haga un chequeo completo. Si alguno tiene problemas para acceder con su usuario y contraseña, que lo comunique en el foro. En breve os daré más detalles acerca de lo ocurrido.

Simutrans, tenemos un problema

Parece que desde hace unas tres horas el foro está fuera de servicio. El servidor esta activo porque responde al ping pero la página no carga. El resto de dominios también estan caídos, asi que habrá que esperar hasta que los chicos del foro lo arreglen. Para aquellos que quieran seguir informados, puede acceder al foro de emergencia en forum.simutrans.us. Un poco de paciencia, que se arreglará lo más pronto posible..

Actualización: Parece ser un problema de la base de datos, según comentan en este hilo del foro alemán de Simutrans. Actualmente aparece este mensaje de error al entrar en la página del foro..

Table './simutrans/sforum_smf_sessions' is marked as crashed and should be repaired

...así que parece que la cosa va para rato, pero quien sabe.

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.

El hombre, D-man

Definitivamente ha vuelto...

Leer más...


Tal vez a algunos os suene el nombre de Raven, y otros no sepaís de quíen estoy hablando, pero es seguro que a partir de ahora oireís hablar de él.

"Esta bien tío, me apunto. Porque sabes, aquí se está cociendo algo del futuro y eso a mí me mola.." Will Smith - Men in Black I

Antaño fue una figura importante en la comunidad de Simutrans, sobre todo en el apartado gráfico. Muchos de los edificios y vehículos de los pak64 y pak128 son suyos, especialmente los trenes (es un loco de los raíles.. ;)) Autor entre otras cosas, del pakHD que parecía dibujado a mano. El caso es que por unos motivos u otros se distanció del proyecto, pero ahora está de vuelta y poco a poco va calentando motores...señores, ¡D-Man esta de vuelta!

Una muestra de su trabajo reciente..

Yo no digo todo, mas pinto todo

En más de una ocasión hemos hablado acerca de la técnica de UV Mapping en Blender, y hemos valorado sus ventajas e inconvenientes. Entre estos últimos, destacamos el trabajo que supone crear una textura cuando tienes que desplegar la malla de objetos complejos, con superficies intrincadas. Te lleva mucho tiempo y esfuerzo, pero esto va a cambiar gracias al descubrimiento de una técnica llamada Project painting.

Leer más...

Esta técnica permite literalmente pintar la malla del objeto, a partir de las proyecciones de texturas en las distintas capas UV. Aunque en el vídeo al final del artículo está todo explicado, en inglés pero al fin y al cabo es un vídeo, voy a hacer un pequeño resumen del método. Es más sencillo de lo que pueda parecer a primera vista.

En primer lugar necesitamos hacer algún objeto, pero para el ejemplo usaremos el habitual cubo y esta imagen como textura.

A continuación, pulsamos en el botón del cuadrado con puntos. Seguidamente vamos a la pestaña Mesh y creamos varias UV Textures pulsando en x, que se corresponderán con las vistas frontal, lateral y alzado, así como una más que albergará la textura que queremos aplicar. Seleccionamos el cubo y pasamos a modo Edición, seleccionando todas las caras (Pulsa A).



Pasamos a modo UV, marcamos las costuras y lo desplegamos usando Unwrap (si no sabes como, echa un vistazo aquí) sobre la capa base. A continuación, seleccionamos cada una de las restantes capas (lat, top y front) y proyectamos el objeto según la vista actual (tecla U >> Project from view) Hay que repetir esto con cada una, seleccionando la capa correspondiente en cada ocasión.



Ahora tenemos que cargar las imágenes de las texturas en todas las vistas UV (menu Image >> Open) menos en la primera, donde deberemos crear una imagen nueva en negro (menu Image >> New >> OK). Tened en cuenta que hay que ir seleccionándolas en la lista de capas, sino la imagen se cargará siempre en la misma capa. Después, cambiamos a modo Texture Painting y debemos poner todas las "capas" en modo clone excepto la primera (base), que debe estar en modo stencil.



Además, en el modo UV debemos ajustar los vértices del objeto a las distintas caras del cubo de la imagen, en las capas front, lat y top, para que la textura se ajuste al objeto



Llegamos a la parte más fácil. Es la hora de pintar. En la ventana 3D, cambiamos a modo Texture Painting y el Draw Type a Textured. Pulsamos V. Después, en la pestaña Paint, seleccionamos las opciones clone y Clone Layer. Subimos el valor de la opacidad (Opacity) a 1.0 y aumentamos el tamaño del pincel a 71 unidades. Finalmente seccionamos la capa base (la primera) y la que queramos aplicar (cualquiera de las otras tres, en este caso la capa lat) y pintamos en el objeto. Esto clonará la actual y las modificaciones aparecerán en la base. Recuerda que hay que pintar la cara anterior y posterior, en cada caso.



Podemos guardar el resultado seleccionando la capa base como activa, y en el modo UV pulsamos en el menu Image >> Save as. Para cargar imagen resultante con la textura desarrollada en función de la malla, debemos crear un nuevo material para el objeto (F6 >> Links and Pipeline >> Add new), activamos la opción TexFace en la pestaña Material y creamos modo UV, creamos una nueva textura en la pestaña Texture con Add new y en la pestaña Map Input marcamos UV.



Observaciones finales. Si quereís renderizar la escena, es conveniente que añadaís una fuente de luz (lámpara tipo sun o spot) Recordad que hay que establecer la textura UV base como Set rendering UV texture, para que tras cargar la imagen y renderizarla, esta aparezca proyectada correctamente en el cubo. El resultado debería ser parecido a esto..


Como veís, no es tan dificil aplicar buenas texturas a objetos complejos. Me atrevo a decir que más de uno se va a quedar sorprendido con el vídeo.

Referencias:

• Enlace al vídeo original. Lo interesante empieza hacia la mitad del vídeo.


• Notas de referencia oficiales sobre Projection Painting en Blender 3D

¿Árbol? No soy árbol, soy un Ent.

En anteriores artículos comentamos algunos plugins de Blender para la creación de arboles como Gen3. El problema es que no suelen ser muy intuitivos, y a veces los resultados no son lo suficientemente manejables. Es por esto que me puse a buscar nuevas formas de crear árboles sin necesidad de plugins, y encontré este interesante tutorial que muestra como hacer árboles de forma rápida y sencilla mediante curvas.

Leer más...

Esto es básicamente una traducción del enlace que aparece al final del artículo, con algunas imágenes extra de ejemplo, ya que se supone que esta técnica es parte de un script que está desarrollando el autor (Campbell Barton) para Blender.

En el modo 3D, añadimos una curva Bezier pulsando la tecla espacio, y seleccionamos Add >> Curve >> Bezier Curve. A continuación establecemos el parámetro bevel depth con valor 0.1 (botón Edición >> pestaña Curve and Surface) y BevResol con valor 6 o superior.

Tened en cuenta que la curva es ahora sólida, esto significa que tiene superficie. Activamos la opción del botón 3D (queremos un arbol en 3D) y desmarcamos los botones Front y Back. Después, pasamos al modo edición y pulsamos la tecla N. En el panel Transformation Properties, seleccionamos ambos puntos de la curva y pulsa el botón Auto, para que la curva se alinee automáticamente.

Lo que hay que hacer ahora es crear la forma básica del tronco extruyendo y copiando la curva. Selecciona y arrastra los distintos puntos de la curva en sentido vertical, para crear el tronco. A continuación, selecciona el punto inferior de la curva, y ajusta el radio, pulsando Alt+S. Después, extruye el punto superior y ajusta el radio, reduciéndolo para que parezca un árbol. Por último, deberemos escalar la curva para ajustar el tamaño al tipo de arbol que hayamos eleguido (10-20 unidades)



El siguiente elemento a modelar son las ramas. El método es bastante parecido al aplicado para la creación de las ramas, pero en este caso el tamaño de los objetos será menor. Duplica algunos de los puntos del tronco y extrúyelos para crear las ramas. Selecciona dichas ramas y reduce el radio pulsando Alt+S. Además, hay que reducir el radio de las puntas de las ramas, respecto de la parte que está junto al tronco. Basta con seleccionar la rama, pulsar W y seleccionar la opción Smooth Radius. Esto suavizará progresivamente el radio desde el inicio al final de la curva.

Tómate tu tiempo para situar correctamente las ramas, hasta que la cosa se parezca más o menos a un árbol.

Para las hojas basta con deformar una esfera, y aplicarle alguna textura de hojas. La cosa puede mejorar si usaís texturas con transparencia, ya que esto hará que la textura tenga huecos, como los que dejan las hojas entre sí.


Para aquellos que aún no lo tengan claro, el enlace del final contiene un vídeo tutorial. Como comprobareís, la técnica da algo más de trabajo pero el resultado es más manejable y accesible que cuando usamos plugins..



Referencias:

• Tutorial Tree from Curves.