[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 !

Merry Christmas 2011

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.

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í

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

[Source+Bin] Motor para crear un videojuego en C++

Bueno, despues de haber aprendido mucho programando esto, he llegado a la conclusión que he de comenzar todo desde el principio, y planificarlo mejor. Hay que añadir que este es el mejor que he programado nunca, pensando en su expansibilidad y reutilización, pero no llega a dar los requisitos que busco, así que descontinuo su desarrollo. OJO, es un motor muy sencillo, no tengo mucha experiencia programando y menos en C++, así que se puede decir que es la primera cosa ‘seria’ que he programado en este lenguaje.

Para que el código no quede abandonado he pensado en liberar el source, y eso estoy haciendo. Aquí abajo teneis el link para descargarlo. Para compilarlo necesitareis un compilador en C++, las librerías de OpenGL y SDL y vuestro IDE favorito (aunque el resultado no es para nada vistoso). Aun pudiendose compilar, lo he subido para que podais ver el código y resolver alguna posible duda que tengais en C++.

 

Descargar Motor C++ (Binarios)

Descargar Motor C++ (Source)

 

PD: Que ganas de ver finalizado mi siguiente intento

Edit: He añadido dos binarios que he encontrado de cuando realizaba Tests

Por qué realizar un prototipo es importante en el Desarrollo de un Videojuego

Me he acostumbrado a la idea de que al comenzar un nuevo juego, es recomendable crear antes un prototipo de este (conteniendo algunas características complejas del mismo, pero sin extenderme mucho), pero… ¿Por qué es tan importante este paso?

Es debido a que a lo largo de este proceso aprenderás mucho. Si realizas un prototipo antes de crear el producto final, lo realizarás mejor, más limpio y mucho más eficiente (además del ahorro de tiempo a largo plazo que esto supone).

¿Así que quieres empezar a trabajar en tu nuevo juego, eh? Has tenido una idea sobre un nuevo y revolucionario juego y piensas que será un bombazo… (quizás), aunque la realidad es que aún ni siquiera hemos empezado el juego.

Bueno, entonces, tienes dos posibilidades:

Puedes o bien escribir cientos de páginas con el diseño del juego y empezar a agobiarte pensando en la cantidad de meses que tardarás en implementar todo esto… o simplemente coger tu IDE favorito y empezar el código. (Nota: un IDE es un entorno de desarrollo integrado, básicamente es aquel programa donde tu escribes tu código)

No pienses demasiado en como diseñarás las clases, sus optimizaciones, contenido, interfaces, etc…. simplemente escribe el maldito código. Si ya escribiste lo básico, juega con el prototipo. Añade cosas que creas que pueden ser interesantes, elimina las que creas que sean superfluas. Comenta con tus amistades qué podría ser interesante añadir, juega y diviértete con el.

El código no tiene por qué ser limpio, tu no lo reutilizarás de todos modos.

¿Cuales son los beneficios de hacer un prototipo?

• Si piensas que tu juego romperá barreras pero es aburrido, lo descubrirás rápidamente.
• Serás más creativo si juegas con tu prototipo en las tempranas fases del diseño del juego.
• Ganarás muchos conocimientos en poco tiempo: ¿Funciona el diseño de tu Base de Datos? ¿Donde están los cuellos de botella que fastidian el rendimiento? ¿Qué hay de los problemas que surgen durante la implementación? Con esta información, podrás diseñar y escribir código mucho más claro y eficiente. Entonces podrás empezar el verdadero proyecto.
• No perderás el tiempo discutiendo si una característica será divertida o no. Simplemente impleméntala en el prototipo y lo averiguarás.
• Podrás realizar mejores estimaciones de duración (para ver si es viable o no un futuro proyecto).
• Conocerás los requerimientos técnicos mejor, y podrás decidir más fácilmente con qué tecnología rendirás más.
• Podrás permitirte fallos y sucios ‘hacks’ sin preocuparte mucho. Si puedes ‘hackearlo’… simplemente hazlo. Realmente no importa. (Nota: A ‘hackear’ código se refiere a arreglar un bug que te haya surgido de ‘mala manera’, escribiendo código que se sale de la planificación general del diseño).
• Podrás concentrarte en la lógica del juego, y no en cosas como la seguridad, rendimiento, aprobechabilidad, etc.
• Podrás usar tu prototipo para mostrar tu idea del juego a un editor. Esto es más efectivo que una aburrida presentación con logotipos por todos lados, etc.

¿Qué deberías tener en cuenta?

La primera regla (y más importante), sin excepciones:  Nunca uses código de tu prototipo en el producto final (o aquel que te de ingresos). ¡O te arrepentirás! Si tu jefe te obliga a hacerlo, debes: Dispararle, golpearle, prender su casa en llamas y destruir el prototipo con todas sus copias de seguridad!

Nunca dejes de pensar. Solo porque puedas escribir código rápido y sucio, no significa que puedas dejar de pensar. Obviamente no necesitas pensar durante todo el día horas y horas, dedícale unos minutos diarios a pensar cómo mejorarlo. Implemente sus ideas. Si no funcionan, piense en otras y vuelva a intentarlo.

Concéntrate en los aspectos más importantes. Trabajar en las cosas que son importantes para acabar el juego es divertido. Lo que no es divertido es pensar qué deberías cambiar para hacerlo divertido. Si piensas que no resultará, deberías parar de desarrollarlo y empezar algo nuevo.

¿Debería pensar en las futuras características?

Si deseas implementar una nueva y complicada funcionalidad en tu juego, las mismas reglas de antes son aplicadas.

Ocurre de vez en cuando, que los programadores piensan en el diseño de su código y en cómo lo implementarán, solo para encontrar luego, que no han tenido en cuenta todas las relaciones o han tenido problemas técnicos. Realizar prototipos conduce a la creación posterior de mejor código que podrá ser mantenido en un futuro, además de que ahorrarás tiempo en las primeras fases intentando pensar en como solucionar cada problema que te surgirá y de las posibilidades que tendrás para solucionarlo.

Además, los diseñadores de juegos podrán aprender del prototipo y les permitirán diseñar mejores juegos o incluso pueden ser inspirados por el.

———————

Nota del traductor: Lo he traducido en apenas 30 min, así que puede contener faltas o algo que no se entienda muy bien. Sobre los “diseñadores de juegos” se refiere a aquellas personas que se dedican a planificar y diseñar en papel la idea principal de un juego, no a programarlo. Es decir, crear su argumento, estilo de juego, características, contenido, etc.

Traducido por JuDelCo - Source original [intermediaware]

Feliz año nuevo 2011 !!!

Este año va a ser épico, brutal y legendario.

Feliz Navidad !!!

Que sus regalen muchos regalitos y os lo paséis muy bien <3

Yay! Nuevo Tema!

A costado decidirse entre varios, ya que ninguno llama la atención. Pero la verdad es que cogiendo un tema normalito como este, y dandole algunos toques personales, como la cabecera o el fondo, queda de maravilla ^_^

Bueno, pues así lo voy a dejar de momento (El skin). Voy a ponerme ahora a modificar las barras laterales y todo eso

さようなら ~~