Animado

Bueno, ultimamente estudio y no he hecho demasiado....

Justo pensar un poco como puedo hacer el tema de cambiar el sprite y he llegado a diferentes conclusiones:

- Las rotaciones es preferible hacerlas guardando dibujos en diferentes posiciones en el archivo de frames, al menos mientra no use openGL ya que tiene que ser bastante caro el rotar la imagen en terminos de CPU (es una operacion bastante cara con SDL y ademas destructiva, no se puede rotar una imagen previamente rotada pq pierde mucha calidad, con lo cual debiera hacer un sistema de 'caches' de objetos rotados para no transformar en cada ciclo la imagen de una nave que viaje en diagonal... mucho lio que como mucho va a tener el rendimiento de meter imagenes rotadas... no merece la pena, tal vez con openGL si pq lo hace la GPU, con lo cual no debo cerrar la puerta, pero ahora no).

- He creado un objeto 'Animacion' que contiene a una fila de frames de una imagen, esto es, la animacion de que la nave gira a derecha, explota... Esto me permite separar la parte de gestionar la animacion de la de gestionar el sprite (colisiones, posicion, etc...). He probado a hacer animaciones de todos los objetos con toda las lineas y funciona... ahora debo sustituirlo en codigo y optimizar el protocolo que utilizo para el motor. Me gusta este cambio. Le da bastante flexibilidad al sprite.

- Ayer hable con angulo senior para que me probea de imagenes, no se si me he colado diciendole ya pq aun no tengo ni el esqueleto bien hecho, pero la verdad es que necesito imagenes de todo tipo para ir probando que todo funciona bien, las mascaras.... Esta bien hablar de esto con gente, te da ideas de cosas que hacer, un cierto feedback,  y eso mola... aunque aun tengo muchas mas ideas que tiempo...

En fin.

Grandes cambios se avecinan

Como me temia, el rotar las imagenes y hacer mascaras no son tareas nada triviales ya que mis frames estan todos en el mismo archivo...

Parece ser que la unica solucion que voy a tener es hacer subsurfaces de cada una de las frames que contienen cada imagen bmp (surface) y tratarlas de ese modo, con lo cual cambiara la el protocolo de mi motor grafico (idea que no me gusta  un pelo, pero parece que no hay otra). En vez de tratar subrectangulos de una superficie definidos por x,y,w,h, con lo que solo tenia que usar esas coordenadas, tendre que bregar con subsuperficies definidas por esas coordenadas, esto es: En vez de utilizar coordenadas para coger de un mapa tendre que cortar un mapa en trozos usando esas coordeanadas y usar los trozos....

En un principio no sera muy dificil cambiar, pero voy a tener que hacer un sistema de gestion de todos esos trozos que sea claro  y eficaz a la hora de hacer mascaras y rotaciones... me voy a la cama a pensarlo... esto va para largo....

Estancamiento ultrasonico

Si, parece que se acerca un periodo de estancamiento por varias razones:

1- He acabado satisfactoriamente el asunto de los sonidos y va ciertamente bien, aunque para evitar un HORRIBLE lag entre el hecho de disparar y que se oiga el disparo he tenido que desinstalar la libreria pulseaudio (por defecto con gnome, parece ser) e instalar la esound. Soluciona completamente el problema de el lag, y creo que solo ocurre en gnome, pero me parece una mala solucion. Tendre que cambiarlo en un futuro usando alguna otra libreria en vez de pygame (estoy penando en pysound). En cualquier caso, de paso, comentar que he hecho otro 'motor' para el sonido, de modo que los sonidos que se tengan que ejecutar lleguen por el mismo medio que los objetos que se deben dibujar. A la sazon lo que he hecho es un lista con todos los sonidos y un motor con una lista del mismo tamaño con booleanos que indican si se debe reproducir el sonido correspondiente en ese ciclo o no. De este modo no se puede, por ejemplo, ejecutar dos veces el mismo sonido en el mismo ciclo, lo cual me parece que no es una limitacion sino de cajon...

2- He vuelto a estudiar!!! ahora los fines de semana (este puente empece) los dedicare a estudiar hasta examenes.

En fin. Entre semna procurare ir haciendo cosillas que no sean demasiado complicadas ni tengan demasiadas implicaciones... aunque en la secuencia logica que tengo para hacer el juego supone saltarme  pasos y no estoy demasiado por la labor... se ira viendo...

Y bien...

Hoy tenia evisto continuar donde lo deje ayer:

Habia hecho un refactoring bastante bueno y habia comenzado a meter el tema del sonido, pero me voy a ir a por amaia a basauri asi que tendra que esperar...

Eso si, he aislado COMPLETAMENTE pygame dentro de mi aplicacion, lo cual facilita brutalmente el cambio de pygame por pyglet o pyopengl... Por ahora voy a aparcar ese asunto pq aun no lo necesito y ademas a partir de febrero tengo una asignatura que va sobre openGL...

La familia bien, gracias.

Manifiesto “En defensa de los derechos fundamentales en internet”

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de Internet manifestamos nuestra firme oposición al proyecto, y declaramos que:

1. Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.
2. La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.
3. La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.
4. La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.
5. Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.
6. Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.
7. Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.
8. Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.
9. Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.
10. En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Progresa adecuadamente

Caramba, cuanto tiempo llevo sin actualizar esto....

En fin, he terminado el tema de leer las coordenadas y dimensiones de un archivo de datos y he introducido explosiones que he hecho yo mismo con el gimp, ademas he refactorizado el codigo -algunos cambios de nombres, de lugares y eliminacion de metodos que se habian quedado deprecated-...

Hoy toca empezar a cambiar el motor a pyglet, para probar el rotar sprites tanto en pygame como en pyglet (se supone que tiene que darme mejor rendimiento en pyglet).

Proximamente tendre que ver como trato el tema de rotar los frames, tendre que hacer algo en la clase 'mapa' para controlar que no se roten frames que no sea necesario rotar (si una nave se desplaza en diagonal solo deberia tener que rotarla una vez si no varia su direccion), pero eso seria mas adelante, despues de hacer rotar los sprites de una manera eficiente quiero meter la musica, para finiquitar el motor -la musica tb se reproduce con pygame y pyglet-

Pero eso tal vez mañana, que hoy me duele la cabeza bastante...

Pequeñas maravillas de ssh; redirigir las Xs a ssh.

Esto es una pijadilla, pero bueno.

Con ssh podemos establecer conexiones cifradas entre dos ordenadores diferentes, para ello hacemos (por consola, si, lo siento, habra  algun interfaz, seguro, pero no lo conozco):

ssh (usuarioconelquetequieresloggear)@(direccionipdelamaquinaremota) -p (puertodelamaquinaremota)

El parametro -p es opcional (si no lo cambias especificamente el puerto de destino es el 22, de modo que el ordenador siempre busca el 22 por defecto).

Como ejemplo quedaria el comando, para mi ordenador al que le he puesto el ssh en el puerto 7777:

iñigo@deep-blue:~$ ssh iñigo@192.168.1.144 -p 7777

Esto nos abre una consola del ordenador remoto en el propio.

A partir de esto se pueden hacer cosas que tienen gran utilidad como tuneles y tuneles inversos, pero para eso remito a delicious, en mi pagina (http://delicious.com/inigod) tengo, en el tag ssh un par de paginas muy descriptivas.

Otra cosa increiblemente util y que acabo de 'redescubrir' -sabia que se podia hacer pero no sabia que era tan sumamente facil- es redirigir las X-s

Q son las X-s? Son las ventanas que dibuja nuestro linux, a diferencia de en windows, el programa que dibuja las ventanas esta pensado como un servidor, con ello lo que se consigue es que las ventanas que se obtienen al ejecutar un comando puedan ser redirigidas a diversas pantallas, escritorios....

Pues bien, tambien se pueden redirigir al ssh simplemente añadiendo el parametro -X

iñigo@deep-blue:~$ ssh -X iñigo@192.168.1.144 -p 7777

De este modo podremos ejecutar programas en el ordenador remoto y apareceran las ventanas en el nuestro con solo ejecutarlos desde la consola resultante de ssh!!!

Esto es, por ejemplo:

iñigo@deep-blue-remoto:~$gimp

Nos abrira una ventana en nuestro ordenador con un gimp ejecutandose en el remoto....

Esto es bastante util para hacer asistencias remotas a alguien (yo, por ejemplo no se hacer todo por consola y reconozco que para la mayoria de cosas apenas es necesario, asi que lo probare con mi hermano y con amaiita) y para instalar cosas que requieren instalacion por ventanas (como weblogic 10 u oracle 10,  uno de los dos se instalo parecido cuando yo trabajaba en osakidetza, pero lo hicieron mas enrevesado...)

En fin, parece util.

Saliendo del caos

He andado liado con medicos y tal...

Pero bueno, algo hemos avanzado. He hecho que el programa que escribe el archivo con las coordenadas de los frames de las naves saque sus resultados por pantalla ademas de a archivo, se debera ejecutar para todas las imagenes, ya que crea un *.shp en /info con la informacion que obtiene de el archivo de imagenes...

En el protocolo que utilizo para pintar se han añadido la x y la y, asi como la anchura y altura -todas estas coordenadas dentro de la superficie de frames- que definiran a el frame que ha de dibujarse.... de modo que queda algo asi:

[imageindex, x, y, rect.x, rect.y, rect.w, rect.h, angle]

Tambien en algun momento tendre que unir varias naves en el mismo archivo, por aquello de no tener un monton de archivos abiertos, en memoria, a la vez. Esto puede hacerse añadiendo un parametro mas a el array que contiene la informacion de los sprites... y por ahora me parece una buena solucion...

Pero bueno, lo proximo es hacer *.shp para todos.

Lo siguiente, espero que sea introducir el tema de las explosiones por fin (asi me lo quito) que no tiene pq ser trivial, sobre todo teniendo en cuenta que debe dar salida a todo el tema de objetos no interactuables (con los que no se puede colisionar)... es mas, tal vez empieze haciendo un fondo (con la imagen que tengo de la estrella de la muerte) que se mueva lentamente..... mmmm

Bueno, por hoy vale.

PD: No se ve bien, esta el x-wing girando hacia la izquierda en el extremo izquiedo con su rectangulo detector de choques redimensionado.

Pequeñas cosillas

Hoy ha tocado afianzar cosillas:

He arreglado el fondo. Ahora coge cualquier imagen y va haciendo tiles dinamicamente con ella segun el numero de cortes que le quiera dar en X y en Y. Luego llama a un metodo -si es menester- para que haga un ciclo con la imagen. Este ya esta, aunque supongo que hare otro(s) para hacer fondos que no ocupen toda la pantalla, tipo estrellas, planetas, estrellas de la muerte... pienso que lo mas comodo sera hacer uno (o varios, por si quiero sobreimpresionar fondos que se muevan a diferente velocidad y crear sensacion asi de profundidad) y tratarlos como a los containers de naves (aunque sin buscar colisiones). Dibujados en el orden correcto tiene que ir bien...

Ademas he hecho que el programita que se ejecutaba aparte y que me daba las coordenadas y las medidas de los rectangulos que envuelven a los frames escriba sus resultados a un archivo (tal vez a un archivo por nave sea lo correcto, ya vere) y un metodo en utils que lo lee y lo carga en una lista. He guardado los datos en bytes, de modo que vaya poniendo todos los datos consistentes en tipo para cuando vayan por internet (imagino que no habra mucha diferencia entre mandar bytes a un archivo y a un ordenador remoto).

Por ultimo he convertido en privadas algunas propiedades de SpritezatedImage (que nombre mas horrible) con el consabido '__' de modo que pueda controlar el acceso desde fuera, vienen a ser las propiedades que indican el numero de sprites en y y x, la anchura y altura del frame (hasta ahora era constante y a partir de ahora sera un valor de un array) y las coordenadas y y x del frame dentro de la imagen con todos los frames.

Mañana, a parte de terminar el asunto de que se cojan las imagenes y sus rectangulos contenedores debiera pensar otro metodo para hacer el efecto de que las naves 'se tumben' ya que recibir todas las coordenadas de cada objeto en un array unidimensional y tratarlo como bidimensional... no se... ademas en mapas de frames que he obtenido por internet pareciera que utilizaran mucho mas la horizontal que yo... tengo que mirarlo....

PD: Ah! ademas he puesto un log por pantalla que me da los arrays que se dibujan y que definen a cada objeto que se dibuja:

Avantti ma non troppo

Llevo varios dias sin actualizar esto asi que tratare de ponerme al dia en orden cronologico:

Puse un fondo al matamarcianos el sabado, compuesto de un monton de sprites cuadrangulares que se pintaban todos e incluso escrolaban verticalmente...

El rendimiento cayo un monton, a estas alturas no deberia preocuparme de esto, pero bajo de unos 350fps de media a unos 50-60... Horrible... De modo que me plantee seriamente el tema de usar OpenGL desde ya, finalmente mejore el codigo y lo deje en sobre 80fps y me tranquilice...

Aun asi me decidi a terminar el motor.

Hoy lo he terminado y esta funcionando. Se le pasan:
[indice_de_imagen_convertida_en_un_array, x, y, coord_x_del_frame_a_pintar_en_la_imagen_de_frames, coord_y_del_frame_a_pintar_en_la_imagen_de_frames, angulo_a_rotar_la_imagen]

Es decir 6 enteros. El fondo lo dibuja tambien el motor pero en otro metodo independiente pendiente de terminar -no considero necesario pasar todos los datos de el fondo por internet ya que es una parte 'pasiva' y ademas cuando este la parte de internet disponible se podra pintar el fondo mientras se obtienen datos- y funciona todo en el mismo proceso (para jugar en red habra que implementar un proceso paralelo pero para jugar en local no es necesario).

Ademas ya empiezo a tener frames de xwings, awings, tie-figthers y tie-bombers, en cuanto vaya teniendolos bien los subo.

Voy a empezar a poner capturas de pantalla para que se vea como va cambiando... Pero eso mañana, me voy a ver flash-forward

Sprites

De vuelta con los sprites en la cabeza....

Y cuando me refiero a sprites me refiero a todos los frames que forman una animacion... y no a la imagen actual dentro de esa secuencia y sus coordenadas en la superficie... Reitero, menos mal que esto es solo para mi....

Me he dado cuenta que poner todos -o al menos muchos- de esos frames en cada imagen puede estar bien, claro que como pueden tener diferentes tamaños habra que cambiar un poco el codigo para que tome las coordenadas x,y del vertice superior izquierdo y as xf, yf del vertice inferior derecho (o sus altura/anchura, vaya), y no solo eso, lo peor: habra que sacar las coordenadas de cada frame a manija lo cual puede ser una autentica tortura....

Asi que esta tarde me he dedicado a hacer un scriptcillo que encuentre todas esas coordenadas por mi y me los deje por ahi en algun archivo como datos que pueda coger directamente el pograma.

Aun tiene sus limitaciones: Hay que separar las filas de frames con una linea de distinto color que el fondo y no me escribe datos a archivos... solo hace esto:








:)

Esta eliminado el color de fondo (magenta) y hardcodeado otro para q sea como en el juego, luego se pintan encima los rectangulos que he conseguido.

Los he conseguido haciendo una matriz de colores RGB con la imagen y recorriendola en X e Y en busca de no-magentas y no-verdes....

Este codigo lo tengo que subir pq la verdad es que me parece util...

No prolijo

Se acabaron los dias prolijos, llega la oscuridad, el miedo y las dudas...

Me he apuntado a la UNED, y una de las asignaturas que he cogido para este año versa sobre OpenGL, que esta muy bien, claro, pero pygame utiliza SDL, habia otra libreria (pyglt) que usa OpenGL pero me decidi por pygame por que siendo una aplicacion en 2D tenia la impresion de que iba a sobrar (y es una libreria mucho mas madura que pyglt). En fin, que tal vez algun dia haya que cambiar...
Solo se importa pygame desde 2 archivos, el main y el de images, en un futuro no se deberia usar desde el main pero todo se andara pq el de images se va a dividir en varios rapidamente... He pensado en hacer un wrapper de pygame pero en python he leido que no se deben meter capas alegremente si quieres rendimiento (no es que a estas alturas me importe el rendimiento como para cambiar nada, pero si como para no hacer cosas que lo penalicen)

He aprovechado para mover un par de cosas de sitio que me estorbaban y para meter comentarios.

Y hacer los papeles de la convalidacion de asignaturas de la UNED, claro.

Dudas que me han surgido: Basicamente los sprites;

-No se si rotarlos programaticamente (coger una imagen y hacerla un rotate(radians)) o coger imagenes fijas de los sprites con diferentes angulos....
-No se como colocarlos: todos en un gigantesco 'mapa de sprites' como se bajan usualmente de internet y solo abrir un archivo o divididos por 'nave'? La primera solucion parece optima, pero como hacer para recorrer el mapa si los rectangulos que ocupa cada imagen son de diferentes tamaños? Evidentemente se me ocurre como, pero no Como.
-No se (y esta muy relacionado con lo anterior) si meter todos los sprites del mismo tamaño y mover un rectangulo de imagen en imagen para simular movimiento o meter las imagenes Y los anchos el rectangulo que contiene la imagen del elemento en cada posicion... menos mal que esto solo lo leo yo... por el gran FSM.....

Cambiando sprites

Bueno, hoy tambien ha sido un dia prolijo:

Primero de todo y lo mas importante: ya tengo SVN. Estaba gestionando el historial de codigos a mano y realmente... apesta... Ahora tengo 6 .zips y 3 versiones en el repo :) Eso si, el repo esta en LOCAL, asi que no podre hacerlo publico mientras no pueda ponerlo en mi servidor (cosa para la cual, repentinamente, he perdido todo tipo de prisa). en fin...

He conseguido tambien un sprite a partir de modificar para ordenar segun mi conveniencia unos de: http://www.gamedev.net/community/forums/topic.asp?topic_id=495808 son de un tal 'Prinz Eugn' (son los de aqui al lado) y son libres, el tio solo quiere que le digan si lo utilizas y que le metas en los creditos... No lo voy a usar mas que a modo de pruebas pero he de reconocer que el tio es un artista del copon. Yo me he encabezonado y he hecho 2 sprites mas para la rotacion (eran 3) queda convincente... Es una lastima que me haya encabezonado con starwars... Estoy por mandarle un mail: Guy! I need a star-wars-ships sprites!

En lo que se refiere al juego: he conseguido separar la parte que calcula la posicion del sprite de la parte que calcula el sprite que debe dibujarse de todos los de la imagen y me ha quedado convincente. Lo he hecho como una superclase controlando el sprite a dibujar que es extendida por otra clase que calcula la posicion del Sprite.

He creado ademas una nueva clase 'SpriteStatus' que es uno de las propiedades de SpritezatedImage (nombre horrible que ha de cambiar) y que siguiendo el patron 'strategy' cambia el modo de recorrer la fila de sprites. De momento hay uno para el 'no hacer nada' y otro para el 'girar' (a izquierda o derecha solo depende del valor de Y). A priori parece bastante escalable... y lo peor es que funciona bastante bien, el avion ya gira a la derecha cuando va a la derecha y a la izquierda cuando va a la izquierda... :) Creo que lo he hecho de una manera bastante precaria y que voy a tener que mejorarla mañana o asi... pero por hoy vale.

Noto una necesidad IMPERIOSA de sprites de star wars....

Cambios varios -YA MATO!-

Hoy he hecho varios cambios:

Por fin he aislado completamente el render del draw en el defaultSprite, no tenia mucha enjundia pero había que hacerlo.

He creado mi propio sistema de colisionado, aun es muy básico, solo obtiene un choque rectangular bastante tosco -pero que queda sorprendentemente bien, aun así- para el futuro quedara, en caso de que lo vea necesario -que insisto que por ahora me convence- hacer subrenctángulos dentro de la imagen que contengan a la figura y que le den mas precisión. Definitivamente creo que voy a poder prescindir de la clase pygame.Sprite ya que el remove() que yo creía que automáticamente eliminaba el sprite de todos los grupos es bastante cutre... (hay que pasarle los grupos en los que puede estar)

Ya que he encauzado el tema de las colisiones que menos que probarlo... he implementado vida a las balas y a las naves y ya mueren... Esta bastante bien y es un punto muy propicio para hacer otro alto en el camino y ver que el codigo este quedando BIEN, así que supongo que lo próximo que tocare sera eliminar pygame.Sprite de mi programa.

Sprites, quiero sprites.... Procedo a reinstalar el Alliance y a sacar alguno...

El motor ha quedado enfilado pero aun no quiero meterlo pq se que me voy a liar con eso innecesariamente, primero que sea usable, luego ya funcionara en red...

Engine

Ahora me he puesto a hacer una nueva clase que contenga las imagenes y los rectangulos que se van a dibujar... Vale, eso se llama sprite, pero no acabo de ver que tenga que controlar las colisiones tambien... en pygame originalmente no se hacia en la clase sprite y seguramente si han evolucionado a ese modelo es por algo... pero ahora mismo a mi no me convence tal y como esta en mi juego....

Ademas tengo pensado que las imagenes tengan distintas filas de sprites para distintos estados, por ejemplo 3 para que si no se pulsa ningun boton el motor de la nave saque fuego moviendosse, 3 de la nave con distinta inclinacion a la derecha, 3 a la izquierda, 3 para la explosion.... introducire en esa clase la logica de cambio de fila y comportamiento (por ejemplo en la explosion, que despues de dibujar todos sus sprites ese objeto no tiene que volver a dibujarse...) a la hora de recorrerla en la nueva clase.

Funciona bien por ahora, tiene las imagenes, el numero de sprites en los que se divide la imagen en X, lo mismo en Y, el ancho y el alto de cada sprite... desafortunadamente por ahora los sprites solo avanzan en X

Ahora tengo que cambiar las imagenes por indexes de imagenes para allanar el camino de lo siguiente que tengo en mente:

Proximo TODO: Un motor

Se trata de un objeto al que se le pasan una serie de cosas que hay que dibujar a una cola y el las dibuja...

Tiene sus cosas buenas y sus cosas malas, a saber:

-Podre hacer que se pueda utilizar en red, con solo poner un protocolo que me mande objetos como los que interpreta el motor, lo cual puede parecer absurdo en un matamarcianos pero quien sabe, igual queda bien.

-Me van a sobrar bastantes cosas de pygame.sprite (por esto he dicho que no me convencia), al motor NO pueden llegar sprites ya que estos contienen una imagen (o una referencia a una imagen, vaya) y un rectangulo... y esas cosas ocupan mucho, o al menos no se cual es su tamaño, como para mandarlas por internet... tendre que hacer mis propias 'referencias' de imagenes en una lista interna con todas las imagenes y pasarle esta referencia, las coordenadas y las coordenadas del sprite a dibujar dentro de la imagen. 5 enteros, 2 + 2 + 1 + 1 + 2 bytes.

Esta hecho pero no probado, mañana le doy cera, solo hay que cambiar el draw the el DefaultSprite, el resto cambiado y funciona.

Haciendo un matamarcianos

Pues si.

Me ha dado por hacer un matamarcianos, y he decidido hacer un registro de todo lo que voy haciendo, todos los problemas que voy encontrando, todas las cosas que se me van ocurriendo, etecetera....

Vamos a comenzar con lo que uso:

He utilizado hasta ahora el mejor editor del mundo: VIm, pero a la hora de tener muchos archivos abiertos del mismo projecto no me acaba de convencer... Tengo que mandar un email a Jon a ver si me da alguna pista para lidiar ese problema.... Ahora uso eclipse con pydev, la libreria pygame y python 2.6. Tengo que poner subversion en mi servidor y algun dia, cuando consiga pasar el maldito router, hare publico.

Voy a probar algo llamado easyeclipse que parece ser que viene con todo lo que necesito... solo por probar....

En fin, el codigo:

Se compone de varios modulos, que a grandes rasgos son:

sprites: Tiene una extension de pygame.sprite (en python no hay interfaces) que actualmente se ocupa de renderizar y dibujar el sprite de la imagen que queremos.

ships: extienden a LivingObject, que es un objeto con una cierta velocidad, vida, y un numero maximo de disparos (una nave, actualmente). Hay diversos subtipos como son: PlayerShip, EnemyShip....

shots: son los distintos tipos de disparos... Actualmente solo hay un sprite.... pero esto cambiara

strategies: son las estrategias que van a usar los shots para causar destrozo, pueden seguir en linea recta, recalcular su velocidad para dirigirse a su objetivo....

images: la imagenes que se usan en los distintos sprites, como van a ser comunes tengo pensado ponerlas aparte de modo que pueda incluir en ellas la logica de calculo del sprite, no suena bien, lo se, pero me tengo que convencer de que no esta bien

main: tiene el bucle principal

Cosas curiosas:

NO puedo usar los cursores y el espacio por que interfieren entre ellas... tiene algo que ver con el metodo de fabricacion del teclado (literalmente con el diseño de este), de modo que se dispara con la x