Muda de piel para mi PC

Bueno, después de tanto tiempo (8-9 años?), ya le tocaba a mi PC hacer un cambio de caja, pues la anterior APENAS tenía ventilación (80 grados en la gráfica era lo normal si me ponía con juegos actuales). La caja era antigua y mala hasta el punto, que solo permitía un triste ventilador en la parte de atrás y el resto era caja cerrada, completamente.

Pero no solo eso, sino que ENCIMA la gráfica NVIDIA GTX 480 que tengo (gracias por el donativo nvidia !) no entraba por culpa del chasis… por lo que tuve que…. doblar el chasis. Sep.

La nueva caja es una NOX Coolbay VX Green Goblin. Aquí teneis un review de la misma. Ahora mi PC estará fresquito por fin 😀 !!!

Aquí van las fotos de la caja antigua con el chasis doblado:

(tiene guasa eh, en fin, nada que no se arregle a mordiscos)

Bonus Pics:

(a mi gatejo le gusta mi placa base *prrr prrr*)

(lamento la calidad de las fotos, mi ZTE Blade no da para más)

Habéis perdido el juego

 

Anuncios

Programa Videojuegos, no Motores

Para empezar, el término “motor” (en su definición vinculada al mundo del desarrollo) no posee una definición concreta, por lo tanto, para que nadie se pierda, intentaré definirlo con mis palabras para utilizarlo en el artículo como busco hacerlo. Un “motor” es una colección de subsistemas bien definidos y reutilizables (generalmente librerías y herramientas) diseñados para facilitar el desarrollo de un videojuego adaptándolos a una serie de requisitos que sean necesarios por el juego en cuestión (estos requisitos pueden ser de muchas categorías bien definidas: Renderizado, sonido, físicas, etc…). Aquellos motores ambiciosos que permiten configurar requisitos de distintas categorías tienden a ser conocidos como “motor de videojuego” en vez de simplemente “motor gráfico” o “motor de físicas” (por ejemplo).

Ahora que nos entendemos, vayámonos con el caso real: “Como programar el motor de un videojuego”.

Por alguna razón, muchos desarrolladores neófitos de videojuegos (y a veces experimentados) tienden a creer que para crear un videojuego necesitan crear primero un motor (ya que piensan que es una parte crítica del mismo). Ellos ven el juego como un coche (un coche sin motor simplemente no funcionará), sin embargo, esa analogía mecánica empieza a venirse abajo cuando nos damos cuenta de la realidad de la situación: un motor está constituido SOLAMENTE por componentes reutilizables. Al igual que puedes construir un coche con piezas reutilizables de otros coches puedes hacerlo con piezas hechas a medida y personalizadas, ¿no es verdad? El hecho de que tengas que tener un motor para programar un videojuego es mentira. Esa leyenda ha sido extendida a lo largo del tiempo por desarrolladores que no sabían hacer nada mejor.

Sin embargo, alguien puede decidir que ha llegado el momento de programar su propio motor, pensando así que entonces podrán crear juegos realmente buenos. Estas personas suelen realizar preguntas solicitando recursos y dudas sobre el diseño y el proceso de desarrollo de estos motores (de hecho si estas leyendo esto es porque probablemente buscabas crear algo similar así que déjame destruir tus sueños con un poco de esfuerzo por mi parte). Continúa leyendo

Mi consejo: Si estás tratando de programar un motor… NO LO HAGAS. No importa cuales sean tus razones (no importa si estas programando el motor para que puedas crear el juego de tus sueños, o si piensas que es una buena técnica de aprendizaje, o cualquier número de razones similares, ya que TODAS son una pérdida de tiempo. Puedes sentarte y escribir un videojuego sin tener un motor creado antes, de hecho es (normalmente) la mejor propuesta por la que puedes optar con diferencia. El proceso de desarrollo de un videojuego es MUCHO más sencillo que el de un motor ya que los requisitos para crear un videojuego están mucho más definidos y clarificados. Además, un videojuego es MUCHO más útil y recompensado que un motor (que suele acabar en un simple tech-demo).

La mayoría de los desarrolladores que “finalizan” un “motor” que fue diseñado y programado aisladamente de la creación de un juego definido (con el objetivo de tener el motor primero)… ¡ no pueden realmente ni usarlos ! (ni serán útiles para terceros). Ya que el proyecto no tuvo ningún fin, ningún límite o utilidad tangible tal proyecto no será de utilidad de cara a un proyecto futuro del cual tomar como base el finalizado, pues una base sin unos buenos pilares no tiene estabilidad ni futuro.Esos “motores” que crean como resultado tienden a ser un poco más que una mezcla de funcionalidad aleatoria inconsistente que no es práctica, robusta ni reutilizable. Además, el resultado “visible” de los motores suelen ser un pequeño mapa en el que puedes caminar y observar pequeños modelos renderizados con ciertos efectos básicos de iluminación, normal mapping, etc. Puede que también hayan implementado cierto sistema de animación o detección de colisiones. Estos proyectos son simplemente demos técnicas y ninguna es visualmente “irresistible” en particular.

La solución, aun si tu realmente quieres programar un motor, es crear EL JUEGO en su lugar. Estoy seguro que pondrás en duda este consejo, pero espera un momento. El juego NO tiene que ser una producción épica. NO tiene que ser GTA5, Quake 17, el próximo Elder Scrolls o el nuevo World of Warcraft. Solo tiene que ser un JUEGO con una jugabilidad bien definida. Es mucho más fácil definir los requerimientos necesarios para crear un juego ! (y además los pondrás en práctica). Una vez hayas hecho un juego, haz otro. Y luego otro (y luego otro,…. y otro… más y más). Cada vez que empieces un nuevo proyecto, identificarás nuevas funcionalidades que podrían ser usadas genéricamente en todos los proyectos para reunirla en una librería de código base. Probablemente tendrás que refactorizar parte de tu código para eliminar las dependencias explícitas del juego en cuestión, pero eso es algo bueno! Te ayudará a generalizar qué es generalizable de una forma en la cual podrás probar la funcionalidad genérica con tu juego acabado y confirmar que funciona (es obvio que tendrás que modificar ciertos aspectos específicos del juego para adaptarlo a código genérico).

Si repites estos pasos las veces suficientes, después de unos pocos juegos tendrás el comienzo de una colección sólida de funcionalidad reutilizable que ha sido PROBADA para tener aplicaciones prácticas en el desarrollo de un videojuego. Además, tendrás un conjunto como resultado de juegos interesantes que podrán demostrar la solidez de tu librería. Este método de crecimiento del motor (en vez de crear uno de golpe desde la nada) es infinitamente mejor ya que te ayuda a definir tus metas, te fuerza a pensar sobre los problemas que realmente tendrás a la hora de crear un videojuego y las implementaciones que necesitarás hacer. También te forzará a pensar sobre la necesaria separación entre lo específico del juego y la funcionalidad lógica del motor. Esto hará que aprendas de tus errores en vez de pretender que no los tendrás.

¿A qué esperas? ¡Deja de divagar y ponte hacer un videojuego! ¡TU videojuego!

Basado en: Write games, not engines

[Blog] Nuevo rediseño !

Bueno, ya tocaba, le he dado un lavado de cara, he creado una nueva cabecera (estoy por poner chibis a punta pala en la parte derecha… ya veré), he arreglado links de vídeos caídos y otros que no se veían, y varias cosicas más.

¿Qué tal? ¿Os gusta? A ellas les ha producido un shock del hype:

(ﾉ◕ヮ◕)ﾉ*:･ﾟ✧

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

Merry Christmas 2011