La Zona KF

El otro día Richard Stallman publicó un artículo en la web de la FSF (Free Software Fundation) en el que reflexionaba acerca de los problemas que podría suponerle al software libre, depender de Mono o C#.

Paso a copiar el texto original, en inglés (al final de la entrada encontraréis un enlace a una traducción a español), y luego haré una breve reflexión personal:

Este artículo viene a cuento de la decisión de Debian de incluir Mono en la distro. Mono es una implementación de código abierto de .NET, una plataforma de desarrollo de Microsoft.

El artículo se centra en explicar por qué es una mala idea que el software libre dependa de Mono o C#, y se resume en uno de los problemas a los que hace frente la FSF con más fuerza: las patentes de software. C# está sujeto a patentes de software, así que el problema que plantea Stallman se resume en que si se desarrolla cada vez más software libre en C#, podría llegar Microsoft y hacer efectivas las patentes, lo que supondría un grave daño a esos programas, a todas las distros que las incluyesen y a la propia imagen del software libre.

Esta tercera parte tenía que haberla publicado hace semanas, pero no he podido porque me fui al pueblo de vacaciones. De todos modos desde entonces no he hecho nada nuevo, y esta parte 3 ha consistido en rehacer cosas.

Novedades

He tenido que rehacer toda la parte del código que se encargaba de crear y dibujar el mapa, por los problemas que tuve con el bloqueo en la parte 2.

Ahora el mapa está formado por tiles. Eso significa que cada mapa requiere dos archivos:

• Un archivo de imagen con los trozos de mapa que se van a usar (a ese archivo se le conoce como chipset o tileset, y a los trozos de mapa se les llama tiles).
• Un archivo de texto que almacena un código formado por varias letras, que identifican a cada tile. El código hace referencia a uno de los trozos/tiles del archivo de imagen.

El scroll ahora no es suavizado, es lineal, normalito. El cambio se debe a una cuestión de eficiencia, pues el suavizado que había no aportaba nada que fuese lo suficientemente interesante como para sacrificar recursos.

Siguiente etapa

Cuando el personaje llega al borde se queda en el sitio pero sigue la animación. Es algo que funcionaba bien en la parte 2, pero como ahora el mapa está formado de tiles... pues tengo que arreglarlo de nuevo. Nada complicado.

Quité las diagonales al rehacer la parte del mapa, tengo que plantearme a ver si me interesa el movimiento en diagonal o no.

Cuando termine con lo que acabo de comentar, sería un buen momento para empezar a pensar en las capas y la profundidad del mapa, ya que algunos tiles deberían tapar al personaje para que parezca que pasa "por detrás".

En la primera parte comenté que estaba desarrollando un RPG con Pygame (Python y SDL).

Hasta ahora tenía a un personaje animado que se podía mover por un mapa (una simple imagen) en 8 direcciones y con un movimiento por píxel. Vamos a repasar las novedades.

Novedades

Dije que el siguiente paso era conseguir que hubiese scroll (vamos, que la "cámara" siga al personaje según este se mueve) y que el personaje no se saliese de los bordes. Eso es lo que hice:

En el vídeo se puede ver que el personaje no se sale del mapa. Tuve problemas con el movimiento en diagonal hacia los bordes y esquinas, pero lo solucioné, da igual como se mueva el personaje, si se topa con el borde no se saldrá.

Además también se puede apreciar el scroll (00:07 del vídeo) aunque muy poquito, porque no me di cuenta de que también tenía que mostrarlo. X_x

Siguiente etapa

Llegados a este punto, tenía dos posibles caminos:

• Mostrar NPCs en el mapa (y que se muevan por su cuenta).
• Meterme a fondo con el mapa, las capas, profundidades, bloqueos y detección de colisiones.

El otro día escribí una entrada sobre Pygame, a modo de presentación, pero hoy voy a hablar sobre lo que estoy haciendo con Pygame.

El proyecto se llama "Nirvash", y consiste en reconstruir diversos elementos de todo RPG en 2D (mapas, colisiones, movimiento de personajes, secuencias, batallas, menús...) utilizando Pygame. Para empezar estoy intentando desarrollar el tema del movimiento de personajes.

La idea es conseguir que un personaje se mueva libremente por un mapa, con movimiento por píxel (no por cuadros o tiles como RPG Maker) en 8 direcciones y con animación al caminar (3 frames/imágenes de pose en cada una de las 4 direcciones, para las diagonales no uso poses propias aún).

Voy a hacer un repaso rápido por lo que he estado haciendo, sin pararme en detalles técnicos. Ya llegará el día en el que repase todo de forma que solo me entiendan los que programen. xD

Pygame es un conjunto de módulos (basados en SDL) para el desarrollo de videojuegos en Python. No es un IDE para Python, ni una herramienta de desarrollo de juegos (como podría ser RPG Maker o Game Maker).

Se puede destacar que:

• Es multiplataforma (funciona bajo distintos sistemas operativos).
• Es libre (licencia LGPL), así que cualquiera puede utilizarlo como base para el desarrollo de videojuegos bajo licencias de código abierto, libres, gratuitos, comerciales...
• El núcleo está escrito en C (más eficiente y rápido que Python).
• Los juegos desarrollados con Pygame pueden funcionar en algunos dispositivos Nokia o consolas (como por ejemplo gp2x).

Es una opción interesante para aquellos que quieran programar videojuegos en 2D, en general es fácil, aunque viene bien tener ciertos conocimientos de programación en Python y leer la gran cantidad de documentación que existe (ejemplos, artículos, libros, tutoriales...).

Desde hace tiempo sigo de cerca las novedades de Pygame aunque no me había puesto con ello hasta hace un par de días. La primera experiencia que he tenido es muy positiva, sobre todo gracias a la documentación que hay en LosersJuegos. De hecho, a modo de prueba, he empezado a desarrollar aspectos básicos de un RPG.