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.. :)
Mostrando entradas con la etiqueta mejora. Mostrar todas las entradas
Mostrando entradas con la etiqueta mejora. Mostrar todas las entradas
17/5/09
Dime con quién juegas y te diré como eres
Una de los elementos clave del desarrollo de cualquier projecto son los comentarios de los usuarios, la retroalimentación (feedback) es fundamental en el proceso de mejora y pulido de los detalles, ya que los desarrolladores normalmente no tienen tiempo de probar de forma intensiva todos ellos. Y Simutrans no es una excepción, ya que en los últimos tiempos hay algunos jugadores, más o menos experimentados que se han animado a relatar sus experiencias de juego en forma de informes, arrojando conclusiones que ayudan a mejorar tanto el juego como los paksets.
Leer más...
Primero hay que decir que no es estrictamente necesario ser un jugón para hacer este tipo de cosas, pero si ayuda. En otra ocasión comentamos que hay gente que juega por placer y otra como reto personal, lo cual no es malo pero son dos formas totalmente distintas de afrontar una partida de Simutrans, y ambas pueden aparecer mezcladas. Digamos que la segunda es más técnica, una visión más analítica del juego en busca de fallos o desequilibrios en al mecánica del mismo.
Este tipo de informes se basan en partidas con cronología, que analizan el comportamiento del juego y el pakset en un determinado lapso de tiempo o época. Sirve para ver si la mecánica está compensada, si la economía es favorable o desfavorable al jugador, si los vehículos existentes son rentables o deficitarios, si existen suficientes vehículos, si la época contemplada está debidamente ambientada con edificios y vehículos correspondientes. Ese tipo de cosas...
Supongo que existen muchos, y como hemos dicho con mayor o menor grado de detalle como por ejemplo el hilo del foro hispano de Simutrans donde la gente va colgando sus avances y se discuten estrategias y decisiones, no es tanto un informe completo sino un intercambio de ideas.
Uno de los que más me ha gustado (sobre todo porque no está en alemán.. :P) es NiNiWania - 19th Century from 1830 to 1900 creado por Lodovico. Si no recuerdo mal fue uno de los pioneros en este tema. El informe trata de una partida con pak64 y cronología entre 1830 y 1900, siglo XIX. Está muy bien estructurado, con imágenes de la evolución de las ciudades, comentarios divididos por años, muchas capturas de pantalla y seguimiento completo de las finanzas año a año. Otra ventaja es que a pesar de estar en inglés, no contiene mucho texto lo cual lo hace muy ameno.
Si echaís un vistazo por encima, la mayoría de la decisiones que toma son bastante sensatas y consecuentes. Siempre opta por los vehículos más rentables, y más baratos a ser posible, explicando las razones de su elección basada en criterios como capacidad, rentabilidad, coste operativo, etc...
Por otro lado sigue una de las máximas de Simutrans, que reza..
Si seguís leyendo, comprobareís opta por conectar las industruías existentes en ese momento, con los vehículos más optimos, y unas lineas más abajo aparecen las primeras conclusiones. Recomienda no usar un carruaje para papel y como en esa época no existen las señales de elección de parada vacía tienes que poner varias paradas y varias líneas sirviendo en la misma ruta, lo cual te lleva a tener atascos de tráfico.
Esto es una constante a lo largo de todo el informe. Primero valora su situación económica, revisa las nuevas oportunidades de transporte, toma decisiones y explica el razonamiento seguido, y por último analiza las consecuencias de dichos actos.
A veces hace "trampas" y compra nuevas industrias para aumentar las oportunidades, pero el análisis de los vehículos es muy concienzudo. Realmente te muestra cuando hay que optar por un tipo de vehículo u otro, y hace una extensa revisión de todas las locomotoras antiguas a vapor, con sus pros y sus contras.
Todas sus decisiones son muy precavidas, conservadoras y meditadas. Cuando ve que un vehículo da pérdidas, inmediatamente inicia la búsqueda de un posible reemplazo o simplemente ignora dicha ruta o mercancía.
Algunas de las conclusiones que se obtienen del informe:
Enlaces relacionados:
Leer más...
Primero hay que decir que no es estrictamente necesario ser un jugón para hacer este tipo de cosas, pero si ayuda. En otra ocasión comentamos que hay gente que juega por placer y otra como reto personal, lo cual no es malo pero son dos formas totalmente distintas de afrontar una partida de Simutrans, y ambas pueden aparecer mezcladas. Digamos que la segunda es más técnica, una visión más analítica del juego en busca de fallos o desequilibrios en al mecánica del mismo.
Este tipo de informes se basan en partidas con cronología, que analizan el comportamiento del juego y el pakset en un determinado lapso de tiempo o época. Sirve para ver si la mecánica está compensada, si la economía es favorable o desfavorable al jugador, si los vehículos existentes son rentables o deficitarios, si existen suficientes vehículos, si la época contemplada está debidamente ambientada con edificios y vehículos correspondientes. Ese tipo de cosas...
Supongo que existen muchos, y como hemos dicho con mayor o menor grado de detalle como por ejemplo el hilo del foro hispano de Simutrans donde la gente va colgando sus avances y se discuten estrategias y decisiones, no es tanto un informe completo sino un intercambio de ideas.
Uno de los que más me ha gustado (sobre todo porque no está en alemán.. :P) es NiNiWania - 19th Century from 1830 to 1900 creado por Lodovico. Si no recuerdo mal fue uno de los pioneros en este tema. El informe trata de una partida con pak64 y cronología entre 1830 y 1900, siglo XIX. Está muy bien estructurado, con imágenes de la evolución de las ciudades, comentarios divididos por años, muchas capturas de pantalla y seguimiento completo de las finanzas año a año. Otra ventaja es que a pesar de estar en inglés, no contiene mucho texto lo cual lo hace muy ameno.
Si echaís un vistazo por encima, la mayoría de la decisiones que toma son bastante sensatas y consecuentes. Siempre opta por los vehículos más rentables, y más baratos a ser posible, explicando las razones de su elección basada en criterios como capacidad, rentabilidad, coste operativo, etc...
Por otro lado sigue una de las máximas de Simutrans, que reza..
Para evitar la bancarrota, debes empezar por el transporte de mercancías
Si seguís leyendo, comprobareís opta por conectar las industruías existentes en ese momento, con los vehículos más optimos, y unas lineas más abajo aparecen las primeras conclusiones. Recomienda no usar un carruaje para papel y como en esa época no existen las señales de elección de parada vacía tienes que poner varias paradas y varias líneas sirviendo en la misma ruta, lo cual te lleva a tener atascos de tráfico.
Esto es una constante a lo largo de todo el informe. Primero valora su situación económica, revisa las nuevas oportunidades de transporte, toma decisiones y explica el razonamiento seguido, y por último analiza las consecuencias de dichos actos.
A veces hace "trampas" y compra nuevas industrias para aumentar las oportunidades, pero el análisis de los vehículos es muy concienzudo. Realmente te muestra cuando hay que optar por un tipo de vehículo u otro, y hace una extensa revisión de todas las locomotoras antiguas a vapor, con sus pros y sus contras.
Todas sus decisiones son muy precavidas, conservadoras y meditadas. Cuando ve que un vehículo da pérdidas, inmediatamente inicia la búsqueda de un posible reemplazo o simplemente ignora dicha ruta o mercancía.
Algunas de las conclusiones que se obtienen del informe:
- Son necesarias locomotoras para periodo 1850-1870, con potencia 50-200 kw y coste operativo 1,5-2.5 cr/km
- Vagón de pasajeros para 1850-1870
- Vagón para áridos para antes de 1870 (10 tn., menos de 0,5 cr(km))
- Vagones para acero y madera más ligeros que los actualmente disponibles para dicho periodo
- Nuevos barcos para el periodo 1890-1900
Enlaces relacionados:
- Informe Silverfuxx en alemán
- Informe Bossilein en inglés
- NiNiWania por Lodovico, en inglés
- The World in pak64 por fuzion_051, en inglés
14/5/09
Simutrans en los Premios SourceForge
En SourceForge, el mayor repositorio de software del mundo, va a entregar los premios a los mejores projectos de 2008. Estamos haciendo campaña para que Simutrans pueda conseguir el premio como mejor proyecto para jugadores (Best Project For Gamers) así que animo a todos a que voteís por ello.
Leer más...
Rellenad este formulario donde lo único que tenís que escoger es la categoría Best Project For Gamers e introducir vuestro correo electronico. Tras emitir el voto, teneís que confirmarlo por mail, pulsando en el enlace incluido en el correo que os mandarán. ¡¡Todos a votar!!
Leer más...
Rellenad este formulario donde lo único que tenís que escoger es la categoría Best Project For Gamers e introducir vuestro correo electronico. Tras emitir el voto, teneís que confirmarlo por mail, pulsando en el enlace incluido en el correo que os mandarán. ¡¡Todos a votar!!
22/10/08
Zambulléndose en Simutrans (IV): una pequeña modificación
Una vez que sabemos obtener el código, compilarlo y aplicar un parche, solo nos falta pensar en una modificación y aplicarla. Vamos a realizar una pequeña modificación que nos dará la posibilidad de tener convoys ferroviarios de más de 24 vagones, que es el límite actual.
Leer más...
Tengo que confesar que en este caso juego con ventaja, porque esto ya fue propuesto por otras personas y Prissi, el desarrollador que coordina Simutrans, dijo donde había que tocar para conseguir que los convoyes ferroviarios tuvieran más de 24 vagones.
De todas formas, como en cualquier proyecto que abordas, ya sea para modificarlo o para crear cosas nuevas desde cero, es necesaria algo de intuición. A primera vista, si pensamos donde habría que modificar para conseguir aumentar la longitud máxima del convoy, es probable que no supieramos por donde empezar....
Dando unas pocas vuelta más al asunto, podemos asociar los convoys con los depósitos o cocheras. Realmente no hay muchos más candidatos. Las estaciones no influyen en la disposición del convoy y el resto de estructuras ferroviarias como los puentes y los túneles tampoco tienen porque. ¿Los trenes en sí mismos? uhmm...podría ser, pero el juego está diseñado usando el paradigma de la orientación a objetos, por tanto los convoys no se consideran como un todo, sino como la asociación de varios objetos(instancias) de la clase tren. En ese caso, el único candidato que nos queda es el depósito de trenes.
Aunque el código de Simutrans está en alemán, gran parte de los comentarios están en inglés. En el idioma de shakespeare, cochera o depósito es depot, así que podemos empezar la busqueda por algun fichero que cuyo nombre contenga dicho término. ¡¡anda, mira por donde existe un fichero llamado simudepot.h!!
Abrimos el fichero con un editor de texto (Notepad, Vim, UltraEdit) y como podeís comprobar esta escrito en C++. El archivo contiene un conjunto de clases que representan a los distintos tipos de cocheras que existen en Simutrans (bus, camión, maglev, tren, tranvía, monorraíl, avión y ferry). Las distintas clases empiezan siempre por
Como lo que nos interesa es la parte de trenes, nos situamos en la línea 219 que contiene lo siguiente:
No tengo ni idea de lo que significa, pero tres líneas más abajo aparecen las palabras Lokomotive y Waggon, por lo tanto supongo que esta será la parte relacionada con la cochera de trenes.
Proseguimos el rastreo. Lo que buscamos está relacionado con la longitud del convoy. Longitud en inglés es length. Si miramos unas líneas más abajo, concretamente en la 245, aparece la siguiente instrucción:
Parece que lo que hace esta función es obtener el valor de la longitud máxima de un convoy ferroviario. Para esto, consulta el atributo max_rail_vehicle del objeto convoi_t y devuelve su valor. Parece que hemos encontrado lo que buscábamos, ¿no?
En este punto tenemos dos opciones. Podemos poner un valor entero, como aparece en algunos de los otros depósitos, lineas 333 para bus,398 para avión y 370 para ferry. La otra opción es buscar donde se define el valor de dicho atributo max_rail_vehicle y modificarlo. Evidentemente la segunda opción supone más búsqueda en otros ficheros, principalmente los que se mencionan a partir de la línea 11, precedidos por la palabra include. Un buen candidato sería convoihandle_t.h
En este caso vamos a optar por la primera, por ser más fácil y rápida. Pues bien, sustituimos el contenido de la línea 245 por este otro:
que simplemente le dice que la long. máxima para un convoy ferroviario será de 30 vagones.
Ahora guardamos los cambios y solo nos queda compilar el código de nuevo. Si no sabes como, repasa este artículo sobre el tema. Una vez tenemos el ejecutable, comprobamos que los cambios han surtido efecto, creando un convoy de 30 vagones (1+29).
Como comprobareís no funciona porque aunque te deja comprar hasta 30 vagones, no los muestra cuando el vehículo sale del depósito. Eso significa, entre otras cosas, que la variable max_rail_vehicle tiene un valor fijo en algún lado, solo para cuando tiene que mostrar los elementos que componen el convoy en pantalla. Para solucionar esto, primero pulsamos deshacer para dejar esa línea como estaba y después hacemos una búsqueda del término max_rail_vehicle en todos los archivos con extensión *.cc o *.h. Entre los distintos resultados de la búsqueda, no fijamos en los relacionados con el archivo simconvoi.cc:
Esta lineas no usan un método get sino que obtiene el valor de la variable de forma directa. Además, en el fichero simconvoi.h vemos la siguiente línea:
Si cambiamos ese valor 24 por 30, guardamos los cambios y compilamos de nuevo, comprobaremos que ahora si muestra los 30 vagones del convoy.
Podeís hacer otra prueba poniendo menos vagones, digamos 10, y comprobando que no te deja comprar más de dicha cantidad.
Como veís es algo sencillo y fácil de hacer. Pequeñas modificaciones como estas se pueden hacer a cientos, solo teneís que bucear un poco en el código. En futuros artículos propondremos otros pequeños cambios.
No quisiera terminar, sin agradecer la inestimable ayuda de isidoro en este tema, a la hora de resolver mis dudas. Muchas gracias.
Relacionados:
Zambulléndose en Simutrans (I): A por el código.
Zambulléndose en Simutrans (II): compilando el código fuente
Zambulléndose en Simutrans (III): aplicando un parche
Leer más...
Tengo que confesar que en este caso juego con ventaja, porque esto ya fue propuesto por otras personas y Prissi, el desarrollador que coordina Simutrans, dijo donde había que tocar para conseguir que los convoyes ferroviarios tuvieran más de 24 vagones.
De todas formas, como en cualquier proyecto que abordas, ya sea para modificarlo o para crear cosas nuevas desde cero, es necesaria algo de intuición. A primera vista, si pensamos donde habría que modificar para conseguir aumentar la longitud máxima del convoy, es probable que no supieramos por donde empezar....
Dando unas pocas vuelta más al asunto, podemos asociar los convoys con los depósitos o cocheras. Realmente no hay muchos más candidatos. Las estaciones no influyen en la disposición del convoy y el resto de estructuras ferroviarias como los puentes y los túneles tampoco tienen porque. ¿Los trenes en sí mismos? uhmm...podría ser, pero el juego está diseñado usando el paradigma de la orientación a objetos, por tanto los convoys no se consideran como un todo, sino como la asociación de varios objetos(instancias) de la clase tren. En ese caso, el único candidato que nos queda es el depósito de trenes.
Aunque el código de Simutrans está en alemán, gran parte de los comentarios están en inglés. En el idioma de shakespeare, cochera o depósito es depot, así que podemos empezar la busqueda por algun fichero que cuyo nombre contenga dicho término. ¡¡anda, mira por donde existe un fichero llamado simudepot.h!!
Abrimos el fichero con un editor de texto (Notepad, Vim, UltraEdit) y como podeís comprobar esta escrito en C++. El archivo contiene un conjunto de clases que representan a los distintos tipos de cocheras que existen en Simutrans (bus, camión, maglev, tren, tranvía, monorraíl, avión y ferry). Las distintas clases empiezan siempre por
class tipodepot_t : public depot_t
Como lo que nos interesa es la parte de trenes, nos situamos en la línea 219 que contiene lo siguiente:
class bahndepot_t : public depot_
No tengo ni idea de lo que significa, pero tres líneas más abajo aparecen las palabras Lokomotive y Waggon, por lo tanto supongo que esta será la parte relacionada con la cochera de trenes.
Proseguimos el rastreo. Lo que buscamos está relacionado con la longitud del convoy. Longitud en inglés es length. Si miramos unas líneas más abajo, concretamente en la 245, aparece la siguiente instrucción:
unsigned get_max_convoi_length() const { return convoi_t::max_rail_vehicle;
Parece que lo que hace esta función es obtener el valor de la longitud máxima de un convoy ferroviario. Para esto, consulta el atributo max_rail_vehicle del objeto convoi_t y devuelve su valor. Parece que hemos encontrado lo que buscábamos, ¿no?
En este punto tenemos dos opciones. Podemos poner un valor entero, como aparece en algunos de los otros depósitos, lineas 333 para bus,398 para avión y 370 para ferry. La otra opción es buscar donde se define el valor de dicho atributo max_rail_vehicle y modificarlo. Evidentemente la segunda opción supone más búsqueda en otros ficheros, principalmente los que se mencionan a partir de la línea 11, precedidos por la palabra include. Un buen candidato sería convoihandle_t.h
En este caso vamos a optar por la primera, por ser más fácil y rápida. Pues bien, sustituimos el contenido de la línea 245 por este otro:
unsigned get_max_convoi_length() const { return 30; }
que simplemente le dice que la long. máxima para un convoy ferroviario será de 30 vagones.
Ahora guardamos los cambios y solo nos queda compilar el código de nuevo. Si no sabes como, repasa este artículo sobre el tema. Una vez tenemos el ejecutable, comprobamos que los cambios han surtido efecto, creando un convoy de 30 vagones (1+29).
Como comprobareís no funciona porque aunque te deja comprar hasta 30 vagones, no los muestra cuando el vehículo sale del depósito. Eso significa, entre otras cosas, que la variable max_rail_vehicle tiene un valor fijo en algún lado, solo para cuando tiene que mostrar los elementos que componen el convoy en pantalla. Para solucionar esto, primero pulsamos deshacer para dejar esa línea como estaba y después hacemos una búsqueda del término max_rail_vehicle en todos los archivos con extensión *.cc o *.h. Entre los distintos resultados de la búsqueda, no fijamos en los relacionados con el archivo simconvoi.cc:
fahr.resize(max_rail_vehicle, NULL);
fahr.resize(max_rail_vehicle, NULL);
Esta lineas no usan un método get sino que obtiene el valor de la variable de forma directa. Además, en el fichero simconvoi.h vemos la siguiente línea:
enum { max_vehicle=4, max_rail_vehicle = 24 };
Si cambiamos ese valor 24 por 30, guardamos los cambios y compilamos de nuevo, comprobaremos que ahora si muestra los 30 vagones del convoy.
Podeís hacer otra prueba poniendo menos vagones, digamos 10, y comprobando que no te deja comprar más de dicha cantidad.
Como veís es algo sencillo y fácil de hacer. Pequeñas modificaciones como estas se pueden hacer a cientos, solo teneís que bucear un poco en el código. En futuros artículos propondremos otros pequeños cambios.
No quisiera terminar, sin agradecer la inestimable ayuda de isidoro en este tema, a la hora de resolver mis dudas. Muchas gracias.
Relacionados:
Zambulléndose en Simutrans (I): A por el código.
Zambulléndose en Simutrans (II): compilando el código fuente
Zambulléndose en Simutrans (III): aplicando un parche
Suscribirse a:
Entradas (Atom)