Saludos lupinos amiguetes.

Hoy he decidido traeros la traducción de una entrada de un blog que me ha parecido la mar de interesante. La entrada original en "The amazing spectacular world of Blanof" la podéis encontrar aquí y hace referencia al desarrollo de un juego de Rol, comenta algunas verdades, nos ofrece algunas percepciones algo mas subjetivas y en general, nos ofrece lo que a mi parecer es una experiencia interesante.

De nuevo, he recurrido a la interpretación libre para darle soltura al texto. Espero que no os importe. *

Los problemas de los RPGs

Adquirí Game Maker en Mayo del 2005. Poco tiempo después, uno de los primeros juegos que comencé a desarrollar fue un juego de rol, mejor conocido como RPG. De hecho, aún se puede encontrar el hilo original, aunque los enlaces de descarga han sido borrados hace tiempo. Invertí más de un año trabajando en él y el juego nunca llego a completarse.

Comparemos esa historia con esta: Comencé a trabajar en Dubloon en Mayo del 2009. En menos de un mes ya he realizado un mayor progreso con este juego que en todo el desarrollo anterior de mi primer RPG. También se ve mejor, se juega mejor, funciona mejor y es mas fácil trabajar en él.

Básicamente lo que quiero decir es que hacer un RPG es complejo y no es un desarrollo adecuado para inexpertos. No estoy diciendo que sea algo imposible, pero en términos de desarrollo, los RPGs presentan muchos mas obstáculos que cualquier otro género de videojuegos que se te pueda ocurrir. Así, como parte de una historia preventiva, o a modo de "Diario de desarrollador", voy a hablaros de lo que he aprendido haciendo RPGs y algunos de las dificultades en su diseño.

Una de las primera cosas de las que siempre habla la gente a tratar este tema, es la cantidad de experiencia técnica que se precisa. Cuando hablas sobre el funcionamiento interno de un RPG, estás viendo un montón de datos que deben ser organizados, computados y machacados constantemente. Debes manejar inventarios, estadísticas de personajes, cálculos de batalla, y así sucesivamente. Puede ser duro llevar un seguimiento de todo esto, sobre todo cuando tu equipo de desarrollo consiste en una sola persona, necesitas tener soltura con términos como los arrays, estructuras de memoria, y todas esas cosas divertidas. Quizás no debería decirlo, pero yo programe mi primer RPG sin tener esos conocimientos y es horrible, duro.

Proyectos como un RPG, no son desarrollos que se deban hacer rápidamente. El código que escribes debe ser funcional, comentado y lo suficientemente organizado como para que puedas volver a verlo un año después y entender perfectamente que es lo que hace. Cuando los nuevos desarrolladores comienzan diciendo que quieren hacer el RPG de sus sueños, al igual que hice yo, suele ser la razón por la que les digo que no podrán hacerlo.

Los RPGs no son solo complejos de desarrollar técnicamente, también lo son a nivel artístico. A diferencia de juegos de otros géneros, la expectación que se tiene sobre un buen RPG es una larga duración. La mayoría de los juegos independientes pueden terminarse fácilmente en una hora, o incluso menos. Para conseguir esa gran diferencia en horas de juego, necesitas añadir diferentes mecánicas e ideas para mantener la variedad y el interés. El problema que encuentro en muchos RPGs es que a menudo caen en repetir patrones aburridos: explorar mazmorras, machacar, luchar con los jefes, desplazarnos hacia la siguiente mazmorra. En la actualidad los juegos se mueven muy rápidamente y los diseñadores tienen una gran responsabilidad combatiendo por mantener el interés del jugador. ¡No dejes que tu juego se estropee! “RPG” no tiene porque ser sinónimo de “aburrido”, y si dedicas el tiempo suficiente en pensar en el sentimiento y el ritmo de tu juego, es totalmente posible unirlos en un juego de rol que resulte divertido y atractivo.

Parece evidente que los juegos de rol no son tan bien recibidos hoy en día como lo eran antes. Lo descubrí dolorosamente cuando subí “Dubloon” a IndieGames en Julio de 2009. La gente envió comentarios tipo "sólo otro juego de rol" sin tan siquiera haberlo jugado. Los juegos de rol no son tan apreciados tanto en estos días, esta tendencia se puede observar en las listas de “mejores características” del año en Indiegames. La mayoría de los géneros quedan bien delimitados y con 15-20 juegos incluidos en su lista, mientras que los RPGs están agrupados junto con otros dos géneros similares y apenas consiguen un total de 10 títulos innovadores.

En el mercado actual, se hacen un montón de promesas para convencer al público de que su RPG es especial. Tal vez estoy reaccionando con demasiada fuerza a un grupo minoritario de “enemigos” del género, pero nunca es mala idea tenerlos en cuenta para tratar de innovar. Hay que ser consciente de la imagen de tu juego: ¿cómo lo ven los jugadores? Hay una razón por qué existen listas como éstas y es importante que familiarizarse con los clichés del género... para poder romperlos.

¿Están muertos los juegos de rol? Yo no lo creo, en absoluto. Ofrecen una experiencia muy particular al jugador, haciéndole sentir el crecimiento del personaje y la aventura de una forma que ningún otro género puede ofrecer. Lo que es importante al hacer un buen RPG es saber que es bueno, que no lo es tanto, y hacer uso de esas cualidades en tu favor. Cuando comencé con mi primer RPG, empecé sólo porque quería hacer un juego de rol, y no creo que esa sea la forma correcta de abordar este tipo de proyectos. Un juego de rol, no es interesante sólo por el hecho de serlo. Cuando empecé a Dubloon, era porque quería hacer un juego de piratas, y decidimos que el mejor género para ofrecer ese tipo de experiencia era un juego de rol. Deja que el género sea tu herramienta... no te conviertas en una herramienta del genero.

---

*: y si os importa... os podéis poner a hacer encajes de bolillos. XD

Hoy, mientras navegaba un poco me he encontrado con este interesante "Postmortem" de un proyecto de la joven empresa Ninja Fever. Me ha resultado especialmente interesante porque, entre otras cosas, refuerza algunas de las creencias que ya tenia con respecto a la importancia del binomio "Marketing-Diseño".

Eso es todo. Os dejo con el articulo. Espero que os resulte tan interesante como a mi.

Ninja Fever es una empresa creada a mediados de 2009 en Castellón, orientada al desarrollo de títulos para descarga on-line de las principales plataformas de consola.

Como primer título, se eligió Dual Zone, un remake de un antiguo proyecto como grupo amateur, mejorado y adaptado para la consola Xbox Live, en la sección Indie Games.

Qué fue bien

1. 
   La calidad. Planteamos el juego para que tuviera una calidad visual superior a la existente en el bazar de juegos independientes, y una jugabilidad original. Gracias al buen hacer de nuestra grafista freelance, conseguimos sobradamente el primer apartado y, según la crítica, también el segundo. Como veremos más adelante, esto no implica necesariamente que el juego fuera un éxito de ventas. Como detalle anecdótico, la música ha sido muy bien valorada en general, pese a ser el aspecto en el que menos esfuerzos se invirtió.
   
2. 
   Las reviews. Tanto de medios especializados como las críticas de particulares, han sido muy positivas en su gran mayoría. Incluso en medios muy exigentes, la nota más baja ha sido de 7 sobre 10, y muchos de ellos valoran positivamente tanto la curva de aprendizaje como haber tenido en cuenta posibles problemas de daltonismo en jugadores. Estas reviews han supuesto una estupenda forma de dar visibilidad a la empresa por su lanzamiento a los medios de comunicación. De nuevo, veremos que esto no supone necesariamente verse reflejado en las cifras de ventas.
   
3. 
   El poner los sistemas a punto. El proyecto se empezó cuando aún no teníamos siquiera montado el estudio de desarrollo, de forma que uno de sus principales objetivos era el de ayudarnos a establecer una metodología de desarrollo (o su base) desde la que partir para los demás proyectos. En definitiva, Dual Zone ha sido un banco de pruebas perfecto para testear el buen funcionamiento de herramientas como Mantis o Subversion, las copias de seguridad, el blog interno de desarrollo o el propio Framework para desarrollar en XNA. En este sentido, al terminar el proyecto, todos los sistemas están casi completamente funcionales, y la metodología general de producción ha mejorado considerablemente.
   
4. 
   La obtención de información sobre el panorama del mercado. Contrastar nuestras expectativas de mercado con la realidad nos ha aportado multitud de datos interesantes, como por ejemplo el funcionamiento del ciclo de validación de los juegos para XBLIG por parte de otros desarrolladores y su idiosincrasia interna, los peculiares títulos más vendidos, que la calidad no es un factor determinante, y en general el caos interno de esta sección de esta plataforma en concreto.
   
5. 
   La experiencia de un primer trabajo con freelance. A pesar de todo lo que podemos mejorar en este aspecto (y que detallaremos más adelante), la experiencia de trabajar a distancia con una infografista ha sido muy enriquecedora. Ha ayudado haber trabajado previamente con ella in situ en el desarrollo de un proyecto anterior en otra compañía.
   

Qué fue mal

1. 
   Las ventas. Hemos calculado la necesidad de unas 10.000 compras para llegar al punto de equilibrio. Tras un mes en el mercado, hemos vendido 21 copias. Los ratios de descarga/compra de 1'15% (aproximadamente 1.700 descargas con las mencionadas copias) nos han puesto de manifiesto que Dual Zone no es un juego apto para el público general, quizá demasiado difícil para algunos usuarios o repetitivo. Las bajas ventas han extrañado incluso a otros desarrolladores de XBLIG, que nos han apuntado como posibles factores que el trailer, la demo y la descripción del juego no representaran con la suficiente fidelidad su contenido. Extrapolando con las estadísticas de precios de las aplicaciones más vendidas para iPhone, quizá la elección del precio (el rango medio de 240 MSP, frente a los 80 MSP o los 400 MSP) haya sido contraproducente.
   
2. 
   La carencia total de un documento de diseño. El haber partido de la idea de un proyecto anterior y en medio de la vorágine de la constitución de la empresa supuso el no darle la importancia debida a la definición extensa y por escrito de los componentes del juego y sus interacciones. El no tener plasmado en ninguna parte la visión del juego (dos jugadores opuestos pero complementarios) ocasionó una deficiencia en la comunicación con la grafista y la pérdida de rumbo del propio programador, en forma del propuestas de adición de contenido incoherente con el universo del juego, la petición de gráficos sin una definición suficiente y, lo que es peor, el alargamiento innecesario del tiempo de desarrollo.
   
3. 
   La explotación ineficaz de los recursos gráficos. Pese a contar con un alto nivel de calidad gráfico, se les podría haber sacado mucho más partido invirtiendo algo más de tiempo en la creación de alguna cinemática introductoria a las partidas en las que se permitiera ver mejor las naves (que, a pesar de tener bastante detalle, apenas se aprecian sus formas), o en asuntos como el sistema de partículas, las explosiones de los enemigos o los propios modelos enemigos (al ver su versión grande, se nota su baja poligonalización).
   
4. 
   Las herramientas de trabajo. Dado que hemos ido construyendo el pipeline sobre la marcha, hemos tenido problemas paralelizando el framework de programación a la vez que el propio juego, además de bugs en herramientas de exportación de modelado y shaders de terceros. En conjunto, estos problemas ralentizaron el proyecto considerablemente. Como problema adicional, el no disponer aún de servidor FTP propio ha supuesto un handicap de comunicación con la grafista (a añadir a los problemas de comunicación anteriores). Anecdóticamente, nos costó horrores encontrar una tarjeta de memoria oficial para la Xbox con la que hacer ciertas pruebas.
   
5. 
   El proceso de revisión. Fue lento, caótico y desesperante. Tener estancado el juego para su review durante tiempos inciertos, o incluso recibir puntuaciones negativas en el bazar aún sin haber comprado el juego nos dio bastante mala impresión sobre el sistema de XBLIG.
   

Qué hemos aprendido

En cuanto al marketing, que es necesario invertir más tiempo estudiando el mercado existente para crear proyectos que se adapten mejor a los gustos patentes a un precio adecuado. La falta de un documento de diseño detallado y consensuado entre programador y grafista desde su concepción es inadmisible para futuros proyectos. El focus testing hubiera ayudado a la hora de encontrar debilidades en el gameplay, el trailer y la descripción, debilidades que sólo pudimos encontrar en estadios demasiado avanzados del juego.
Finalmente, aunque en conjunto el proyecto ha cumplido los cometidos para los que fue pensado, nos deja un mal sabor de boca el ver que en la plataforma triunfa otro tipo de juegos.

Desarrollador: Ninja Fever
Publisher: Ninja Fever
Fecha de salida: 7 de diciembre de 2009
Plataforma: Xbox Live Indie Games
Número de desarrolladores a tiempo completo: 1
Número de contratados: 1
Tiempo de desarrollo: 3 meses
Software de desarrollo: Visual C# Express, 3DStudio Max, Photoshop, Acid Xpress
Tecnología: Framework XNA Ninja, kW X-port

Saludos lupinos manada.

Por el momento no os puedo contar nada, pero por el momento parece que se me están abriendo nuevas puertas y cerrando las de épocas pretéritas, tanto a nivel laboral, como vocacional e incluso espiritual*. Supongo que a lo largo del año os podré ir informando un poco conforme vayan cristalizando las cosas.

Con respecto a Cell Fusion, por el momento sigo sin poder volver a una dinámica estable, motivo por el que estoy prefiriendo no ponerme fechas en estos momentos. Simplemente, me limito a coger un elemento de la lista y me pongo a trabajar hasta completarlo. Eso si, procuro aprovechar cada momento libre que se me presenta y la verdad es que estoy quedando satisfecho con los resultados. Tras la culminación de la tarea de los sprites, la pila de trabajo va tomando el siguiente aspecto:

Objetivos restantes ("Product Backlog"):

- Intro 1
- Intro 2

- Textos intermedios

- Tutorial
- Final

- Nivel 6
- Ajustes Items

- Completar sprites Sondas
- Añadir nuevas armas [En reconsideración]

Sprint 1: Terminar Intro 1 y hacer los ajustes de los Items.

Semana 1:

- Insertar introducción al inicio.
- Mostrar los textos centrados junto a la imagen.
- Añadir efectos de transición entre imagenes.
- Añadir sonidos y música.

Semana 2:

- Crear los sprites de los nuevos ítems.
- Crear su funcionalidad.
- Redistribuirlos.

Sprint 2: Hacer Intro 2

Semana 1:

- Crear texto.
- Insertar introducción al inicio del nivel.

Semana 2:

- Crear imágenes.
- Añadir sonidos y música.

Sprint 3: Textos intermedios y Final

Semana 1:

- Crear textos (Creados, pero no traducidos)
- Crear imágenes (No me convence como quedan)

Semana 2:

- Insertar los textos al inicio de cada nivel
- Insertar final
- Añadir sonidos y música. (Los sonidos aún no me convencen)

Sprint 4: Tutorial

- Crear textos tutorial
- Crear imágenes tutorial
- Ubicar tutorial

Sprint 5: Nivel 6 completo.

Semana 1:

- Crear imagen jefe final.
- Crear patrones jefe final.

Semana 2:

- Crear flujo nivel.

Sprint 6: Imágenes para las sondas y nuevas armas

Semana 1:

- Crear 18/18 imágenes para las nuevas sondas

Semana 2:[En reconsideración]

- Crear ítems para las nuevas armas
- Implementar las nuevas armas

Eso es todo por hoy con respecto a Cell Fusion.

¡Nos leemos!

---

* Si alguno quiere venir en pos de mí, niéguese a sí mismo, tome su cruz cada día, y sígame. Porque quien quiera salvar su vida, la perderá; pero quien pierda su vida por mí, ése la salvará. Pues, ¿de qué le sirve al hombre haber ganado el mundo entero, si él mismo se pierde o se arruina?

---

¡Saludos lupinos!.

Como ya comenté en la anterior entrada, si bien ando mas liado que el chapísta de MazingerZ, al menos ya tengo tiempo suficiente como para poder seguir desarrollando Cell Fusion.

Uno de los objetivos que tengo enumerados en el "Product Backlog" de la recta final, es la creación y pulimento de los sprites de todas las sondas del juego. Que si bien son pequeñitas, tienen diseños muy mejorables.

La verdad es que a la hora de ponerme manos a la obra me he dado cuenta de como ha ido pasando el tiempo a lo largo del desarrollo y como la experiencia a comenzado a notarse en el apartado gráfico. En mi opinión he mejorado bastante en cuanto a la gestión de la luz y la impresión de volumen. Ahora mismo llevo editadas 9 de las 18 sondas y como compensación a mi larga ausencia, me gustaría enseñaros algunos de estos sprites.


A vuestra siniestra están situadas las imágenes antiguas, a la diestra, las editadas.

También, aunque parezca mentira, me esta yendo bastante bien el gestionar Pixelamos. Ver y traducir tanto tutorial, criticar y observar los trabajos de otros, es muy útil para crecer. A la hora de incluir las sondas en el juego, es posible que tenga que aumentar el contraste y bajar el brillo como consecuencia del efecto Blur.

He de admitirlo, los últimos acontecimientos me han desbordado.

El nacimiento de Diana, el cambio de vida, las mudanzas, la inestabilidad laboral... han convertido mi vida en un auténtico desorden.

Me gustaría poder decir que hablo a toro pasado, pero la verdad es que no. Sin embargo, si es cierto que al menos ya estoy en casa y que poco a poco empiezo a amoldarme a la situación.

Durante los últimos días he estado haciendo un poco de "propósito de enmienda" aprovechando el descalabro de mi planificación para las últimas semanas del año. Por una parte, como ya comenté, terminé por animarme a crear la comunidad de Pixel Art, que tanto tiempo llevaba pensando en montar. Hoy a las pocas semanas de haberla creado, ya llega a los 130 usuarios y dispone de una actividad bastante agradable. Por otra, hace poco decidí ponerme manos a la obra y montar de nuevo toda Comunidad Game Maker salvando los datos antiguos, documentando el proceso para futuros administradores y haciendo un cribado en el equipo para sanear la gestión de la comunidad. Ha sido un follón, pero la verdad es que ha quedado mejor que nunca. Otro peso que me quito de encima.

El pequeño retiro, aunque ha sido estresante en muchos aspectos, me ha permitido ver el proyecto de Cell Fusion con un poco mas de perspectiva y librarme de algunas de mis ansiedades por no cumplir objetivos antes de las fechas estipuladas. Si algo tiene bueno caerse, es que del suelo, no pasas. :P

Pero bueno, tampoco se puede decir que no haya estado haciendo nada, conste. Lo que he podido avanzar, ha quedado bastante bien. Se vé que el participar en la comunidad de Pixel Art me está ayudando a aprender mejor la senda del pixel. Sigo sin poder considerarme una eminencia, pero la verdad es que estoy muy contento con lo que me va saliendo.

Por el momento he terminado con el jefe final, que ha resultado ser enorme, casi demasiado, pero que con la rutina sencilla que le he terminado por programar, cumple con lo que el juego necesitaba representando un desafío aceptable.

También he portado el proyecto a GM8, que tiene un intérprete más potente y unos tiempos de carga sensiblemente inferiores con respecto a sus predecesores.

Por último, ahora mismo me estoy dedicando a rehacer todas las sondas. Ahora mismo llevo 6/18 con buenos resultados, al menos para mi gusto. Ahora las variantes de cada modelo se diferencian más entre sí y tienen un acabado bastante más correcto.

En cuanto al guión... al final me parece que le voy a pegar un señor hachazo, ya que tiene poco peso en el juego. Si lo hubiera tenido más en cuenta durante el proceso de diseño, no me vería en esta situación, pero bueno, tampoco se puede decir que no haya aprendido de todo esto.

Objetivos restantes ("Product Backlog"):

- Intro 1
- Intro 2

- Textos intermedios

- Tutorial
- Final

- Nivel 6
- Ajustes Items

- Completar sprites Sondas
- Añadir nuevas armas [En reconsideración]


Sprint 1, semanas 41-42: Terminar Intro 1 y hacer los ajustes de los Items.

Semana 1:

- Insertar introducción al inicio.
- Mostrar los textos centrados junto a la imagen.
- Añadir efectos de transición entre imagenes.
- Añadir sonidos y música.

Semana 2:

- Crear los sprites de los nuevos ítems.
- Crear su funcionalidad.
- Redistribuirlos.

Sprint 2, semanas 43-44: Hacer Intro 2

Semana 1:

- Crear texto.
- Insertar introducción al inicio del nivel.

Semana 2:

- Crear imágenes.
- Añadir sonidos y música.

Sprint 3, semanas 44-45: Textos intermedios y Final

Semana 1:

- Crear textos (Creados, pero no traducidos)
- Crear imágenes (No me convence como quedan)

Semana 2:

- Insertar los textos al inicio de cada nivel
- Insertar final
- Añadir sonidos y música. (Los sonidos aún no me convencen)

Sprint 4, semanas 46-47: Tutorial

- Crear textos tutorial
- Crear imágenes tutorial
- Ubicar tutorial

Sprint 5, semanas 48-49: Nivel 6 completo.

Semana 1:

- Crear imagen jefe final.
- Crear patrones jefe final.

Semana 2:

- Crear flujo nivel.

Sprint 6, semanas 50-51: Imágenes para las sondas y nuevas armas

Semana 1:

- Crear 12/18 imágenes para las nuevas sondas

Semana 2:[En reconsideración]

- Crear ítems para las nuevas armas
- Implementar las nuevas armas

Bueno, pues esto es todo por hoy, tan pronto como me sea posible, estaré aquí de nuevo con vosotros.

¡Nos leemos!

Pronto todos los aficionados de la informática clásica tendremos una cita ineludible con una edición nueva, diferente y a la vez igual, de una de las más famosas ferias de "retroinformática", será igual porque nuevamente tendremos ocasión de vernos con nuestros amigos, charlar con los más expertos y sobre todo compartir una jornada (y esperemos que jornadas) en las que la informática clásica será el nexo de union de multitud de aficionados a los que os queremos recibir con los brazos abiertos.

Sin embargo será nueva, diferente, y no porque cambiemos de ubicación, sino porque RetroMadrid es más que nunca una obra de gran magnitud en la que decenas de personas participarán para que esta edición de 2010 signifique un cambio conceptual que ya os adelantamos, será muy enriquecedor y transformará esta feria en "algo más". Esperemos que el esfuerzo que la organizacion ha volcado tenga la respuesta necesaria para hacer realidad todos los anhelos de los que conformamos este prometedor proyecto.

No dejes que tus amigos, compañeros o familiares se lo pierdan y aprovecha para ayudarnos difundiendo el cartel de la nueva edición, que es probable que modifiquemos en tiempo real según se confirmen posibles nuevos patrocinadores.

Saludos lupinos. Hoy os dejo una entrada rápida ya que paso por casa.

Se trata de un vídeo con 100 juegos creados con GM durante el pasado año. Me alegra ver que la calidad de los juegos continua ascendiendo.


Juegos GM 2009

¡Felices fiestas!

¡Saludos lupinos!

Os escribo para comentaros que hace poco nació mi niña. No tengo mucho tiempo para comentaros porque estoy que me caigo. Como no duerma algo me voy a cagar.

La madre y la nena están estupendamente. La niña es muy mona. La primera noche se comportó muy bien, pero sería por falta de confianza, ahora ya sabe cuales son sus papis y ya se dedica a no dejarlos apartarse de ella durante mas de dos horas seguidas. Sea de día o noche, te pille comprando el pan o en el bater, de esos detalles sin importancia no entiende.

Solo comentaros que aunque sigo vivo, voy a tardar un poco más en crear nuevas entradas o responder los comentarios, al menos durante unos días, hasta que pueda volver a casa, hacer las compras y papeleos de rigor y que mi mujer se recupere un poco.

Foticos para los curiosos

Felices fiestas a todos, ¡seguimos en contacto!

¡Saludos lupinos!

Hace un tiempo que llevaba dándole vueltas al tema de crear una comunidad de Pixel Art en castellano. Al final, viendo el interés de varios de vosotros, me he animado a dar el primer paso. La integración técnica y la incorporación del material inicial ya están terminados, a partir de ahora es cosa de continuar publicitando la iniciativa.

Ya de paso, me gustaría agradeceros de nuevo la ayuda que me estáis brindando José Zanni, Dani y Alberto, Soujiro, LuisYX y tantos otros que de una forma u otra se han implicado desde el principio con su ayuda desinteresada. Así da gusto señores.

¡Felices fiestas!

PIXELAMOS

Comunidad Hispana de Pixel Art

Si bien existen desde hace mucho grandes comunidades dedicadas a esta disciplina, como amantes del Pixel Art, muchos de nosotros hemos echado en falta la existencia de una comunidad única en la que compartir nuestros conocimientos y trabajos sin necesidad de manejar con soltura un segundo idioma.

Con la intención de cubrir este vacío, surge la idea de crear "PIXELAMOS", una comunidad hispana dedicada al Pixel Art en la que compartir nuestros conocimientos, trabajos e incluso buscar grafistas para nuestros proyectos. Para nosotros es algo más que el poder compartir conocimientos, es también brindar la oportunidad de crear un concepto de "escena", facilitar la comunicación entre grafistas y desarrolladores, fomentar la práctica mediante la participación en nuestras actividades y traducir material didáctico a nuestra lengua para facilitar el aprendizaje de esta disciplina entre la población hispano parlante.

Esperamos que esta nueva comunidad os agrade tanto como a nosotros crearla:

http://www.siliconcreatures.com/pixelamos

¡Seguimos en contacto!

Saludos lupinos.

Llevo un tiempo queriendo crear una especie de curso, pero tras darles algunas vueltas al tema he pensado que lo mejor que puedo hacer es ir creando entradas relacionadas con el tema e ir compartiéndolas con vosotros poco a poco. Si más adelante alguien quiere utilizar el sistema de comentarios para enseñarnos algo, o pedirnos consejo a los demás, está invitado a hacerlo.

También llevo tiempo barajando la idea de mejorar la comunicación en la "escena hispana" creando una comunidad de amantes del Pixel Art en castellano, ya que aunque han existido varias, actualmente no parece quedar ninguna. Las comunidades angloparlantes son estupendas, pero hay conceptos que para muchos es difícil de tratar en inglés, limitando su capacidad de aprendizaje y la comprensión de las críticas vertidas por sus colegas extranjeros.

Por desgracia es un tema que tengo relevado a un segundo plano en espera de sacar algo de tiempo de debajo de alguna piedra, pero todo llega. Por el momento, si alguno de vosotros esta interesado, ya sea para confirmar su interés en que exista una comunidad de este tipo o para colaborar activamente, agradecería que me lo comentará por aquí o vía email.

Volviendo al tema de los "tutoriales", he pensado que por ahora, el mejor comienzo es hablar un poco de los términos utilizados con más frecuencia cuando se habla de Pixel Art. Como veréis, como la mayoría de los términos relacionados con la informática, están en Inglés. Si nos interesa el Pixel Art, cuanto antes los manejemos, mejor.

Anti-Aliasing/AA: Técnica de Pixel Art que permite suavizar la transición de un color a otro. No se trata de un contorno o un degradado.


Dithering: Técnica de Pixel Art que simula un degradado de un gran número de colores con un número reducido de estos. Este efecto se consigue a base de entrecruzar patrones para crear tramas, creando el efecto de que existen más colores. Un ejemplo de tramado sencillo es el de un tablero de ajedrez. Visto de lejos, este tramado de dos colores parece formar un tercer color.


Edit: Se llama "edit" al Pixel Art surgido de la edición de un trabajo ajeno.


GIF: "Graphics Interchange Format" es un formato gráfico desarrollado por CompuServe a mediados de los ochenta para imágenes fotográficas. Permite guardar imágenes tanto estáticas como animadas. Por su bajo peso es muy apropiado para el Pixel Art. El número máximo de colores soportado por este formato es 256. Cuenta con un único color transparente.


HSL: Modelo de color básado en sus componentes de tono, saturación y luminosidad. Muy utilizado en Pixel Art.


Hue-Shift: Hace referencia a una paleta cuyos colores mas brillantes y oscuros difieren en tono, formando un degradado de tonos y luminosidad al mismo tiempo. Ejemplo: una paleta creada para dibujar llamas puede tener como colores mas luminosos los mas cercanos al amarillo claro, mientras que los mas oscuros se aproximan al rojo oscuro pasando por toda una gama de naranjas de diferente tonalidad.


JPG/JPEG: El Némesis del Pixel art. Cuando hagas Pixel Art no guardes nunca tus graficos en este formato. El JPG aplica un sistema de compresión que destruye los efectos creados con esta técnica al introducir suavizados y eliminar parte de la informacion de color. Este formato puede ser estupendo para fotografías, pero nunca para el Pixel Art.


Lineart: Un sprite que contiene únicamente las líneas de la imagen, sin color o antialias.


Luminance: Brillo. Es uno de los tres componentes que forman un color en el sistema HSL. Un valor de 0% crea un color negro, independientemente de su tono o saturación. De la misma forma, un valor de un 100% crea un color blanco independientemente de los demás componentes.


MockUp: "Maqueta". En el desarrollo de videojuegos, se refiere a una imágen creada por un grafista para mostrar como se verá una parte del juego en funcionamiento. Por ejemplo, una imagen en la que se ve el marcador y un personaje saltando sobre unas plataformas mientras es atacado por varios enemigos, como si de una captura de imágen se tratara. Esto permite al resto del equipo ver si el arte es correcto y comprender cual debe ser el aspecto y funcionamiento final del juego.


PA: Pixel Art, forma de arte digital creada mediante software de edición de bitmaps. Las imágenes asi creadas son editadas a nivel de píxel, es decir, punto por punto. Esta técnica excluye la utilización de herramientas automatizadas comunes en editores de imágen como el Antialias automático o la utilización filtros.


NPA: No pixel art. Cualquier imagen creada mediante una técnica distinta al Pixel Art.


Paleta: Conjunto de colores utilizados en una ilustración. En algunos sistemas, las paletas a menudo pueden quedar limitadas a 4, 8, 16 o 256 colores. En los sistemas actuales el número asciende hasta los 16 millones.


Pixel: Un píxel o pixel (acrónimo del inglés picture element, "elemento de imagen") es la menor unidad homogénea en color que forma parte de una imagen digital, ya sea esta una fotografía, un fotograma de vídeo o un gráfico.


PNG: Portable Network Graphics es un formato gráfico basado en un algoritmo de compresión sin pérdida para bitmaps no sujeto a patentes. Este formato fue desarrollado en buena parte para solventar las deficiencias del formato GIF y permite almacenar imágenes con una mayor profundidad de contraste, mayor número de colores y diferentes niveles de transparencia.


Ramp/Color Ramp: "Rampa" una paleta esta compuesta de varias rampas. Se entiende por "rampa" a cada degradado de color que posee la paleta. Ejemplos: "rampa" de azules, "rampa" de rojos...


RGB: Modelo de color basado en los componentes rojo, verde y azul de un color. Poco utilizado en Pixel Art.


Saturation/Saturación: Dentro del modelo de color HSL es el que define la intensidad del color. A menor saturación de color, menos "tinte". Un gris neutro es un color sin saturación, independientemente de su luminosidad o tintura.


Sprite: Imagen utilizada para representar un objeto o un personaje en un videojuego. Un Sprite puede ser una imagen animada formada por varias sub imágenes o "frames". Estas imágenes a menudo son creadas mediante Pixel Art.


Sprite sheet: Imagen no animada de gran tamaño que contiene todas las subimagenes de uno o varios sprites. Puede entenderse como un "pack de sprites".


Tint/Tono: Dentro del modelo de color HSL es el que define el tono ("tinte") de un color, independientemente de su luminosidad o saturación.


Texturing/Texturizado: Técnica utilizada para simular diferentes materias (piedra, metal, hierba, fuego...)


Tile: Para crear un fondo, a veces es bueno utilizar imágenes pequeñas que, puestas una al lado de otra, forman un dibujo. Estas imagenes reciben el nombre de "tile", en sentido literal puede entenderse como "azulejo", ya que es posible crear fondos como si de mosaicos se tratasen.


Tiling: Técnica de creación de fondos a traves de la unión de varios tiles.


Tile Sheet: Es una imagen de gran tamaño que contiene varios tiles. Puede entenderse como un "pack de tiles".

Bueno, eso es todo por hoy. Si queréis añadir alguno para mejorar el listado, o veis que me he equivocado en algo y creéis que hace falta hacer una corrección, sentíos libres de hacerlo.

¡Nos leemos!