A continuación voy a escribir un tocho de extensión considerable, así que para ahorrar sufrimientos innecesarios a adictos al twitter y amantes del proverbio lo bueno si breve, dos veces bueno, aquí va la conclusión:
Windows tiene Graphics Gale, Mac OS X tiene Pixen, y GNU/Linux tiene… el Allegro Sprite Editor. Si te lo compilas.
Bueno, técnicamente los otros dos también lo tienen, es multiplataforma.
Antes de plantearse empezar un proyecto de software, considero imprescindible echar una ojeada a lo que han hecho otros en el mismo campo de lo que pensamos desarrollar. Vamos, ver cómo está el percal.
En el mundo del software privado (lo siento, soy alérgico a la palabra privativo en este contexto), por no intentar hacerle la competencia a monstruos como Photoshop o Flash. Ni la mismísima Adobe pudo hacerle sombra a Flash invirtiendo en SVG, así que acabó comprando Macromedia.
En el mundo del software libre, por no duplicar esfuerzos.
Al menos es lo que yo he hecho. Como usuario de software libre desde hace ya bastante tiempo, veo que una tendencia importante en el mundillo es la de empezar un proyecto nuevo por desavenencias tan graves con otros proyectos similares como:
- No me gusta GTK.
- No me gusta Qt.
- No me gustan ni GTK ni Qt.
- Las interfaces gráficas son para maricas, donde se ponga un buen modo texto…
- Vim es Dios.
- emacs r00lz.
- Este editor de texto no soporta resaltado de sintaxis del lenguaje de programación klinkon, que además de que puedes programar un juego tipo Final Fantasy XXVI con dos líneas, te hace las tostadas y te saca el perro a pasear… y aunque podría añadirle soporte fácilmente a dicho editor, prefiero programarme mi propio editor de texto. ¡Con casino! ¡Y furcias!
- El tirano del fundador del proyecto fasdafasda no me ha aceptado un parche que tardaba 0,000000000000001 segundos menos en pintar monos verdes con openGL. Mira que decirme que la ganancia en velocidad era nimia, estaba dentro del margen de error y no justificaba un hack tan feo… Pues he creado mi propia versión, FAST fasdafasda. ¡Chúpate esa!
- La licencia del programa asdf no es suficientemente libre. No incluye ninguna cláusula que permita explícitamente la impresión del código fuente en papel higiénico serigrafiado con dibujos de gatitos, así que hemos hecho un fork del proyecto original con una licencia prácticamente idéntica salvo en ese aspecto para acabar con semejante injusticia, la KPTPGPL (Kitten-Patterned Toilet Paper General Public License).
- Hay 9384 distribuciones distintas de Linux. Pero yo quiero una con el nombre de mi novia/perro/hijo primogénito.
Por una razón u otra, para cada tarea más o menos determinada suele haber del orden de 10 a 20 programas que básicamente hacen lo mismo, por lo que como usuario te puedes encontrar con 4 programas de diseño 3D, 10 sistemas de control de versiones o 200 editores de texto sin formato, con lo que te queda la duda de si al decantarte por uno no te estarás perdiendo nada de los otros 199.
¿A qué viene todo esto? ¿El tema de la entrada (y del blog) no eran los editores de sprites? Pues precisamente a eso iba: he estado buscando editores de sprites para Linux hasta debajo de las piedras y…
no hay.
Bueno, está el ya mencionado Allegro Sprite Editor. Si te lo compilas. Y ya está.
Con la de videojuegos basados en sprites para linux que hay, es curioso que la oferta de aplicaciones disponibles para esto sea tan limitada.
Peor aún: los editores tipo raster tampoco abundan. Ni Gnome Paint ni Gpaint tienen zoom y están verdes, verdes. Sólo pinta se salva de la quema. Los degradados son exageradamente lentos, pero aparte de eso me ha parecido bastante decente. ¡El zoom funciona! Y es indispensable si quieres tener un mínimo de precisión a nivel de pixel.
El zoom de Gnome Paint. Lo verás, pero no lo catarás...
Pero con pinta no se puede animar. Ni siquiera con un plugin aparatoso como GAP. Para hacer animación 2D tenemos a nuestra disposición programas más que aceptables y de filosofías tan diferentes como Synfig y Pencil. Adoro sobre todo Pencil, esa sencillez y orientación a la animación tradicional… pero claro, ninguno de los dos está orientado específicamente a sprites, y no tienen toda la artillería para procesar imágenes de GIMP, por lo que animar un muñecajo y llevarlo a tu juego pasaría por las siguientes fases:
- Una vez acabada tu animación, exportarla en forma de secuencia de imágenes png.
- Pencil está bastante limitado a la hora de colorear, así que tal vez prefieras hacerlo con GIMP.
- La mayoría de motores de sprites y bibliotecas de funciones multimedia prefieren o exigen sprite sheets por motivos de rendimiento, así que toca hacerse un script que trabaje con GIMP, PIL, ImageMagick o similar para pegar todos los cuadros de animación en una sola imagen.
- Te queda lo más duro: especificar los datos propios de los sprites como número de cuadros y frecuencia (cuadros por segundo) de cada animación, coordenadas de mapeado de cada cuadro, cajas de colisión, etc. Mucha gente lo suele hacer directamente en código (hard coding), lo cual es un horror, ya que te obliga a mantener tu código actualizado respecto a los sprites y a volver a compilar o ejecutar cada vez que cambias algo. También los hay que se fabrican sus propias mini-utilidades para exportar este tipo de datos a XML. Lo malo es que lo suelen hacer en Visual C++ o Visual BASIC…
- Si ves que la animación se te queda corta, larga, o no pega con el resto del juego, vuelve al punto uno. No te olvides de revisar uno por uno los cuadros que componen cada animación si cambias algo. De nada.
Animar y desarrollar videojuegos ya son actividades sobradamente duras por sí mismas. Por esto y por mucho más, he decidido hacer bueno el dicho de si te pica, te rascas tan propio del software libre y ayudarme a mí mismo a la vez que, espero, ayudo a otros.
Sprite Hut 
10 Comments
Entonces queda claro que Sprite Hut tiene su cabida. Lo que me extraña es que nadie lo haya hecho antes si, como bien dices, abundan los juegos 2D que hacen uso de sprites.
Quien sabe, si tu proyecto sale bien, puede que aceleres el desarrollo de muchos juegos más.
Saludos.
PD: Tocho-entradas pero bastante amenas :D.
Hola, David.
A mí también me extraña. Creo que lo que pasa es que cada vez que alguien pregunta por un editor de sprites o de bitmaps le mandan a GIMP. Que es genial y por poder, se pueden hasta dibujar y animar sprites. Pero es matar moscas a cañonazos, como lo sería usar Photoshop en otras plataformas.
Por otro lado, creo que los programadores en general y los linuxeros en particular somos muy nuestros y sufrimos el síndrome NIH. He visto echar pestes de SFML porque hace demasiado por ti. Si es que… donde se ponga una aguja imantada y buen pulso… xD
Ni los editores de sprites ni los exportadores de datos de sprites son ideas nuevas, es más, para esto último me sirvió de inspiración el abandonado proyecto Kyra.
Quién sabe si la idea de aunar ambos aspectos en el mismo programa cuajará o no. Eso el tiempo lo dirá. Tal vez salgan decenas de editores de sprites parecidos. O sólo lo usemos tres.
En cualquier caso, los programadores y diseñadores tendrán una herramienta más a su alcance, que creo que nunca viene mal. Usarla o no, ya dependerá de cada uno.
Es curioso que haya engines comerciales para desarrollar juegos como el Unreal que proporcionan un conjunto de herramientas para acelerar el desarrollo brutales y no existe un homónimo en el software libre.
Unreal Engine es mastodóntico pero podría existir un motor 2D pequeñito que tuviera un conjunto de herramientas a su alrededor que acelerasen el proceso de creación de contenidos. Editor de niveles, de sprites, un formato de exportación común, etc.
Sería muy interesante un proyecto así, aunque utilice librerías existentes como Gosu…
Saludos.
Hombre, David, que precisamente Ogre facilita mucho las cosas xD. Y hay otros motores no sólo gráficos basados en él o independientes, como Crystal Space, Panda 3D o Irrlicht que tienen su público. Lo que fallan son las herramientas, que casi siempre te mandan a Blender, pero no se puede tener todo.
Dudo que un equivalente al Unreal Engine para GNU/Linux llegase a tener mucho éxito precisamente por la mentalidad si es fácil, no puede ser bueno que te comenté antes.
Para 2D existen muchísimos proyectos: BennuGD, Löve, Pyglet… (de hecho tengo pensado integrar este último en los tests de sprites). El Ethanon Engine me parece muy prometedor, pero aún es exclusivo de Windows, y mira que usar AngelScript para programar… parece un lenguaje de script especialmente inventado para la ocasión. Bueno, antes de que se me olvide, otro compañero del concurso se está montando su propio casino… digoo motor 2D: Onyx Illusion.
Creo que lo que sobran son motores 2D y bibliotecas varias, aunque lo que dices es muy buena idea. Yo voy a aportar mi granito de arena con Sprite Hut y el resto ya veremos. Para editar mapas tileados, Tiled no está mal.
Hola Juan, soy el creador del Allegro Sprite Editor (ahora llamado ASEPRITE). Cuando comencé a desarrollarlo me dijeron «ya existe un ganador, y se llama GIMP, ¿por qué no ayudas con el GIMP?», sencillamente mi respuesta a este tipo de preguntas es «porque tengo ganas de hacer un programa yo mismo» 🙂
Ninguna cosa que hagas necesita justificativo alguno, sencillamente si tenes ganas de programar un editor de sprites, hacelo. Punto 🙂
Ya nombraste el ASEPRITE, te dejo otro multiplataforma: El GrafX2
http://code.google.com/p/grafx2/
Muy parecido al Deluxe Paint. Usa la SDL para la interfaz gráfica. Es muy bueno, aunque tiene ese estilo clásico de las interfaces DOS.
Lo que me gusta de tu proyecto es que vas a usar Python para desarrollarlo, eso puede facilitarte y acelerar el trabajo. Buena elección (también C# y Mono serían otra buena elección).
Por el problema sobre ASEPRITE que no viene ya compilado para Linux, en próximas versiones tengo pensado sacar paquetes Debian. Espero que eso ayude (igualmente la mayor cantidad de diseñadores parece usar Windows o Mac OS X).
Suerte con el proyecto!
Hombre, el creador de ASEPRITE. Y además eres hispanohablante. ¡Qué agradable sorpresa! 😀
Yo simplemente respondería a esa pregunta que GIMP no me parece la herramienta adecuada para editar sprites. Puede servir, igual que puedes clavar una alcayata con un destornillador, pero lo mejor es un martillo. GIMP me encanta pero para otros usos.
Por supuesto que para empezar un proyecto de software o cualquier cosa no es necesaria justificación alguna, y es respetable que cada uno invierta su tiempo como desee. Lo único que pasa es que como usuario preferiría tener unas pocas (máximo 10) alternativas fuertes y bien acabadas para cada tarea en lugar de encontrarme con decenas o centenares de proyectos en fase beta o alfa. Creo que decenas de proyectos muy similares podrían aunar esfuerzos y no sólo beneficiarse ellos sino sus usuarios.
Comprendo que resolver un problema puede tener varios enfoques, como centrarse más en la facilidad de uso o en la potencia, pero cuando la cantidad de alternativas es muy abundante, la elección del usuario se torna más difícil o imposible. Un ejemplo que me parece bastante representativo de esto es el de las distribuciones de GNU/Linux. Más de una vez me han venido amigos que querían dar el salto a Linux con la misma pregunta: ¿Cuál Linux me instalo? La verdad es que yo mismo me la planteé en su tiempo, y ahora es aún más difícil elegir ya que no sólo hay más distribuciones para elegir, sino que también tienes que escoger escritorio por defecto.
En fin, supongo que no hay nada que hacer. Yo mismo en vez de unirme a otros de los escasos proyectos que hay de editores de sprites he decidido empezar el mío, así que lo digo con la boca pequeña. 😛
Gracias por el enlace a GrafX2. No lo conocía, y puede ser una fuente de inspiración para el proyecto.
Lo gracioso es que en un principio la implementación de Sprite Hut pensaba hacerla en BennuGD. Pero claro, tendría que programarme mi propio toolkit gráfico, sistema de traducción/localización, etc. Así que me decanté primero por GTK que es el toolkit con el que más familiarizado estoy y luego por Python que lo descubrí hace unos meses y me encantó por su sencillez y potencia. Sin duda acelerará la implementación.
Con C# hice mis pinitos en Linux hace cosa de 4 años pero igual porque Mono no estaba muy maduro no me acabó de convencer. Y últimamente descarté cambiar a Vala por eso mismo. No quiero tropezar dos veces con la misma piedra.
¡Que vayan a haber paquetes Debian de ASEPRITE es una excelente noticia! 😀 Obviamente habrá más usuarios de Windows y Mac, pero si encima no le pones las cosas fáciles a los usuarios de linux… sobre todo para usuarios poco curtidos puede resultar intimidatorio acudir a la consola.
Demanda para editores de bitmap sencillos y sprites en Linux hay, por eso no te preocupes. Y competencia, escasa. Quién sabe si de aquí a dos años hay 20 editores de sprites, lo cual no sería necesariamente malo. xD
Gracias por tu visita e impresiones, David. Espero que Sprite Hut sea de tu agrado cuando tengamos algo presentable.
> Yo simplemente respondería a esa pregunta
> que GIMP no me parece la herramienta adecuada
> para editar sprites.
Igualmente podrías agregar un plugin o modificar el GIMP para soportar una edición de sprites. El problema es si estás dispuesto a gastar una gran parte de tu tiempo libre aprendiendo el código del GIMP, para luego recién poder hacer algo útil.
> Por supuesto que para empezar un proyecto de
> software o cualquier cosa no es necesaria
> justificación alguna, y es respetable que cada
> uno invierta su tiempo como desee.
Claro. Sólo una aclaración, los únicos proyectos que no requieren justificación son los de software libre o abierto. Todo demás proyecto requiere un justificativo (ej: si pensas gastar dinero para luego obtener ganancias).
> Lo único que pasa es que como usuario
> preferiría tener unas pocas (máximo 10)
> alternativas fuertes […] Yo mismo en
> vez de unirme a otros de los escasos
> proyectos que hay de editores de sprites
> he decidido empezar el mío, así que lo
> digo con la boca pequeña.
Sí, voy a hacer de cuenta que no escuché nada jaja Nuevamente confirmo, el único justificativo válido para comenzar un proyecto de software libre (siendo que existen alternativas) es: «porque tengo ganas de programar algo yo mismo por mí cuenta, porque tengo ganas de aprender, porque me gusta programar, y no quiero perder tiempo aprendiendo un montón de código de otras personas en un lenguaje y con un framework que desconozco». Y esto que digo no es malo, sólo hay que tenerlo bien presente.
> ¡Que vayan a haber paquetes Debian de ASEPRITE
> es una excelente noticia! Obviamente habrá más
> usuarios de Windows y Mac, pero si encima no
> le pones las cosas fáciles a los usuarios de
> linux…
El tema no es ponerle o no las cosas fáciles a los usuarios de Linux (y otra plataforma, y otro grupo de gente). El problema es cuánto tiempo libre tenes disponible. Sobre esto mi reflexión es la siguiente: si existe gente que quiere versiones de ASEPRITE para Linux, y yo no tengo tiempo para empaquetarlas ni aprender cómo se empaqueta ¿por qué esa gente no me ayuda a hacer los paquetes?
Si realmente el objetivo fuera tener disponible un editor de sprites para Linux, simplemente ayudaríamos a otros proyectos (ej: GIMP, GrafX2, o ASEPRITE). Por lo tanto, el objetivo sencillamente es otro: «quiero programarlo yo» 🙂 Y realmente me parece fabuloso y lo mejor que te puede motivar a hacer el proyecto. Hacer las cosas para otras personas es deprimente (encima si no te pagan), hacerlo simplemente porque a vos te gusta es la mejor sensación que te puede pasar.
> Gracias por tu visita e impresiones, David.
> Espero que Sprite Hut sea de tu agrado cuando
> tengamos algo presentable.
Por nada Juan, voy a estar siguiente el desarrollo de cerca, todo lo
relacionado a editores de sprites me gusta (además te puedo robar alguna que otra idea y viceversa).
Saludos
>Igualmente podrías agregar un plugin o modificar el GIMP
> para soportar una edición de sprites. El problema es si estás
> dispuesto a gastar una gran parte de tu tiempo libre aprendiendo
> el código del GIMP, para luego recién poder hacer algo útil.
Pues hacer un plugin para GIMP también se me pasó por la cabeza, pero las APIs para plugins me temo que son insuficientes para hacer todo lo que quiero, y en cuanto a modificar el código de GIMP directamente ocurre lo que dices. No es práctico para una sola persona, y no sé si mucha gente estaría dispuesta a ayudarme en tamaña tarea.
>Claro. Sólo una aclaración, los únicos proyectos que no requieren
> justificación son los de software libre o abierto. Todo demás proyecto
> requiere un justificativo (ej: si pensas gastar dinero para luego obtener
> ganancias).
No necesariamente. Puedes desarrollar algo por afición o gusto y luego distribuir sólo los binarios gratuitamente o a cambio de dinero, modalidades que no entrarían dentro de lo que entendemos como software libre.
>[…] Nuevamente confirmo, el único justificativo válido para comenzar un proyecto de software
>libre (siendo que existen alternativas) es: “porque tengo ganas de programar
> algo yo mismo por mí cuenta, porque tengo ganas de aprender,
>porque me gusta programar, y no quiero perder tiempo aprendiendo
> un montón de código de otras personas en un lenguaje y con un
>framework que desconozco”.
Si no te digo que no. El factor ego es importante, es más, yo mismo admito en la entrada que el objetivo primario del proyecto es ayudarme a mí mismo. Pero no creo que sea la única justificación válida, ya que si el objetivo fuera hacer un editor de sprites única y exclusivamente para mi aprendizaje, uso y disfrute, ¿no sería mejor desarrollarlo en mi casa sin decírselo a nadie? Me iba a ahorrar muchos disgustos y podría presumir de 100% de usuarios satisfechos. Y de software libre, nada. ¿Para qué?
Respecto a que existen alternativas, ninguna de las que hay en la actualidad satisfacen mis necesidades y adaptarlas me costaría más tiempo, esfuerzo y desprecios varios que empezar mi propio proyecto (que ya es decir). ¿Crees que hacer un fork o presentar un parche más grande que todo el código de un proyecto de software libre en mi caso son opciones viables?
> Y esto que digo no es malo, sólo hay que tenerlo bien presente.
¿Quién ha dicho que sea malo? Excusatio non petita…
>El tema no es ponerle o no las cosas fáciles a los usuarios de Linux
> (y otra plataforma, y otro grupo de gente). El problema es cuánto tiempo
>libre tenes disponible. Sobre esto mi reflexión es la siguiente: si existe gente
> que quiere versiones de ASEPRITE para Linux, y yo no tengo tiempo para
> empaquetarlas ni aprender cómo se empaqueta ¿por qué esa gente no me
> ayuda a hacer los paquetes?
Muy buena pregunta. ¿La has hecho abiertamente?
Porque me extraña que viendo cosas como ésta o ésta nadie se haya dignado a empaquetar ASEPRITE o GrafX2 para su distribución de Linux favorita. De hecho, veo que GrafX2 sí que tiene versiones binarias para muchísimas plataformas, entre ellas varias distribuciones de Linux.
Igual tienes razón y no hay suficientes linuxeros ni usuarios de otras plataformas a los que les importe ASEPRITE lo suficiente. Lo siento.
>Si realmente el objetivo fuera tener disponible un editor de sprites
> para Linux, simplemente ayudaríamos a otros proyectos (ej: GIMP, GrafX2, o
>ASEPRITE). Por lo tanto, el objetivo sencillamente es otro: “quiero programarlo yo”
> Y realmente me parece fabuloso y lo mejor que te puede ;motivar a hacer el proyecto.
> Hacer las cosas para otras personas es deprimente (encima si no te pagan), hacerlo
> simplemente porque a vos te gusta es la mejor sensación que te puede pasar.
No quiero repetirme, pero evidentemente si hago algo así gratis y la vista de todo el mundo, será por gusto y satisfacción personal pero habrá otros factores también. Y perdona que difiera pero he hecho cosas para otras personas sin cobrar y para nada me parece algo deprimente. Sé que suena muy mal, pero me refiero en mi caso a colaborar en otros proyectos, aunque no eran de software.
>Por nada Juan, voy a estar siguiente el desarrollo de cerca, todo lo
>relacionado a editores de sprites me gusta (además te puedo robar alguna que otra idea y viceversa).
>Saludos
¡Faltaría más, hombre!
Hasta otra, y me puedes llamar Juanjo. 🙂
quizas este plugin te sirva para hacer el sprite sheet en Gimp: http://www.losersjuegos.com.ar/software/gimp
Gracias. Ya me había hecho mi propio script hace tiempo, pero de todas formas hacer sprite sheets con GIMP es el menor de los problemas.
Perdona que haya tardado tanto en validar tu comentario, estaba de exámenes.
One Trackback/Pingback
[…] Sobre el blog « Situación actual de los editores de sprites en GNU/Linux y otros sistemas. O por qué decidí meter… […]