[PC] Slaves to Armok II: Dwarf Fortress

No os voy a mentir, esto es un clon (actualizado y ampliado) de la antigua entrada que hice de Dwarf Fortress pero con motivo de ACTUALIZAR el enorme pack que hice con utilidades, skins, enlaces, y un sin fin de cosas. Así que:

¿De qué va Dwarf Fortress?

Es una mezcla de todo, elementos de juegos de estrategia, de rol, de construcción, enanitos locos, Sims, dungeon crawlers… Único.
Tu propósito es levantar una fortaleza enana en un mundo que cambia a cada partida y en el que TODO puede pasar, desde un ataque goblin, a que tus enanos se mueran ahogados en su propia mierda, se suiciden, exploten experimentando, se depriman, se cabreen con vosotros y os destruyan el castillo… como he dicho antes, algo único, TAN unico que algunos fans del juego han hecho fortalezas increíbles completamente gestionadas hasta un mismísimo ordenador funcional con todos sus componentes de hardware hecho a mano (increíble obra de ingeniería, en serio) con los componentes de construcción del propio juego. El juego tiene un sistema de físicas muy complejo, incluyendo gravedad (cuidado con cavar cuevas muy anchas sin columnas!) sistema de hidráulicas, presiones, magma, volcanes, erosión, temperatura, química, y paro porque no acabaría.

Review:

Bueno, lo primero es lo primero, aspectos positivos y negativos del juego.

Positivo:

• Experiencia de juego muy distinta a los típicos juegos comerciales o indie.
• Da para horas y horas y horas y horas (y horas) de probar cosas distintas, el juego ademas anima a ello. Si te encuentras atascado, visita la wiki!
• Situaciones (o eventos, como se llama en el juego) que cambian siempre, ninguna partida es como la de otra persona, pueden ocurrir cosas similares, pero vuestras historias jamas se parecerán.
• No hay ningún juego tan profundo como este
• Pica muchísimo, es bastante adictivo.
• Gratuito y multiplataforma

Negativo:

• Aspecto gráfico bastante ausente, empezó siendo solo con caracteres ASCII, pero ya tiene sprites decentes en la versión estándar, no obstante puedes jugar a cualquier versión, tanto ASCII, como básica, como otras que hay por ahí, algunas realmente buenas con gráficos en isométrico. Así que se puede decir que está subsanado en parte.
• Dificultad MUY elevada en muchas ocasiones (dependiendo de como juguemos claro!)
• Curva de aprendizaje jodida, tienes que echarle una tarde para controlar los menús y saber como va esto (muy por encima!). TODO se maneja con controles de teclado.
• Esta en inglés y, aunque yo no he tenido mayor problema, no obstante el juego tiene una gran riqueza en su vocabulario por lo que si no sabes muy bien inglés te recomiendo tener al lado Google Translate para traducir palabras sueltas.

¿Y ahora… qué?

Hay tutoriales completos en ingles, simplemente con visitar la Wiki oficial (es enorme) del juego o realizando una sencilla búsqueda en Youtube. También los hay en español, aunque sean un poco antiguos y no profundicen tanto como los ingleses, pero es lo que hay, ya que el juego está íntegramente en inglés y tendremos que jugarlo así.

Por mi parte, os he recopilado un pack actualizado con todas las herramientas / utilidades más útiles del juego, packs de texturas, enlaces de interés a webs relacionadas (como el archivo de mapas, un repositorio de más utilidades, wikis, tutoriales a punta pala, etc larguisimo). Aparte de estos enlaces, también están descargados varios tutoriales en PDF así como el propio juego actualizado y comics e imágenes, y todo ello categorizado en carpetas y con sus correspondientes enlaces para que podáis visitar la fuente del recurso (para que podáis descargar sus actualizaciones en caso de que las sufran).

 

Sin más, os dejo aquí el pack, pero esta vez en MEDIAFIRE, ya que Megaupload ha muerto llevándose consigo a la tumba el anterior pack (aunque no es una pérdida muy grave, ya que estaba desactualizado y este trae lo que tenía el anterior más miles de cosas más, lo veréis por el peso del mismo):

 

Dwarf Fortress Pack Parte 1/3 [Mediafire]

Dwarf Fortress Pack Parte 2/3 [Mediafire]

Dwarf Fortress Pack Parte 3/3 [Mediafire]

 
Saludos !

Fuck yes [DJ Max Portable 2]

Se aproximan cientos de horas de vicio y dolor de pulgares….

 

 

PD: Que sí, que hoy en día todos conocemos el remote joy, la ultima vez que lo usé fue hace bastantes años y estaba demasiado verde. Ahora es un gustazo. Va fluidísimo!

[Opinión personal] El nacimiento de un videojuego

Aunque esto va más orientado realmente a la creación del proyecto de un videojuego, ¡mejor aún!

Veamos, quiero hablar sobre aquellos proyectos en los que personas (generalmente jóvenes o neófitos en el tema con muchas ganas y poca experiencia) crean un “llamamiento” (ya sean diseñadores, programadores, etc) para llevar a cabo un proyecto el cual está (generalmente) vagamente diseñado. Por ejemplo, típica persona que se apunta a un foro en el que sabe que pulula al menos gente interesada en el tema, y crea un hilo en el que busca a un número de personas (cuantas más siempre mejor, ¡claro!) a las que clasifica en categorías (va poniendo una lista categorizándolas, un grupo para los diseñadores, otro para los programadores, etc…), usando como reclamo un par de frases descriptivas de lo que quiere hacer o algún boceto, ya sea un juego shooter, un plataformas, un clonico del pacman, etc. Bien, esta persona (o personas) casi nunca cuentan con nada hecho, como mucho un par de bocetos o requisitos del juego de una forma mas o menos poco detallada. Y claro, imagino que habréis visto en qué acaba la mayoría de estos proyectos…

Creo que el que más lejos llegó fue uno en el que crearon una web y un foro con registro cerrado para esas personas a las que “reclutaron”. Llegaron a crear: Por parte de los diseñadores, un par de bocetos o tiras de sprites de calidad discutible. Por parte de los programadores discusiones y discusiones sobre qué lenguaje/librerias/programas/herramientas usar, con screens de esos programas para ver qué se podría llegar a hacer, y, por parte del que lo ha “organizado” todo, un par de detalles del juego de qué podría tener o algún boceto más sobre como podría ser un nivel del mismo. NADA MAS, hasta ahí he visto yo. Una vez se llega a este punto el 80% mínimo de la gente “reclutada” ha abandonado o ha desaparecido, y el resto resultante está en un caos de organización tan masivo y con tan poca documentación en la que basar su trabajo, que no pueden hacer más que esperar o intentar liar más el rizo.

Pues no, esto así no se hace. Aparte de la insistencia de aquellas personas a las cuales se ha de reclutar (y deben de ser de confianza o demostrar experiencia previa en otros proyectos), NO se puede crear software entre varios programadores desde cero. Es decir, reunir a un grupo de programadores (con una estructura jerarquizada o no, eso da igual) y empezar a hacer algo del cual no tienen un análisis previo hecho, es imposible, totalmente imposible.

Para que un proyecto salga adelante, PRIMERO debe de haberse realizado un análisis previo y definido unos requisitos del mismo lo más detallados posibles (es decir, unos documentos donde recogen qué hará el software, que no hará, y de que forma lo hará, documentar en lo posible toda la funcionalidad y capacidad del mismo). Una vez se tienen hechos (este paso SI se puede hacer entre varios, pero para ello debe haber una gran comunicación y experiencia previa por parte de los analistas involucrados), entonces hay dos salidas: O bien utilizar un engine existente (como unreal engine, cryengine, game maker, allegro, c4 engine, rpg maker, unity, o un etc muy largo…) desde el cual ya se puede comenzar con un grupo existente de personas para repartir el trabajo (ya que la base está hecha) O BIEN plantearse el diseñar el engine del videojuego desde cero, partiendo de librerías como OpenGL+SDL, XNA, o derivados (todas estarán basadas en DirectX o OpenGL, TODAS). Si se opta por lo segundo, no se puede meter a varios programadores a programar en un código inexistente desde 0 (por muy bonito que tengáis configurado el SVN o GIT). Por ello es inútil el molestarse en buscar a esas personas que te harán los gráficos, sonidos, niveles o la propia IA de los enemigos ANTES de tener creado el engine del videojuego, ya que sino estarán de brazos cruzados hasta que se tenga hecho (ya que sin el no pueden comenzar), y esto ocasionará que huyan del proyecto ya que no se les dará trabajo para hacer (si, empezarán con muchas ganas, pero a la semana se les habrá olvidado que les “reclutaste”).

Resumiendo, los pasos correctos (a MI parecer, tened en mente que es una opinión personal) para que un proyecto salga adelante en condiciones y no se abandone a la primera de cambio son (partiendo de que eres tu el que vas a organizarlo, si eres de los que reclutan esto no tiene mucho sentido, al menos puede servirte para detectar si el barco se va a pique o no):

• Primero, si no tienes conocimientos previos de como realizar el proyecto, estudia, practica, haz mini-ejemplos (prototipos) básicos de lo que pensabas hacer, lee MUCHO, aprende inglés si es que no sabes ya (o estas perdido en cuanto a búsqueda de información en internet), y sobre todo no esperes que alguien haga todo el trabajo por ti y luego te lleves el reconomiento. Eso nunca pasará.
• Segundo, no vale pensar en ese proyecto 5 min y hacer un txt o un boceto con 4 cosas que podría tener como “concepto”, NO. Pasa todas las horas que puedas creando documentación que recoja los requisitos del videojuego, qué niveles tendrá y como, su historia o argumento (si tiene), enemigos, menús, sistema de juego, HUD, nº de jugadores, etc. Todo dato que puedas aportar detallando más y más será de utilidad. (Obviamente hazlo documentándolo propiamente, nada de lenguaje “hoygan” en un txt plano.
• Decide antes las herramientas a utilizar, recursos, webs útiles y lo más importante, el lenguaje de programación y librerías a usar (o engine). Este será el pilar #1 del juego, así que mucho cuidado con lo que elijes. Mi recomendación personal es aprender C/C++ y usar SDL+OpenGL (dejad un comentario para preguntar más detalles).
• Una vez hecho el paso anterior, diseña y construye TU SOLO la base del engine para el juego (por eso dije lo que dije en el primer paso). No digo que creas el juego entero por ti mismo, sino que el sistema de entidades en el mapa funcione, tengas funciones para la carga de recursos (como imágenes y sonido), el bucle principal del juego, entre otras cosas y todo muy bien estructurado, ya que en esto se basará TODO. El objetivo es conseguir un engine orientado al videojuego que quieras crear Y que esté MODULARIZADO. Es decir, que si alguien modifica el código de sonido o de IA de algún enemigo, NO se tenga que modificar nada más para que el juego siga funcionando. De esta forma varios programadores podrán repartirse la tarea sin que el trabajo de uno afecte al trabajo de otro (algo fundamental).
• Una vez tengas el engine creado, funcionando y tengas un prototipo FUNCIONAL, entonces es el momento de buscar y reclutar a gente. Muéstrale lo que tienes hecho, dí a donde quieres llegar, crea algunas demos técnicas de tu engine para que la gente se anime y se apunte al proyecto (te aseguro que teniendo esto hecho vas a notar una diferencia brutal en cuanto a la cantidad de gente dispuesta a unirse al proyecto en comparación si no hubieras tenido casi nada hecho).
• Reparte tareas, ¿recuerdas la documentación que te dije que hicieras del juego? Gracias a ella sabrás que hace falta por hacer y podrás repartir las tareas fácilmente. Comparte esa documentación con todo el que esté involucrado en el proyecto. Así sabrán como debería ser el juego una vez acabado y podrán aportar sus trabajos pensando en ello y dando su toque personal, y NO a ciegas. Mantén a la gente motivada y todo debería acabar bien.

Bueno, y esto es básicamente como se debería comenzar un proyecto en condiciones. Como he dicho, es una opinión personal basada en la lógica y en la experiencia (de lo que he visto, yo no he ido por ahí reclutando a todo un foro para terminar haciendo un hello world xD). Si queréis ahondar más en el tema, hace tiempo publiqué una entrada en la que hablaba de los motivos por los que acaban los proyectos orientados a videojuegos (haced click y leedla, es bastante interesante -> Por qué acaban los proyectos )

Por último, os dejo con un cuento de NightFox que no tiene desperdicio, con moraleja y todo. Aquí va:

—————————————————-

“El cuento del programador y la lechera”

Erase una vez un chavalin que soñaba con ser programador y crear sus propios videojuegos. Había escrito algún programa y estaba lleno de ilusión. Quiso empezar con algo simple, un pong y empezó a ello. Cuando tenia algunas lineas de código escritas, pensó, un pong es muy simple, yo quiero destacar, así que se dijo, bueno, un pong quizás es demasiado fácil, que tal si hago algo mas vistoso, si, un mario, así que empezó a programar, a dibujar algunos fondos, algún sprite y cuando ya tenia eso en pantalla dijo, el mario esta muy visto, que tal si le pongo una ametralladora y que pueda disparar a los Koopas. Empezó sobre el papel a hacer diseños y pensar que estaría bien. Mientras pensó, pero claro, un toque de rol molaría, como el Pokemon, poder subir de nivel, personalizar el personaje y empezó a buscar gráficos sonidos para su homebrew. Cuando tenia mucho material reunido, su programa mostraba (solo) la pantalla de titulo y un menú pensó, bueno, como ya esta empezado, hagamos un mundo mas abierto, como GTA.

Entonces le visito un amigo suyo y le pregunto: “oye, hay un concurso de programación de videojuegos, ¿vas a presentar tu juego?”. Nuestro chavalin le contesta: “¡si! Pero lo he cambiado, ahora no es un pong, es un GTA + RPG + MARIO + POKEMON + ARCADE”. El amigo sonríe y le dice: “Se que has aprendido mucho, pero, en dos meses, crees que seras capaz de aprender todo lo que te falta, dibujar toda esa cantidad de fondos, sprites, hacer las músicas, sonidos…”

¿Me dices que TU que hace 2 meses que programas (con suerte) harás el mismo trabajo que un equipo experto de 30 personas en 1 año?
En ese momento el castillo megachachi mágico que se había montado nuestro colega en su cabecita se vino abajo y vio que lo que pretendía era una salvajada, imposible de realizar.

Moraleja del cuento: Si alguien se cree que el solo o un grupo de 4 o 5, harán el mismo trabajo que un equipo de profesionales en una décima parte del tiempo que lo hacen ellos, no se, cuando toquen de pies en el suelo igual se fracturan las piernas de la ostia que se pegan. Así que, sed realistas, calculad que posibilidades REALES tenéis de llevar a cabo un proyecto en el tiempo que os marquéis, hacedlo y no os desviéis de lo que tenéis proyectado. Así estaréis en ese 5% de proyectos que se terminan.

—————————————————-

¡ Hasta la próxima entrada !

SpaceChem – Más que un juego

Source original: http://blog.darkhogg.es/2011/07/spacechem-mas-que-un-juego/

Cualquiera que sepa algo de Zachtronics Industries sabe de qué hablo cuando digo que sus juegos no son exactamente para toda la familia. Zach tiene por costumbre hacer juegos de puzzle poco convencionales, más enfocados a la resolución de problemas en general que con encontrar una solución concreta a un nivel concreto. SpaceChem es todo eso y más.

(Que no te engañe la imagen, el juego tiene una curva de dificultad fácil de tomar)

En SpaceChem debemos transformar una serie de átomos y moléculas en otros, usando para ellos reactores. Estos reactores contienen dos elementos mecánicos que nos permiten mover, rotar, unir, separar, etc. los elementos de entrada para transformarlos. Nuestros ‘waldos’ se desplazan por el escenario siguiendo un camino concreto que nosotros mismos hacemos, ejecutando órdenes a su paso. En ciertos niveles podemos unir más de un reactor de este tipo para formar una cadena de producción.

Como una imagen vale más que mil palabras, digo yo que un vídeo valdrá bastante más:

 

Lo que hace a SpaceChem diferente de otros juegos de puzzle es la infinidad de soluciones válidas a las que se pueden llegar en un mismo nivel. Tanto que el calificativo de puzzle se le queda corto: En los puzzles típicamente existe una única solución correcta, o variaciones de dicha solución, que el diseñador oculta de alguna forma y nos deja la tarea de encontrarla. SpaceChem es más que eso, es un juego de resolución de problemas: Dadas unas herramientas (los reactores) y unos materiales (las entradas al reactor), hemos de apañárnoslas para conseguir unos productos (las salidas del reactor). No existe ninguna pista de cómo hemos de hacerlo, eso es justamente lo que hemos de conseguir nosotros. Nuestro objetivo no es descubrir la intrincada solución que pensó el diseñador, sino idear una nosotros mismos, que puede ser o no similar a la que dicho diseñador pensó en un principio (si es que pensó alguna). A su vez éste tipo de juegos nos da la posibilidad de medir de alguna manera cómo es nuestra solución de buena, según el número de ciclos que tarda o de símbolos usados, por ejemplo.

No es secreto que Zach diseña lo que él mismo llama juegos para ingenieros. Uno de sus juegos, KOHCTPYKTOP, nos introduce de lleno en la piel de un ingeniero electrónico. Por suerte para todos, los siguientes juegos que hizo no eran tanto para ingenieros, aunque conservaran ese ambiente ingenieril que define a Zach. Estoy hablando de The Codex of Alchemical Engineering y SpaceChem (y un poco en menor medida, de The Bureau of Steam Engineering). SpaceChem es, en realidad, la evolución lógica de The Codex, tintado de química en lugar de alquimia y cambiando la mecánica fundamental de brazos mecánicos fijos a brazos mecánicos completamente móviles.

The Codex trabaja con un modelo de bucles repetitivos, donde el escenario en sí no repercute de ninguna manera en cómo se comportan los brazos. SpaceChem va un paso más allá permitiendo puntos de sincronización, toma de decisiones basadas en datos externos, sensores e incluso una cierta memoria. A todo ello sumémosle la capacidad de procesamiento paralelo que introduce el tener varios reactores funcionando al mismo tiempo, capacidad que estaba presente en The Codex hasta cierto punto, pero no de forma tan marcada.

A estas alturas cualquiera con un mínimo de conocimientos de programación debería saber a dónde quiero llegar. Y quien no, probablemente esa última frase le haya abierto la mente. Resulta que hay decenas de conceptos de la programación que pueden aplicarse a SpaceChem, desde cuestiones muy básicas hasta conceptos de concurrencia bastante más complejos:

• Ejecución secuencial: Tanto en SpaceChem como en la programación, las instrucciones se ejecutan una a una, en un orden determinado y una detrás de otra.
• Bucles: En SpaceChem, el objetivo principal es producir un número concreto de moléculas o átomos. Generalmente las soluciones se construyen de forma que el sistema funciona correctamente de forma indefinida (no siempre es así, luego hablaré de ello). En programación igualmente existen bucles que nos permiten realizar un cierto proceso de forma indefinida. Los videojuegos y los sistemas operativos en realidad no son más que un bucle casi infinito (puesto que se puede terminar) que ejecuta las instrucciones adecuadas.
• Modularización de la solución: En muchísimas ocasiones nos encontramos niveles en los que se nos presenta una tarea muy complicada que podemos resolver usando tareas más sencillas. En programación esto es el día a día, y dudo que nadie sea capaz de programar bien sin realizar una buena división de tareas.
• Entrada y salida con bloqueo: Cuando en SpaceChem tratamos de ejecutar una instrucción INPUT y no hay nada disponible, o un OUTPUT y la tubería de salida está llena, automáticamente el waldo espera a poder realizar la acción. Las operaciones de entrada y salida en programación se comportan exactamente igual en la mayoría de situaciones:bloquean el proceso hasta que existan datos de entrada o sitio a la salida. Lo cual nos lleva al siguiente punto:
• Bloqueo mutuo: Conocido generalmente como deadlock, se trata de una situación en la que dos o más procesos quedan a la espera de recursos que están siendo utilizados por otro de los procesos que forman parte del bloqueo. El ejemplo en SpaceChem se puede encontrar fácilmente en el nivel No Thanks Necessary. Una de las entradas nos aporta N2 y O2 con probabilidades de 25% y 75% respectivamente, es decir, 3 átomos de O por cada átomo de N, con objetivo de conseguir NO3. La solución típica consiste en diseñar un reactor que tome como entrada O2/N2 y envíe átomos de O por la salida superior y de N por la inferior. Este reactor se conecta a un segundo que, a partir de átomos sencillos de O y N, forma el NO3. El problema es que la entrada, aunque a lo largo del tiempo tiende a la uniformidad, es aleatoria, y no podemos asumir que los elementos llegarán exactamente como pensamos (tres O por cada N). En ocasiones podemos llegar a tener 8 O y ningún N, o incluso 4 N y ningún O. Sin espaciar adecuadamente las tuberías, es muy normal que el primer reactor quede a la espera para enviar un O que ya no cabe a la vez que el segundo queda a la espera de un átomo de O que no hay. Ninguno de los dos reactores avanzará, por lo que ambos esperarán indefinidamente. En el mundo de la programación el problema es algo más complicado y generalmente ocurre porque dos procesos distintos tratan de acceder a varios recursos a la vez y en orden inverso, como dos ficheros. La Wikipedia lo explica muy bien, mejor que yo de hecho.

Estos son unos pocos ejemplos, pero hay más cosas que podemos relacionar. Por ejemplo, un reactor puede verse como un proceso con dos hilos (los waldos) que se conecta con el resto de procesos del sistema mediante colas (FIFOs, las tuberías).

Con todo esto, SpaceChem y muchos otros juegos del estilo, son algo más que juegos. Son juegos en cierta manera educativos. Te obligan a pensar de forma muy productiva, puesto que el reto que se te presenta es resolver un problema, con una serie de herramientas, sin ningún tipo de guía, algo a lo que se supone que nos enseñan a los ingenieros en general, y a los informáticos en particular.

[Wallpaper] Enorme recopilación de personajes

A ver quien se sabe el nombre de todos !!! Este wall, tiene un GRAN numero de personajes de anime (sobre todo), videojuegos, etc… es brutal !

Sección de emuladores renovada

Bueno, no pretendo ni mucho menos tener actualizado siempre con la ultima revisión los emuladores, pero nunca está de mas actualizarlos y meter algunos nuevos. Podeis descargarlos pulsando sobre las imágenes de los emuladores en cuestión.

Añadir que el emulador de PS2 necesita de la BIOS de la ps2 para funcionar, en cambio el de GameCube/Wii o el de NintendoDS no precisa nada de eso, funcionan tal cual.

Son revisiones bastante recientes, aunque no las ultimas. Lo que si os puedo asegurar es que son estables y funcionales ^^

 

Para acceder a ella podéis usar el enlace de la barra de arriba o ir directamente aquí

Skygunner – Towards a Far Away Sky

Precioso

Dream of the Shore Near Another World

Como últimamente estoy algo ocupado, os pondré alguna canción de las buenas:

 

Cave Story anunciado para Nintendo 3DS y posible secuela

Cave Story, uno de los títulos indie más populares de la última década junto a Minecraft, tendrá un hueco reservado para su lanzamiento en Nintendo 3DS, esta vez gracias a Nippon Ichi Software of America (Disgaea, ZHP), que hará de distribuidora mientras Nicalis se encarga del proceso de adaptación.

El juego tiene prevista su salida en Norteamérica durante el verano de 2011, y de momento no hay anuncios sobre su posible lanzamiento en Europa. Nicalis está trabajando muy duro para actualizar el juego, manteniendo la misma mecánica, pero con escenarios 3D poligonales que aprovechen la tecnología de la consola y contenido extra. Por primera vez, será lanzado en formato físico, al menos en territorio NTSC.

 

Por si fuera poco, el propio Daisuke ha confirmado a GamesRadar que “tras pasar 10 años desde la aparición de Cave Story, es hora de pensar en una posible secuela”.

Fuente: RamenparaDos | GamesRadar | NintendoMagazine

Nintendo 3DS – Pack limitado OoT

Ojalá se haga realidad (que ni de coña xD). Para los que van a lo loco os aviso:

NOTA: Imagen hecha por un fan, no existe !!! (Aunque joder, es la leche)