lunes, 31 de octubre de 2016

Escenario I. Primera fase y colliders.

En una entrada anterior en la que os explicábamos nuestras referencias, os mostrábamos un pequeño croquis de lo que queríamos que fuera el escenario completo de la aldea.

Lo siguiente que necesitábamos para empezar a trabajar era un mapa en 3D. Teníamos que empezar a situar cosas por un escenario para poder empezar a interactuar con los distintos elementos.

Aunque os explicaremos con un poco más de detalle las fases del movimiento de los distintos personajes, en esta primera fase del escenario los situamos para poderlos mover por el mapa y empezar a hacer uso de los colliders. No son más que una especie de cajas invisibles que ponemos en los objetos con los que nuestro ninja o nuestros peces deberían de chocar y no atravesar.

Hicimos uso de un par de tipos de colliders. Cuando queríamos que los personajes, por ejemplo el ninja, chocara completamente contra una construcción y no hubiera ningún tipo de interacción, usábamos un collider que ocupara todo el objeto. Por ejemplo para las casas, usábamos una caja. Así cuando el personaje intentara pasar, no podía.

En cambio, si necesitábamos que pudiera entrar en una edificación, usábamos el propio objeto como collider. De manera que todo lo que fuera malla 3D actuaba como pared invisible y el ninja podía pasar por la puerta y entrar dentro porqué era hueco, pero no podía atravesar las paredes porqué la malla actuaba como tope.

De la misma manera se configuró el puente, una zona por donde el personaje debía poder pasar por encima y no hundirse.

Para los peces, nos bastó con delimitar la zona del estanque y río con colliders y ya no pasaban de ahí.

Pues bien, para poder empezar a configurar este tipo de cosas e ir más allá y programar el comportamiento de los personajes (algo que explicaremos con más detalle en próximos artículos) necesitábamos un primer escenario.

Al igual que con todo el proyecto en general, empezábamos algo muy básico para ir detallando poco a poco sobre lo que teníamos hecho.

Empezamos con un plano y pusimos cajas directamente desde unity para marcar los sitios donde habrían edificaciones. Mientras se trabajaba con eso, se iban trabajando los modelos en 3D desde blender. Y así, y sin tener todos los modelos ni sus versiones finales, obtuvimos una primera versión más digna de enseñar del escenario.

Vista cenital del mapa en fase I.
Un modelo de casa duplicada varias veces, el granero, el campo de tiro, el puente y nuestro torii más una serie de objetos sueltos formaban parte de esta primera fase del escenario.

Si nos fijamos un poco, tenemos al personaje principal con los brazos en T (está aún sin animar) y los peces que no son más que pequeños ladrillos que se mueven por el estanque vacío.

Vista del mapa en fase I.
Aún así, suficiente para trabajar con los colliders y para empezar a programar el comportamiento de nuestro ninja y los peces.

Esto no hacía nada más que empezar.

jueves, 27 de octubre de 2016

Ninja I. Diseño, modelo, rig y animaciones.

Modelo

Como ya avanzamos, usamos un modelo 3D realizado en blender ya hecho. Eso nos aportaba muchas cosas. Algunas buenas, unas no tanto y otras que simplemente nos aportaban cosas, ni buenas ni malas.

Por una parte nos ahorraba horas de trabajo porque ya estaba hecho de principio a fin. Ese punto fue decisivo. No disponíamos de tiempo para dedicarnos a hacer un diseño, modelarlo en 3D, texturizarlo y hacerle su correspondiente rig y su pesado (explicamos este proceso un poco más abajo).

Hay que pensar que ese modelo había que animarlo, y eso ya es mucho trabajo. De hecho, tuvimos que recortar gran parte de trabajo de animación, pero eso lo explicamos más adelante en el post.

Además, nos proporcionaba un contexto (Japón tradicional) y un estilo (cartoon). Este punto ni es positivo ni negativo. O se acepta o no se acepta. Pero como ya comentamos, nos venía muy bien porqué la ambientación que venía implícita nos gustaba mucho. No había que pensar en demasiado en el tema.

Ahora vienen los puntos negativos, que son unos cuantos. Todos estos puntos son del modelo en si. Este personaje fue el primer personaje de principio a fin que hizo una parte del equipo. Al ser el primero, salió con sus cositas.

El modelo se hizo con la idea de hacer algún corto o pequeñas animaciones. Es decir, estaba enfocado a animación y no a videojuegos. Eso es un problemón, ya que hay diferencias muy grandes entre hacer el modelo para una cosa u otra. El número de polígonos, quizás, es de lo que más se tiene en cuenta.

Otra cosa bastante evidente es que el modelo está hecho con polígonos de 4 lados. En animación hay que evitar los triángulos (entre otras cosas), que es justo lo contrario de lo que pasa cuando modelas para videojuegos. Aunque cuando se importa en unity el propio programa los transforma a triángulos, se debería hacer en el momento de modelado.

Pero además de que no estaba hecho para videojuegos, tenía los errores típicos que hace uno cuando empieza, y es que la malla no está muy limpia. Eso se nota mucho en los hombros, por ejemplo. Este tipo de cosas hace que aparezcan problemas cuando se anima (también lo explicamos más adelante en el post).

A pesar de todo ello, decidimos aceptar sus limitaciones en pro de todo el trabajo que nos ahorraba.

Rig y animación

El rig es el sistema de huesos que se crea en el modelo para poderlo animar. Además de los huesos hay que realizar el pesado para decirle al hueso que vértices de la malla debe mover. Hablando mal, seria decirle a cada hueso que parte de "chicha" del personaje le corresponde.

El modelo tiene un rig muy sencillito. Apenas tiene 4 cositas en el rig facial (mover la cabeza, cejas, ojos, orejas y mandíbula). La mayor parte del trabajo está en el cuerpo. Aunque tampoco le sacamos mucho provecho, ya que el número de animaciones se redujo muchísimo.

Teníamos pensado tener diferentes animaciones según las acciones que podría hacer el modelo, pero al final se quedó en un idle* muy sencillo y muy sutil y en un ciclo de andar neutro.

En un inicio queríamos que pudiera andar, correr y lanzar estrellas en el campo de tiro. Además, queríamos un par de idle diferentes. Uno muy sutil para que no se vea el modelo parado y también queríamos añadir alguna más con el personaje mirando de lado a lado, o cambiando de pie. Nos flipamos bastante. No es que quisiéramos hacer animaciones de luchas complejas, pero ya nos costó bastante acabar con las básicas. Además, llegamos a un punto de desgaste que había que cuidar mucho para no dejarlo sin acabar.

Pero finalmente se quedó solo con el idle sencillo y con el ciclo de caminar normal solamente :(.

Las animaciones, así como el modelo, tienen muchos fallos. A parte de la dificultad que lleva realizar un ciclo de andar, salieron algunos fallitos por culpa de la malla y su pesado. Cuando se realizan las animaciones o posados de un modelo en 3D es cuando aparecen los fallos de una mala disposición de los polígonos. Por muy bien que hagas el pesado, siempre toca arreglar este tipo de cosas.

Con blender se pueden resolver estas cosas arreglando la parte "rota" con el sculpt (es una funcionalidad con la que esculpir directamente sobre el modelo como si fuera de barro)Por ejemplo, en los hombros cuando se mueven los brazos a veces se ve un parpadeo en la malla. Para intentar arreglarlo hubiéramos tenido que esculpir para resolver ese fallo y animarlo de manera que aparezca el arreglo cuando la malla se rompe.

Pero como la textura del modelo era de azul oscuro y apenas se notaba en unity, decidimos que mejor sería invertir el tiempo en otras cosas más urgentes.

La animación del ciclo de andar se hizo sobre el sitio. Es decir, en blender no movemos al ninja en uno de los ejes para avanzar, sino que lo animamos todo en el mismo sitio para que luego desde unity se pueda configurar el movimiento más fácilmente. Esto lo explicaremos con más detalle en un próximo artículo.

A continuación os mostramos un pequeño video donde se puede ver el rig del ninja y como está animado:




Resultado final

Para poder usar las animaciones en unity, había que exportar el modelo a formato FBX. Desde el programa se importaba y detectaba las animaciones perfectamente.

Como ya hemos avanzado, más adelante os explicaremos más cosas sobre el personaje una vez ya en unity. Las fases de movimiento, las distintas animaciones y como se resolvieron algunas cosas con código. Ahora os dejamos con el resultado final del personaje en blender.



Esperamos que os haya resultado útil :).


*idle es un ciclo de reposo que se activa cuando el modelo en 3D no se mueve para que no parezca inanimado, por ejemplo, la respiración del personaje

lunes, 24 de octubre de 2016

Referencias II. Escoger un estilo.

Hasta ahora hemos hablado de referencias en general, sobretodo para escoger una ambientación y que todo tenga el mismo aire.

A continuación os mostraremos unos cuantas referencias más concretas de algunos de los objetos que queríamos poner en la demo...


Torii y puente
Torii y puente
Cerezo en flor
Cerezo en flor
Dianas de tiro, banco periodo Edo, puente y carro.
Dianas de tiro, banco periodo Edo, puente y carro.

También encontramos referencias interesantes de ilustradores profesionales, como la que encontramos para el muro que delimita toda la aldea. En este caso es una ilustración de la ilustradora M. H. Chen.
Ilustración de distintos tipos de muros de M. H. Chen.
Ilustración de distintos tipos de muros de M. H. Chen.

Croquis del mapa de la aldea
Nos hubiera encantado tener las suficientes dotes artísticas como para ponernos a diseñar en 2D los objetos y así poder concretar un estilo sin tener que hacerlo directamente en 3D. Ganas tiempo y aporta mucha riqueza al resultado final.

Las ideas siempre funcionan muy bien en la cabeza, nunca fallan. Hay que ponerlas sobre papel para comprobar que la idea se tiene muy clara y poder resolver más rápidamente las dudas que surjan.

Una vez que teníamos la lista de los objetos que más o menos queríamos que aparecieran, nos hicimos un croquis del mapa de la aldea (a la izquierda del texto).

Estilo

A la vez que uno busca referencias para decidir la ambientación, los personajes e incluso la historia o motivo de la demo, pensamos en un estilo concreto.

En nuestro caso, una vez más, al querer usar el ninja ya creado, el estilo cartoon también venía implícito. Se podría haber intentado hacer algo más trabajado e intentar combinar el personaje con una ambientación menos caricaturesca. Pero una vez más, esa falta de tiempo y recursos nos obligó a seguir con el mismo estilo que el que tenía nuestro personaje principal.

Hay que dejar claro que nunca nos molestó que usar un diseño del personaje principal ya hecho nos hizo aceptar una serie de cosas de forma obligada. La temática de Japón y el estilo cartoon que nos daba el ninja nos parecían fenomenales :). Aportaban mucha riqueza y es un tema universal que siempre gusta.

En el próximo post nos pondremos con las manos en la masa y os mostraremos detallitos de nuestro protagonista.

jueves, 20 de octubre de 2016

Referencias I. Periodo Edo.

Ponerse a realizar cualquier trabajo, sobretodo si es creativo, sin una referencia con la que basarse es muy complicado. Y aunque fuera posible obtener un buen resultado, desde nuestro punto de vista, se habría desaprovechado que el resultado final fuera mejor.

Necesitamos algo con lo que empezar, y más cuando no sabes exactamente que es lo que quieres.

Así que la manera más fácil e inmediata era buscar referencias reales del Japón tradicional, intentando acotar la búsqueda a objetos del periodo Edo. Aunque nuestra intención era intentar ser fiel a esa época, no podemos garantizar que todo lo que encontramos perteneciera a ese período.

Por tanto, tal y como dijimos en el post anterior, nos conformábamos con que todo tuviera una coherencia sin saber si estábamos siendo fieles al rigor histórico...

Encontramos mucha información, entre ella, una web donde aparecen fotografías en 360 grados de lo que parece un set que imita el estilo de las construcciones del periodo Edo.


Casas con el estilo de construcción de periodo Edo.
Vista de las casas y puente con el estilo de construcción del periodo Edo.
También encontramos la web de lo que parece un museo ambientado en un pueblo (¿ficticio?). Incluso hay un mapa en PDF y en cada ítem que aparece en el mapa, se puede ver una descripción de la construcción. Algunas tienen la especificación qué pertenecen al periodo Edo, cómo esta.


Aldea

Con la información que encontramos, ya éramos capaces de tener una idea de como tendrían que ser esos elementos, algunos de los cuales, teníamos incluso referencias claras.

Des de un principio queríamos añadir distintos tipos de casas de los habitantes de la aldea, un pozo, un puente que pasara por encima de un río pequeño, una zona de tiro, el típico atrezzo de una escena (árboles, barriles, cajas, vallas, distinto tipo de vegetación, etc.) y el famoso Torii.

Pero ¿que pasaría si quisiéramos poner un objeto y no tuviéramos referencias claras? Habría que inventar. Para eso es necesario investigar qué materiales se usaban por aquel entonces.

En aquella época parece que el material más común para las construcciones civiles era mayoritariamente la madera.

Así pues, cuando no se tenga referencia con la que trabajar usaremos madera o materiales que se usaban por aquel entonces para resolver la duda.

Después nos pusimos a pensar en una lista de objetos para modelar que estaría bien que apareciesen en la aldea de descanso.
  • Torii. La puerta de entrada al pueblo.
  • Puente. Para poder pasar por encima del río que separa la entrada de la aldea con la propia aldea.
  • Río. Pequeño río que atravesará el pueblo, acabando en un pequeño estanque.
  • Letreros. Señales que indiquen los caminos donde llevan a distintas zonas (campo de tiro, estanque y aldea).
  • Estanque. Donde habrán distintos tipos de vegetación, piedras y los famosos Kois. Carpas grandes típicas de China y Japón.
  • Campo de tiro. Zona de entrenamiento donde habrán dianas para poder practicar tiro en cuanto se añadan las animaciones para ello. Mientras tanto, será otro tipo de construcción.
  • Casas u otras construcciones. Casas de aldeanos, o construcciones típicas como un granero, establo o granja.
  • Pozo. Pequeño pozo que estará entre las casas.
  • Árboles. Cerezos que estarán por todo el escenario por temas estéticos y para separar zonas. Y si se puede otro tipos de árboles.
  • Atrezzo. Distintos objetos para dar variedad al escenario. Carros, barriles, cajas, etc.


Torii

Después de tanta referencia y ver distintas imágenes, nos encantó darle un protagonismo especial a un elemento muy conocido de Japón. El Torii. Además tiene un significado muy especial que nos venía muy bien para nuestra pequeña demo.

El Torii es una construcción que suele estar en las entradas de los templos o santuarios para dar la bienvenida al visitante.
Torii.
Y así decidimos que en la demo se empezaría justo delante de un Torii, que aunque no haríamos ningún templo o santuario, si serviría para dar la bienvenida a nuestro ninja a la aldea de descanso. Y no solo eso, también le daría el nombre a nuestro juego.

Para acabar, volver a hacer hincapié en la búsqueda de referencias. Es tan importante que además, en nuestro caso, nos dio el nombre al proyecto :).

lunes, 17 de octubre de 2016

Cómo. Qué. Quién. Dónde. Cuándo. Por qué.

Una vez analizadas las herramientas que queríamos usar y después de realizar tutoriales e ir probando el entorno de Unity (nuestro Cómo), nos lanzamos a realizar un brainstorming para sacar ideas de que podríamos hacer nuestra primera incursión en el mundillo dominguero de los videojuegos.

Sabíamos que queríamos algo en 3D. Ya tenemos el Qué. Por tanto, poco o mucho, necesitaríamos un montón de material en tres dimensiones y, a no ser que hiciéramos un juego de carreras (espaciales o no) necesitaríamos a un protagonista… ¡animado!

Aún no habíamos empezado y la perspectiva ya se tornaba complicada...

Personaje. En Blender
Pero se dio el caso que nuestra parte tresdesera del equipo había diseñado, modelado y riggeado* un personaje en 3D completamente con Blender. Y por si fuera poco, era un ¡ninja!… ¿hay algo que mole mas que un ninja? Así que ya teníamos protagonista bytheface, nuestro ansiado Quién.

Nos embarcamos en crear algo ambientado en Japón que nos permitiera usar a nuestro nuevo amigo y nos ahorrara faena para poder desarrollar la idea sin que una montaña de trabajo casi infinita se nos viniera encima.

Que el personaje sea un ninja ya pone muchas cosas en contexto, y la cultura japonesa está implícita y nos resuelve el Cuándo y el Dónde.

Para la ambientación miramos qué épocas podían estar chulas para buscar referencias y que existieran los ninjas. Investigando en Google sobre ellos, dimos con un artículo interesante que hablaba sobre las épocas donde los ninjas tuvieron un protagonismo importante. Después de ver distintas épocas y períodos, nos decidimos por el que más nos gustó: el periodo Edo.

Periodo Edo. Artista: Kano Einō (Japanese, 1631–1697).
Nos gustó porqué su arquitectura era lo más parecido a lo que teníamos en mente. Torii, estanques decorativos, tejados en U, etc., son algunas de las características que más conocemos de Japón y que se empezaron a usar en esta época.

Eso es muy importante porqué si hay que modelar escenarios y props* hay que saber en qué momento de la historia estará ambientado. No es lo mismo modelar un coche en los años 80 que en la época actual.

Nos confesaremos antes de empezar. Esto no será un ejemplo de rigor histórico. Simplemente necesitábamos una referencia en la que basarnos para modelar las distintas cosas y que no parecieran de épocas totalmente diferentes.

Pensar que solo buscar trabajo de documentación para la ambientación y crear los diseños conceptuales para definir el estilo ya es una profesión en si misma, así que no nos podíamos permitir el lujo de invertir demasiado tiempo en estas tareas porqué corríamos el riesgo de quedar estancados. Al fin y al cabo, con crear algo con cierta coherencia nos bastaba. Simplemente era tener algo en lo que basarnos para no partir de cero.

Aunque, para ser sinceros, después estuvimos viendo objetos de otras épocas y mucha diferencia no veíamos. Suponemos que escoger Japón como tema central tiene estos inconvenientes, siendo una cultura tan tradicional.

Por tanto, antes de empezar, pediremos disculpas por nuestros errores garrafales históricos que puedan existir, y si herimos la sensibilidad de algún ojo experto.

Bien bien, nos queda solo el Porqué. Ahí va la segunda confesión. Nos flipamos. Aunque creemos que no se nos fue de las manos. Y eso es importante.

Pensamos en un juego más o menos viable. Si. Un juegazo entero con sus niveles y sus bosses. Pero no lo pensamos con detalles, sino con una idea que podría funcionar. A partir de ahí, nos dijimos que la parte que desarrollaríamos seria la típica escena del juego donde el personaje principal se detiene para entrenarse y subir niveles, descansar, curarse, comprar armas y pociones de salud, etc. Esta seria nuestra pequeña aldea de descanso.

Es decir, pensamos en un juego que podría estar guai, pero acotamos mucho lo que podríamos y no podríamos hacer. Creemos que esa es la clave para no rendirse ni aburrirse de la idea. Haz algo que creas que puede funcionar pero sabiendo donde están tus límites.

Eso no quita que no te acabes flipando y pensando en muchas más cosas para hacer de las que realmente se puede. A nosotros nos pasó y nos seguirá pasando. Siempre te flipas, hay que aceptarlo, es un hecho. Es más, si un día no pasa, es para preocuparse. Si cuando uno piensa en hacer algo que le gusta mucho no se viene arriba es que no tiene la suficiente ilusión.

Siempre piensas en todas las cosas que te gustaría que estuvieran hechas. Esas ideas salen principalmente de nuestro bagaje como jugadores, con lo cuál es normal pensar en cosas que nos pueden venir más o menos grandes. Al fin y al cabo, no nos podemos comparar con empresas que sacan productos para hacer negocio y poniendo una inversión y recursos importantes.

¡Por fin! ya teníamos todas las incógnitas resueltas. Ahora era cuestión de empezar a planear el escenario para saber que elementos nuevos había que crear para poder buscar referencias, modelarlos y texturizarlos.

A esa lista de props había que sumarle qué acciones podría hacer el personaje principal para empezar a planificar las animaciones.

¡Bufff! Cuánto trabajo se nos vino encima. En los siguientes posts veremos los primeros modelos que hicimos.

*crear el rig de un personaje es crear el sistema de huesos para poder animar un personaje u objeto.
*los props son los objetos y atrezzo que crearemos para el juego

viernes, 14 de octubre de 2016

Escoger las herramientas. Software y recursos gratis.

Hay mucho trabajo antes de ponerse a programar, diseñar o modelar. Incluso antes de ponerse a decidir un tema concreto para nuestro primer juego.

Lo primero en que pensar y es de vital importancia, son en las herramientas que vamos a utilizar.

Dada la naturaleza de nuestro proyecto, donde sólo podemos dedicarle parte de nuestro tiempo libre, no podemos pensar en algo que no sea de uso gratuito. Eso no significa que no se pueda hacer una inversión puntual por algo que necesitemos y no encontremos una solución mejor.

Así, después de varias investigaciones y según nuestras necesidades, las herramientas con las que contaríamos son...

Unity. Como motor gráfico.

Unity. Como motor gráfico.
Necesitábamos algo gratuito y a la vez práctico para poder desarrollar el proyecto. Empezamos con tutoriales básicos para conocer la interfaz y una vez que vimos que cumplía nuestras necesidades básicas de usabilidad y sabiendo que no haríamos nada tan complicado como para necesitar chequear otras opciones más complejas, nos decidimos por Unity.

En ese momento existía una versión gratuita donde aparentemente estaban bloqueadas algunas opciones avanzadas de iluminación y alguna cosa más a la que no le dimos mucha importancia. Aunque es algo que a priori nos diera desconfianza, tuvimos en cuenta que, en caso de necesitarlo, la opción de pago no era algo desorbitado.

Lo importante era saber que lo que nos ofrecía de forma gratuita fuera suficiente para nuestra primera incursión en el mundillo, y así fue.

Antes de que lo comentéis, en ese momento Unreal no era gratuito.

¿Pero que hubiera pasado si en ese momento hubiera existido esa posibilidad? En ese caso, ¿qué hubiéramos hecho? Pues no lo sabemos seguro. Lo llegamos a probar un poco para ver las opciones una vez empezado con Unity, y nos pareció un motor muy potente. ¿Qué podemos decir de Unreal? todo bueno.

Pensándolo un poco... seguramente hubiéramos optado por la misma solución. El motivo es muy sencillo, aunque no tiene porqué ser el correcto. Se puso de moda dado que era el único software en ese momento gratuito, usable y potente para hacer cosas interesantes.

Que en su momento fuera la única opción usable gratuita hizo que se generase mucha documentación (blogs, vídeos en Youtube, foros, assets, etc). Y eso compañeros, es muy, pero que MUY importante si empiezas en una disciplina nueva donde Internet es fundamental para poder resolver dudas.

Página web: https://unity3d.com/es.

Mono Develop. Como editor de código.

Mono Develop.
Como editor de código.
Esta elección fue bastante fácil. Este programa va integrado con Unity y como vimos que nos ofrecía lo necesario para poder codificar, no tuvimos que pensárnoslo mucho.

Aunque evidentemente, siempre se puede usar cualquier otro para codificar. Se trata de encontrarse cómodo con la herramienta que nos vaya mejor.

Página web: http://www.monodevelop.com/.

Blender. Como software 3D.

Blender. Como software 3D.
Otra elección fácil. Si íbamos a hacer algo en 3D y queríamos un software gratis, la respuesta era clara: Blender.

Existen muchas posibilidades conocidas en el mundo del 3D. Maya, 3DStudio MAX, Cinema 4D, etc.

Pero Blender, a parte de gratis, es un programa totalmente válido para cualquier disciplina dentro del 3D. Se puede modelar, texturizar, esculpir, riggear, animar, etc. ¡Una maravilla!

Hay que decir que si no se tiene mucha idea de 3D, siempre se puede optar por recursos ya hechos. En la misma Asset store de Unity se pueden encontrar objetos e incluso personajes en 3D animados. Aunque, está claro, si uno lo hace por sus propios medios, siempre aportará un toque de originalidad al proyecto.

Visto lo dicho, aunque tuviéramos presupuesto para invertir en herramientas, probablemente la solución 3D hubiera sido la misma.

Somos fans de Blender :).

Página web: https://www.blender.org.

Páginas de consulta y recursos.

Aunque no sea software propiamente dicho, es igual de importante conocer páginas de recursos gratuitos donde echar mano cuando sea necesario.

Esta no es una elección, más bien es una recopilación de recursos que se obtienen una vez metido en el lío. Es una lista que no se debe dejar nunca por cerrada. Incluso cuando empiezas con tu siguiente proyecto, donde tu lista será más vital que nunca y la seguirás ampliando día tras día.

Si os tuviéramos que decir una página web importante, esa sería la ya mencionada página de la Asset Store de Unity. Esa debe ir a favoritos a la de ¡ya!. Puedes encontrar casi cualquier cosa de todos los precios. De 0 a lo que sea.

Incluso es una página a tener en cuenta si después queréis ganar algo de dinero vendiendo vuestros propios assets.

A partir de aquí, una lista de páginas que ofrezcan recursos tales como texturas gratuitas o todos los blogs y/o foros que se puedan ir recopilando a raíz de búsquedas en Internet por alguna necesidad concreta.

Conclusión, como veis, la elección de las herramientas no puede ser tomada a la ligera. Tener que cambiar de software en mitad del proceso puede hacer tambalear el proyecto. Sobretodo cuando se hace por amor al arte.

lunes, 10 de octubre de 2016

Un juego a ratos. Presentación.

Hola a todos y ¡bienvenidos!

Primero, nos presentaremos. Somos un equipo de dos personas que nos encanta el mundo del videojuego. Ya desde pequeños nos gustaba jugar a las maquinitas y es una afición que no se ha acabado al llegar a la edad adulta.

Con la llegada de los juegos indies y gracias a nuestras profesiones nos animamos a ir un paso más allá y ponernos a investigar como se hace un videojuego. Eso si, sin ningún tipo de pretensión. Solo por pura diversión y por ganas de aprender a hacer algo nuevo que, además, pertenece al mundo que tanto disfrutamos.

Somos ingenieros informáticos. A uno de nosotros le encanta programar. Todo lo que tenga que ver con pensar y realizar las funcionalidades que se nos pasan por la cabeza es su trabajo y motivación.

La otra parte sin embargo, le produce más curiosidad el diseño en 3D. Modelar, texturizar, riggear (crear el sistema de huesos para animar el modelo) y animar es su trabajo principal.

Aunque eso no quita que nos podamos substituir el rol en algún momento para descansar de nuestras responsabilidades.

Pero… ¿porqué hacer este blog?...

Necesitábamos algo funcional para dejar documentado de una manera u otra todos los procesos que fuéramos haciendo. Era una manera de poder acceder al contenido rápidamente cuando nos surgiera una nueva duda. Además, siempre queda bonito poder ver el progreso de un proyecto y nuestras mejoras. Así que si nos íbamos a poner a ello, ¿porqué no publicarlo?

Pero existía otra razón igual de importante. Cualquiera que se ponga a hacer un proyecto del cual no conoce el pipeline, lo que hace a la primera duda es mirar en Internet. Pues bien, como muchas cosas que hemos ido haciendo las hemos ido resolviendo gracias a contenido publicado por otras personas, nos vemos con la obligación de hacer lo mismo. Dar para recibir. Así, si alguien se encuentra con un problema que nosotros ya hemos resuelto de alguna manera, podrá encontrar en este blog la inspiración y, con un poco de suerte, la respuesta a su duda.

¿Y porqué este nombre?. Bien, como esto solo es por hobbie, tenemos que dedicarnos a ello en nuestros ratos libres. De ahí, el nombre del blog: “Un juego a ratos”.

Si, ya sabemos que estais pensando. ¿Un juego a ratos? O se hará eterno el proceso o el juego dejará mucho que desear. ¡Efectivamente! Si citamos el famoso refrán de “nadie da duros a cuatro pesetas” ¿que es lo primero que se os pasa por la cabeza? Ejem… si si, tenemos cierta edad si hablamos de pesetas, pero… ¿qué más? ¡Eso es! que si hacemos esto en nuestros ratos libres no se hará en dos días y el resultado no será de triple A.

La gracia del blog es ir compartiendo el proceso. En nuestro caso será un proceso lento, pero eso también tiene su encanto. Si algún día somos unos cuantos en este blog, podremos recibir feedback entre artículo y artículo que nos permitirá ir probando a medida que vayamos realizando todo el proceso.

Nos encantaría que estuvierais ahí para ser partícipes de todo esto. Nosotros prometemos contaros todos los detalles :).

Solo nos queda por decir que… ¡este blog ya está en marcha!

Fdo. Un juego a ratos