MAC problems in ubuntu; changes on each reboot

I'd a problem with ubuntu and my ethernet card:

It changes the MAC in each reboot, so when I did a WOL the MAC changes for another (randomly defined) and I had to reconfigure the client in each reboot...

It also had done another problem that solved here: MAC changed so ubuntu didn't recognize the ethernet card and created a new entry for it in 70-persistent-net-rules creating new sequentialy eth1, eth2, eth3, eth4... in each reboot. I said in a previous post how to avoid that sequence but this is a better way:
The problem appears to be that the kernel didn't recognize the ethernet adapter manufacturer (that have it's own code: the first 3 numbers of the MAC) and changed it for another randomly choiced number (so in each reboot you have a random new MAC).
 A bug -I think- in a driver called forcedeth:

There is too the MAC address

Download macchanger (it can be do too using ifconfig) via:



Or apptitude, or synaptic....

Make a file using it and wiving it a MAC number of your choice nd your ethernet name (mine is eth0, find it typing 'ifconfig' in console):




Save it. Copy it to /etc/init.d (you must be root, so do it graphically 'sudo nautilus' in console, to do in console go to file's directory and type 'sudo mv ./(filename) /etc/init.d/' without ' and changing (filename)  with you file name)

Change file  owner via file properties in nautilus or

sudo chown root:root (filename)

And make it executable via properties (giving it permissions of execution and read for all) or via console:


sudo chmod 755 (filename)

After this put it in your startup sequence:

sudo update-rc.d -f (filename) defaults 21

The 21 its the position in the startup sequence, this is important: i've tried 20 and didn't works and 80 and it worked to change the MAC but not for WOL.

This way you always will have the same MAC on your PC on startup.

Good luck

Wake On Lan

I've thought that as a way to improve my English I can write in English and tell to my brother to check it.... so you know... im sorry about my poor English.

Ubuntu tematic post:

Today i've enabled WOL on my server, to put it On remotely across internet (stop a PC is to type 'sudo halt' in a remote console, but to start it WOL is needed) -so it should stop being a public server an I could start it when I want to down/up load something in it via FTP or do whatever I've to do via ssh or VNC (yes, i'll put VNC too) -

Well... usually that's not a hard operation, you only have to enable the WOL in your server's BIOS -look in your motherboard's manual to see how to do it, changes between companies-, then tell your PC to ear to WOL. To do this, in ubuntu (to say your PC to wait for WOL signals) you must use ethtools. It's a program that isn't by default in ubuntu but is in repos, so you can instal it writing:


sudo apt-get install ethtools

Or using synaptic or apptitude or whatever you use. You have to run this command every time you start your computer:

sudo ethtool -s wol g

To know whats your ethernet name type 'ifconfig' in a console (whitout the '), press enter and it will say somethin like this:

eth0      Link encap:Ethernet  direcciónHW 00:12:34:56:78:90 
          Direc. inet:192.168.1.2  Difus.:192.168.1.255  Másc:255.255.255.0
          Dirección in... (a lot of stuff more)

So, in my case the command will be:

sudo ethtool -s eth0 wol g

This way you say to ubuntu to change (-s) your eth connection (, in my case is eth0) to WOL (wol) on 'Magic packet' (it's easy to do it by sending a special created UDP packet).

But wait, typing that command on every reboot is annoying... better to automatize it...

To do this you must make a new text file with this text inside:
#!/bin/bash
ethtool -s eth0 wol g
exit

Save it. Copy it to /etc/init.d (you must be root, so do it graphically 'sudo nautilus' in console, to do in console go to file's directory and type 'sudo mv ./(filename) /etc/init.d/' without ' and changing (filename)  with you file name)

Change file  owner via file properties in nautilus or

sudo chown root:root (filename)

And make it executable via properties (giving it permissions of execution and read for all) or via console:


sudo chmod 755 (filename)

After this put it in your startup sequence:

sudo update-rc.d -f (filename) defaults 80

80 means 'at the end of secuence' (the end is in 99). Really, we haven't any hurry to run it when start, we only have to run it always...

This way the computer should be ready to WOL, now we only have to configure a client (android client in my case) and the router (I asume you have done it before to configure 'amule', we have to redirect one port, whatever you want, to the WOL port -9 by default- of your PC)

In client side you need only this info: your stopped PC's IP, and MAC address. To get your MAC, like previously, type 'ifconfig' and :


eth0      Link encap:Ethernet  direcciónHW 00:12:34:56:78:90 
          Direc. inet:192.168.1.2  Difus.:192.168.1.255  Másc:255.255.255.0

In my case my MAC number is 00:12:34:56:78:90

At this point: I've had problem because my MAC changed on each reboot but I've solve it in a nice way :) It was an old 'solved' problem and it have a new solution. I have a post down here to explain how I've solve it.

I've use this application for android, pretty simple and clean, I like it  (this is its page with instructions to WOL in windows), but they are applications for all operating systems (I promisse that I'll do one, it appears to be easy to do one and a good starting point to android and UDP programing).

Name is for you to identify the PC to wake up.
MAC: the mac address
IP or Domain: PC's IP or domain (your external IP or your DynDNS domain are valids)
Port: The port you hace redirected or the PC's port to WOL (default 9)

Giving this information to it the client should be working.

Good luck

PS: I've find the main info to do the WOL in ubuntuforums in this thread

Paso atras, paso adelante...

Bueno, ahora si que vuelvo:

He rehecho el menu. De nuevo. Ocurrio que me daba problemas el anterior al concatenar varios submenus con los eventos del raton, que no los habia tenido en cuenta de un principio.

Ahora ha quedado bastante mejor todo, mucho mas pq he eliminado ciertos detalles de fealdad que me torturaban el subconsciente. Ya todos los miembros de menus son de tipo item y tienen sus propios metodos onKeyDown, onMouseIn, out, over.... Y los que hagan falta, vamos.

Ya controla eventos de mouse :)

Ha quedado, de nuevo, bastante bonito y funciona mucho mas claro. Esto solo es la base de lo que sera el menu (evidentemente habra que ponerlo bonito) pero al menos estructuralmente 'ya esta' (por que entrecomillo esto? por la separacion entre el 'quit' y el 'options', busque que ocurriera eso pq me parecia molon, de hecho se separan solo cuando se muestra el submenu y lo hacen a una velocidad variable que depende de el valor de un parametro y si quiero que no se separen, como los menus de toda la vida, tendria que cambiar los eventos del raton, por ahora se queda asi, igual si algun dia me aburro...).

Ahora debo rehacer el item que genera la conexion como antes (esto es, hacer un item 'textArea' con autoscroll para logear la conexion, que se conecte y que ceda el control al juego)

Sigo, aunque no escriba

Bueno, he hecho alguna cosa digna de mencion:

Estoy haciendo un interfaz para empezar el juego bastante mas digno que el que habia (lo he rehecho entero). Los problemas que me ha dado son que al poder mostrar menus y submenus aparte de que el evento 'pulsar Enter' sea comun para todos los elementos de cada menu han hecho que haya que tener un control de que control esta activo en la estructura... Ha quedado bastante limpio. Ademas puedo destacar el item seleccionado con una imagen o incluso una animacion facilmente ademas de cambiar su tamaño o mostrarlo u ocultarlo...

En la imagen adjunta muestro un menu en el que solamente pinto elementos y un recuadro gris detras. He hecho pruebas de cambiar el tamaño del rectangulo, cambiarlo por una imagen, que se desplace suavemente entre las posibles selecciones, que se desplace discretamente (a saltos: uno en cada linea), que un item despliege un submenu aumentando lentamente su tamaño hasta mostrarlo... y la verdad es que ha quedado bastante coherente todo y cambiar el comportamiento es bastante facil.

Ademas he cambiado la logica de crear la conexion y obtener la ID de cliente a este menu (lo hace un elemento que tiene una especie de 'caja de texto' que he hecho yo, tambien), en principio no parece buena idea pero trato de evitar en python el multithreading... En el cliente no ocurrira. Pero bueno, el menu bastante bien, me esta gustando.


El objetivo actual es 'acabar la partida decentemente' esto es: que cando muera un jugador el resto sigan jugando y el vuelva al menu principal. Pero creo que me va a costar algo ya que no se que hacer: tiene que meter high score si ha puntuado lo suficientemente bien (y eso se lo tiene que decir el servidor), tiene que tener la posibilidad de continuar, tiene que ver la partida despues de muerto mientras decide si continuar... Y lo peor de todo, si decido que haya una persistencia de jugadores (sus puntos desbloqueen/mejoren cosas) como lo mezclo con todo lo anterior? como sumo su 'dinero' o lo que se utilice para comprar cosas? Como no tengo muy claro que quiero hacer con todo esto mantendre el tema por unos dias en barbecho mientras hago que el menu reciba eventos del raton y un GUI para el juego (barra de vida, puntuacion y tal, en plan medio basico)

Ademas hay otro punto negativo: en el curro empiezan a poner el aire acondicionado y salgo todas las tardes con la cabeza como un bombo...

Hoy....

Bueno....

El fin de semana probe con amaia a ver como funcionaba en local con 2 portatiles: aceptable, pero tenia mucho log (2 lineas por ciclo minimo en el servidor) y no iba del todo fluido (estoy cuasiconvencido de que era eso, no me di cuenta pq lo ejecute todo el rato en remoto y se me olvido quitarlo).

He dado algun retoque a lo de 'buscar enemigos a la vista'  para apuntar los cañones de la corellian corvette, pero me queda algun detallito, de mañana no pasa.

En fin, hoy tambien he hecho alguna otra cosa: he cambiado el contenedor de objetos vivos, ahora en vez de contener datos de las naves y balas enemigas (dos arrays) y las naves amigas y sus balas (cada nave con su array de balas, lo hice para saber a quien sumarle los puntos cuando una bala amiga mataba a una nave enemiga, pero llegue a la conclusion de que era mejor que cada bala supiera quien la ha disparado, de modo que ahora los contenedores de amigos y enemigos contienen los mismos datos: un array de naves y otro de balas). Ha bajado el numero de bucles...

Ha estado bien pq aunque no parecia un cambio baladi no me ha costado nada... la verdad es que creo que me esta quedando un codigo cada vez mas bonito.

Ademas ya he decidido por donde sacar las naves muertas del mapa: cuando una nave de un jugador muera escribira en su container su id_client y su puntuacion y el mapa se lo dara al motor. Ahora a ver que hace el motor con esos datos... :P

El viernes....

Hoy he cambiando algunas cosas de ayer pero no he podido probar NADA...

Lo de los containers... aun no lo he cambiado al container pero si lo he organizado mejor, me ha quedado en una funcion que practicamente pudiera ser estatica... El problema que veia a que la nave objetivo mas cercana la buscara el contenedor de objetos 'vivos' (enemigos y amigos) es que cada nave tendria que tener una referencia al contenedor amigo o enemigo en el que esta y al contenedor de objetos vivos...  Actualmente me basta con darle una referencia al contenedor de enemigos suyos y no me gusta nada la idea de darle esa referencia... como para aumentarlas....

Pero bueno, al menos ha quedado bastante mejor si esos 'magic numbers' ...

Lo de las torretas tambien esta sin probar y tambien ha sido muy limpio, me ha bastado con cambiar una linea en el metodo que obtiene los objetivos para toda nave o misil que necesite un objetivo....

Lo de la muerte del jugador no lo he tocado aunque lo he pensado bastante... todavia me ofrece muchas dudas....Tengo el problema de que las IDs de los clientes estan logadas a su posicion en el array de naves amigas y ese array cambia cuando muere una nave... creo que voy a hashear los ID's de las naves y punto, si en el futuero se me ocurre una formula mejor la metere....

No todo van a ser avances

Hoy he estado cambiando algunas cosas:

He vuelto a poner las naves enemigas y me he dado cuenta de que no habia cambiado el serializa de las naves compuestas (corellians, actualmente), lo he arreglado.

Ademas he visto un problema que va siendo hora de solucionar: la muerte del jugador. Hasta ahora, cuando moria el jugador se acababa el juego.... ahora cuando muere un jugador... tambien :P Tengo que hacer la 'logica de muerte', tengo que devolver al motor -la parte fuera de la logica del juego- que jugador ha muerto (con cosas como puntos y tal, ya vere), destruir (o dejar desaparecer, ya vere) sus laseres, dejar de mandarle datos (o no, ya vere)...

Y como tengo muchos 'ya vere's lo hare cuando lo tenga mas claro....

Ademas tengo que cambiar la mecanica de los containers de enemigos y jugadores... estoy pensando en darles mas funcionalidades (como por ejemplo que decidan ellos cual es el objetivo mas cercano a una nave del container contrario, actualmente es la nave la que decide q nave del container de naves contrarias esta mas cerca, es poco mas que un cambio de lugar de una funcion, pero eliminaria ciertos 'numero magicos' del codigo y me vendria bastante bien)...

Por ultimo quiero hacer que las torretas cambien de objetivo cuando se aleje el que tienen actualmente (o dejen de disparar). Esto lo hare estableciendo un cuadrado maximo de alcance alrededor de cada torreta (calcular si un punto esta dentro de un cuadrado es comparar Xmax > x > Xmin e Ymax > y > Y) si no lo esta se busca algun objetivo en rango, si no lo hay se pone 0 y se espera al siguiente loop, si hay alguno se hace lo que se hacia antes comprobando previamente, en cada loop, que esta dentro. Esto esta encauzado pero aun no es funcional...

Multicontinuando

Hoy he seguido con el tema del multiplayer:

He 'arreglado' lo de ayer, ahora las pantallas se mueven de una manera completamente independiente. Para ello he utilizado medio byte que tenia libre de los 9 que se utilizan para pasar la informacion de cada objeto a dibujar: me manda una 'id de jugador' que el cliente usa para identificar si la nave que esta dibujando es la correspondiente al jugador que esta usando ese cliente. Todos los enemigos tinen ID_CLIENT=15, de modo que solo podran jugar, por ahora, 14 jugadores simultaneamente (aunque es facilmente ampliable). Si la imagen corresponde al jugador del cliente adecua las coordenadas de la pantalla del clieente sobre el 'mundo'. Se me ocurre que esto no es demasiado complicado de ampliar a que 2 jugadores puedan usar el mismo cliente (una pantalla, 2 naves ligadas como ayer, 2 personas jugado con el mismo teclado, se me ocurre que bastaria con compartir ID_CLIENT) pero por ahora no es la idea...

Ademas he cambiado un poco el codigo: he metido bastante mierda con esto de el online y el multiplayer y he limpiado un poco. He hecho un metodo 'syncronizing' en cliente y otro en servidor para que hagan todo lo que tengan que hacer antes de empezar la partida (ahora mismo se esperan y el servidor distribuye los 'id de jugador', en el futuro tendrian que hablar sobre el tamaño de la pantalla, pero si al servidor no le importa el tamaño de la pantalla del cliente!!! diria uno, pues si que le importa)

Por ultimo (y por esto le importa) he hecho un analogo a lo que hacia antes de 'dibujar solo lo que esta a la vista del jugador' -me insinuo Gustavo, uno del curro- pero para todos los jugadores y en vez de 'dibujar' ahora solo se serializan los objetos que son visibles por algun jugador... por ahora solo lo he probado con laseres y diciendo, para ver que funciona, que desaparezcan los objetos que esten mas haya de la mitad de la pantalla (en ancho y en largo) a partir de cada jugador, me explico: solo s dibujan los objetos que esten a una distancia menor que ancho_de_pantalla/4 a lo ancho y alto_de_pantalla/4 de algun jugador. Es entre 4 para que a uno y otro lado sumen 1/2 y vea como desaparecen los laseres a una distancia de 1/2 del tamaño de la pantalla de la nave que disparo....

Eso provoca el efecto de la imagen: los laseres dejan de aparecer cuando se alejan 1/2 pantalla del que dispara y aparecen a 1/2 pantalla del que esta arriba (en la pantalla de la izquierda ese espacio que aparece sin laseres). De modo que parece que el 'horizonte' a serializar debera ser las coordenadas de la nave de cada jugador  + y - el alto/ancho de la pantalla excepto para naves que sean mas grandes que la pantalla.... ya vere como las trato.... La idea de hacer esto es reducir el tamaño de los paquetes que mando por internet.


Pero bueno, contento.

Ademas he descubierto que otro del curro igual consigo que me eche una manica (ahora se va a londres, cuando vuelva le dire) y ademas estoy haciendo unas pruebas con el android app inventor... no me llama mucho (programar asi es un coñazo) pero bueno, me hare todos los ejemplos que tienen a ver si le cojo el gustillo....

Empezando el multiplayer

Una vez hecho que el tema del juego en red funcionara con una cierta estabilidad -aunque queda tela que cortar- ahora llega el momento del multiplayer (TCP, claro).

Ha sido bastante facil, un problema de referencias -imposible de ver sin el debugger- y ya esta.... mas o menos. Por ahora ambas naves estan encerradas en la misma pantalla (se tienen que mover juntas). Lo solucionare introduciendo en los 9 bytes de info que se mandan para dibujar cada imagen la informacion del jugador al que se refiere cada imagen de nave aliada -creo recordar que tenia bits libres aun-.

De todos modos la idea de que se pinten ambas naves 'encerradas' en la misma pantalla me gusta, puedo usarlo para multiplayer en una misma maquina (con diferentes controles, bien en local o bien en una partida mas grande). En fin, me ha gustado este error. :)

Mas cambios en el on-line:

He arreglado un poco el tema de las conexiones cliente-servidor.

He hecho una clase para envolver las conexiones de las que nos provee python (la clase socket) de modo que se puede usar para cliente y para servidor indistintamente. Sigue siendo TCP pero ya no abro dos puertos, ya solamente se escucha en el 4444 del servidor (si, era bastante absurdo usar mas de uno, es que lo hice rapido pq la idea es que empezara a funcionar el intercambio de informacion en forma de bytes y comprimiendo los paquetes a mano).

He alojado la clase en un nuevo paquete (sockets) ya que ha de estar disponible para ambas engines (la del cliente, que solo dibuja y la del servidor, que es la que piensa) y ademas en un futuro habra que cambiala para que use UDP y multicast... Pero por el momento que funcione en TCP...

Esa clase, tambien, esta preparada para manejar varios clientes simultaneamente (al menos para probar, aunque no se si aguantara en TCP mucho mas de 2 clientes diferentes...) De modo que podre empezar a desarrollar el multiplayer...

Creo que directamente empezare a usar el servidor de bienvenida que tengo hecho en java para esperar conexiones externas y asignar jugadores a un juego cuando haya el numero deseado pq esa es una funcion que voy a tener que implementar si o si. Tambien tendre que hacer un modo 'daemon' para este servidor, para que funcione sin entorno grafico y no me moleste al lanzarlo en remoto.

Ademas he traducido a java un poco de la clase que obtiene las coordenadas de todas las imagenes de un dibujo... A ver si lo termino pq creo que va a ser lo mas complicado de hacer del cliente...

Actualizando el modo online (continuacion del anterior post)

Siguiendo con el texto del post anterior, ete se situa temporalmente un par de dias despues:

Creo que tal vez es demasiado el centrarme ahora en hacer un cliente en java ya que el servidor (la logica) tiene que ser ampliada para que el juego sea realmente jugable (necesito mas naves, mas armas, que las armas puedan evolucionar, mejorar la comunicacion con el jugador, hacer el multiplayer...)

De modo que empiezo por lo facil: un missil que busque a su objetivo (ya tenia algo parecido hecho antes, pero ahora sera una segunda arma del jugador y el codigo ha cambiado bastante). El misil cambiara su direccion un maximo de X cada cierto numero de ciclos N, esto es: cada N' decimas de segundo recalculara su direccion para alcanzar a su objetivo y la modificara a lo sumo en X grados. En el caso de un misil lanzado por el jugador tal vez no ponga limite a los grados ya que de ese modo el misil sera implacable.... o tal vez mejore X segun se suba de nivel... mmmm que buenas ideas tengo mientras escribo.

Ademas he introducido ciertas mejoras en el servidor del juego:

Necesito cargar la libreria grafica para usar el motor aunque este no tenga que dibujar nada!!!

Es un 'fallo de diseño', mas bien un TODO... El asunto es que despues de coger las imagenes del archivo de imagenes de cada nave, se calculan diversas mascaras para cada imagen y ademas se guardan copias de las imagenes rotadas para no tener que rotarlas en tiempo de ejecucion (al final el tiempo de carga del juego es irrelevante aun), de esas rotaciones obtengo el ancho y el alto (que son cosas que cambian como se ve en la foto adjunta) y las utilizo, en la logica del juego, para detectar las colisiones. En el futuro podria guardar estas coordenadas en algun archivo externo y leerlas de nuevo para que el servidor sea completamente independiente de la ligreria grafica (pygame en python).

Al probarlo en casa de amaia, al cargar la libreria grafica en el servidor (que estaba en mi casa) se abria una ventana que tenia que redirigir por ssh (con el modificador -X) a el ordenador donde estaba el cliente (amaia-enea) y parece ser que mandaba refrescos de pantalla por el ssh y aquello no iba...

Actualmente se carga la libreria antes de cargar las animaciones y se descarga justo despues, cerrandose la pantalla, debiera funcionar.

El cliente:

He cambiado varias cosas:

Ahora actualiza la posicionde lo que se muestra por pantalla en el universo (hace que al llegar la nave del jugador a un borde en vez de pararse hace que todo se desplace en el sentido contrario)

Salian 'parpadeos' en la pantalla, para corregirlos he tomado una medida en el motor del cliente:

Se dibuja por doble buffer: una pantalla se esta mostrando mientras se va construyendo otra por detras: primero se pinta entera del color del fondo y luego se van poniendo los diversos objetos y al acabar se intercambian: la que se muestra pasa al inframundo y la que se estaba construyendo pasa a ser la mostrada. Todo muchas veces por segundo (ciclos). Ahora lo que hago es no ejecutar el ciclo de dibujado si no hay nada que pintar (ya que me intercambia la pantalla principal con una que esta en el color de fondo, lo que significa que todo parpadee)

Empezando con el servidor

Bueno, en este impass temporal en el que he estado en basauri el puente tambien he avanzado en algunos sentidos, como no he actualizado esto lo pondre en diferentes posts (los textos estaban escritos pero no subidos):

He hecho un servidor y un cliente funcionales en LAN en python. Funcionales en el sentido de que funcionan, aunque son bastante basicos.

Para ello he cambiado el formato de los paquetes que se enviaban para pintar (enteros que decian indices de la imagen a dibujar y donde -x,y- habia que pintarlas) a una suerte de compactacion de 9 bits que se escriben en un string byte a byte.

Ademas he creado un main para el cliente y un main para el servidor y lo mismo con el engine ya que el servidor no dibuja nada en pantalla, solo manda y el cliente no calcula nada, solo lee lo que le manda el servidor y pinta .

He utilizado 2 puertos, el 4444 para leer y el 4445 para escribir... pq 2 y no solo uno? pq lo ice rapido y sin pensar, de todos modos la idea es separarlo del codigo ya que por ahora son TCP y tal vez acaben en UDP (con lo que habria que crear un protocolo propio para tratar lo que UDP no trata y TCP si, a la sazon el control de errores y el orden, pero se obtendria la ventaja de no reenviar paquetes perdidos: lo que se pierde se deshecha y punto).

Hay un problema con el tema de que se mueva el mundo cuando la nave llega a el limite de la pantalla. Se debe a que era la clase 'ship' la que lo modificaba originariamente dependiendo de su posicion (parecia un buen sitio ya que ella era la que mantenia la informacion de su posicion y la modificaba)... Para solucionarlo pasare esa logica al cliente, de ese modo cada cliente sabra que partes de el mundo quiere mostrar y cuales no.

Hecho esto, y contento conmigo mismo, creo en el repositorio un sitio para un cliente en java (basicamente una traduccion del de python) y comienzo a dar las primeras pinceladas. Me doy cuenta de ciertas ventajas de java respecto a python: la programacion orientada a objetos es mas clara -no asi el codigo, claro-.

London calling...

Welcome back!!

He estado unos dias en Londres por aquello de tener vacaciones. Todo muy chulo. Le deberia dedicar un post... pero no sera este...

Por dicha ausencia no he hecho mucho ultimamente, aunque si que lo que he hecho es bastante ambicioso: quiero hacer ya clientes y por tanto lo primero que tengo que hacer es un servidor de logica en condiciones.

Lo primero que quiero hacer es un cliente en python -a partir del codigo existente- que se conecte al servvidor en el que se desarrollara el juego y que solo se dedique a dibujar la pantalla.

En principio sera muy basico: el servidor se pondra a correr en un puerto esperando un cliente y cuando se le conecte uno empezara el juego.

Empece a hacerlo pero va a ser largo, pq por ejemplo hay que transformar las listas de numeros que ahora se pasan a la engine para que las dibuje (que contienen, basicamente, el indice de el dibujo que hay que hacer y las coordenadas donde debe dibujarse) a arrays de bytes que se escriban hacia los clientes y que estos los desempaqueten y los dibujen (pero recibiran bytes y no listas). Basicamente quiero que funcione todo igual pero lanzando 2 procesos en vez de uno... Luego ya me ocupare de el multijugador y de que haya un programa que gestione las partidas...

Tambien tengo que decidir entre UDP y TCP... No lo tengo muy claro, ambos tienen sus ventajas y sus inconvenientes... esto del principio lo hare en TCP -mas sencillo- y ire cabilando mientras que es lo mas conveniente.

En fin, esta bien cambiar de lo que era la logica del juego... Ademas cuantas mas partes toque mas claro tendre todos los aspectos del juego...

PD: flipo con la cantidad de yankis que entran a ver esto... tal vez debiera start to write in pseudo-english... I'll try... by the way the comments on the game are in pseudo-english...

Piano

He decidido que lo siguiente, para que empiece a tener un poco de sentido, sea hacer un tanteador y un entorno grafico -unas pantallitas q te digan que pulses lo que sea para jugar y lo que sea para ir a otra pantalla-....

Sigo sin arreglar lo de la imagenes pero es que necesito descansar de la parte de logica... de modo que ahora que la GUI tiene forma (evidentemente no tiene ni dibujos ni ningun tipo de letra especial, es bastante arcaico pero tiene forma) hare un 'top scores' y luego tratare de seguir con el multiplayer.

De ese modo podre empezar a mirar tambien los clientes en Java y Android....

JARRAITZEN

Bueno, acabados examenes he hecho un poquillo mas:

He sacado las explosiones de las naves-shots. Ahora son objetos aparte que forman parte de las propiedades de cada movil y son dibujadas por el container de cosas que no interactuan en el juego.

De modo que ahora ese container tendra que tener varios listados: al menos uno para las explosiones, que son lo ultimo que se dibuja (capa mas superior) y otra para las cosas que se muevan en el fondo.

Ademas he aprovechado para limpiar los sprites, ships y shots.

Vislumbro allende el horizonte un nuevo problema:

Deberan cambiar las imagenes en algun momento: meter todos las naves en la misma, por ejemplo... Lo cual igual tambien incluye cambiar el script que me coge el cuadrado minimo para optimizar el uso del espacio... hacer como un mapa... pero como aun no se como hacerlo no me preocupo...

TODOS

Tengo que estudiar, asi que apuntare aqui las cosas que se me van ocurriendo y que tengo que poner en lista de todo's:

1- Poner el tema de las explosiones aisladas en funcionamiento.
2- Hacer mas naves, el resto de TIEs y alguna mediana mas, para dar mas diversidad, asi como meter misiles y laseres verdes para los enemigos.
3- GUI para el juego.
4- Limpiar el codigo.
5- Separar, en las animaciones, las imagenes de sus propiedades si es posible. Esto es, para la logica solo se necesitan medidas y mascaras, no mapas de imagenes. Puede parecer que es una separacion demasiado tenue pero redunda en un cliente mas ligero.
6- Tengo un cliente generico de java. Hacer clientes.
7- He encontrado y deliciouseado una pagina en la que explican como mejorar el loop principal para no tener problemas con ecuaciones no lineales. Vale que no es mi caso ya que no contemplo aceleraciones, pero tal vez en el futuro, otro juego, si. Ademas, en esa pagina vienen algunas cositas para hacer los juegos en red, y tengo que decir, lleno de orgullo y satisfaccion, que ya habia pensado hacer todo lo que he leido para el sevidor y ademas por las razones que dan (basicamente UDP que es un protocolo mas propicio para streaming desde internet y un sistema de id's en los paquetes para desechar los que llegen tarde). Para el cliente, sin embargo, ponen un par de soluciones interesantes que analizare enel futuro.

Explota, explota me explo.

Bien, es facil, parece que ya me he aclarado con las explosiones:

Usare unas explosiones comunes a todos las naves excepto las rebeldes, de este modo todos los tie explotaran igual independientemente del angulo, las torretas idem... Los corvetes imagino que no...

He hecho una nimacion de prueba con una explosion y se la he metido a ties, el xwing y cañones para probar... a lo sucio... me gusta como queda, lo pondre bien en el codigo pero antes me pondre a estudiar pa setiembre, que ya es hora.

Y mas aun!

Bueno, ayer no escribi asi que voy a aprovechar para escribir como va:

1- He metido tie interceptors que van en la direccion de el xwing (solo se calcula la direccion al se creados) y van bien, disparan bien PERO hay un problem: las explosiones. Son secuencias de 5 frames o mas... merece la pena rotarlos 360 veces para todas las naves? para los corellian si, pero para los tie? como solucionarlo sino? no cambiar nada o hacer explosiones en las que no haya restos identificables? una explosion encima de la imagen? tratar las explosiones diferente al resto de animaciones? ya lo pensare.

2- Los cañones de los corellian ya muestran los reflejos por laser. Mola. Ha sido bastante sencillo. Mola. Eso quiere decir que la estructura es bastante estable.

Añado a la lista de TODO:

-Explosiones, definir.

Retiro:

-Reflejos al disparar

Por cierto: hoy cumplo años.

Inexactitudes

Bueno, parece que me es un poco complicado seguir las intenciones que me marco. Generalmente cuando me pongo a hacer algo y me doy cuenta de que tiene que ver con otra cosa me pongo a hacer esas dos cosas...

Que es lo que me ha ocurrido hoy, de las intenciones de ayer solamente he metido el codigo de la corveta de 90 grados (que se va a fusionar con la normal, me temo, aunque tengo mas cosas que pensar pq por ejemplo no se si tiene sentido tener todas las imagenes en memoria de la corvette rotando, tal vez me valga con 0, 90,180 y 270 grados... o tal vez de 30 en 30... tengo que pensarlo, pero en un rincipio parece que la corvette no va a rotar y que me sobran imagenes, tendre que no crearlas o eliminarlas).

El tema de las mascaras lo he empezado a hacer pero no lo entiendo muy bien... no me parece que sea demasiado eficiente ya que se hacen comparaciones bit a bit... si tenemos una mascara de bits, no seria mejor comparar de 16 en 16 o de 32 en 32? Aparte de que es bastante dependiente de la clase sprite de pygame y no queria depender mucho de pygame (aunque al final en la logica del juego me va a tardar en molestar).

Cosas que SI he hecho:

-He arreglado los problemas que tenia con los disparos (unos errores al dibujarlos). El error se debia a que por defecto se reseteaba a la animacion STAND y no se reseteaba el numero de frame, con lo cual los laseres que venian con angulo y se asignaban a tie interceptors petaban. Es un error bastante complicado de encontrar, he tenido suerte. Tambien he casteado los datos que me aparecian como floats en los paquetes de datos a int pq no tienen sentido los decimales cuando hablamos de pixeles.

-He hecho un universo mayor que la pantalla, ahora el xwing se desplaza por la pantalla y al llegar a cierta distancia del borde la pantalla se desplaza con el hasta llegar al extremo del campo de juego. Es to me sera util cuando sea multiplayer y pueda jugar en red en varias pantallas: se podran mostrar pantalla totalmente independientes y habra momentos en los que los jugadores no se vean entre si de lo lejos que andaran!!!. Ademas, he implementado un rudimentario metodo en la engine para que no pinte lo que no ve cada jugador (las naves/balas que queden fuera de su screen). Estaria bien que no se enviaran los paquetes, ya que significara menos trafico en red, pero tiene su complicacion si quiero un servidor multicast (o no, todavia no lo he hecho).

Cosas que he de hacer:
- Eliminar los paquetes que no se vayan a dibujar (los calculos se haran igual)
- Acabar el tema de las imagenes especiales con los reflejos de los laseres, las explosiones y las muertes
- Hacer funcional el tema de las naves medianas giradas

Pero lo hare en el orden que vaya viendo y tal vez intercale alguna otra cosa que vaya viendo necesaria.

Y mas!

Bueno, hoy he puesto bonito lo que hice ayer, ahora se le pasan unas constantes mas a la hora de crear cada navecilla en la que se dice que navecillas tienen que hacer flash cuando son alcanzadas. Tengo que meter ahi tambien los frames de cuando se haya disparado (un reflejo del laser en la nave) pero aun no tengo dibujos. Parece que va bien, el xwing ha adquirido las propiedades precisas con solo solicitarlas.

Ademas he modificado el corellian corvette de modo que pueda aparecer con un angulo de 90 grados, tengo que hacerle una estrategia nueva (para naves que van de lado) y tengo que cambiar la animacion de rotacion en la que se le asigna un loop indebido pero no la he podido hacer por no poder acceder al codigo bueno hoy...

Para mañana meto todo en el codigo y tengo que mirar las explosiones de las naves q van en horizontal, que me temo que aun son verticales. Asi como el reflejo del laser al disparar si me da tiempo y sera el copon. Ademas tengo que mirar unos errores que dan al pintar laseres que intuyo que es algun casting que hace mal (mejor dicho, que hasta ahora no era necesario)

Que animado!

Bueno, despues de pasar el fin de semana en basuri he continuado hoy con esto y la verdad es que ha avanzado algo:

He arreglado los problemas de reciclaje de los corellian, el tema de que 'apuntaran mal', un dividebyzero exception a la hora de apuntar y he arreglado las explosiones de las torretas... Vamos, que se puede decir que, a falta de dibujar algunos frames, el corellian corvette no tiene mucho mas que hacer...

Luego he hecho, gracias a un metodo de pygame, unas siluetas de las frames de las naves en amarillo y las he colocado dentro de las animaciones de modo que cada vez que una nave -o una torreta- reciba un disparo se dibuje la silueta (esta en amarillo) de la imagen que se deberia mostrar a modo de feedback de que se le ha alcanzado a la nave en cuestion... Esta bastante avanzado, solo me queda generalizarlo -ahora, pòr ejemplo, el xwing solo se pone amarillo si recibe disparos y no se esta desplazando lateralmente, me faltan esas dos animaciones que poner, solo he puesto la por defecto y tengo que pensar como hacer para decidir de una manera mas bella que animaciones deben tener siluetas amarillas y que animaciones no- pero me gusta.

Corelians

Bueno, parece que me repongo:

He introducido el corelian corvete con 2 cañocitos que disparan al jugador. Parece que lo hace bastante bien, me quedaria ajustar un poco la mirilla (que apunten al centro del sprite y no al punto 0,0, aka esquina superior izquierda), ver la recoleccion de corvetes como funciona (creo que en el tema de los decoradores hay algo que no he reseteado bien) y luego retocar el tema de las animaciones que no me convence mucho...

 Esta bien, ya empieza a parecer jugable :)


Luego aprovechare para limpiar el codigo de las cosas que han ido quedandose viejas. Pero estoy contentas, he visto cosas en el android market que estan menos avanzadas que esto y si le pusiera contador y fondo empezaria a parecer algo...

Q de cosas!!!!

Bueno, al final eso de los grupos no ha triunfado....

He solucionado el tema haciendo una especie de 'decorator': he hecho naves que implementan ship y que a su vez contienen una serie de ships...

Asi podre controlar que al morir no desaparezcan, la vida del total... en fin, no esta terminado pero esta vez si es la solucion correcta. Ya practicamente tengo el corellian corvette hecho, cuando lo acabe podre dormir mas tranquilo pq la logica estara casi hecha....

Sera el momento de hacer algo de el cliente o el servidor... Mmmmm que bien :)

Por cierto, me ha tocado un piso de proteccion oficial. :)

No me olvido

Bueno, ya esta arreglado la mayor parte del desaguisado...

Esta como al principio pero ademas con la parte de los mapas funcional :)

Ahora voy a hacer grupos, que podran ser grupos de naves, de balas... Un grupo sera un conjunto de elementos que se pintan y que se mueven juntos, de ese modo eliminare el problema de redondeo que tenia con los laseres.

Tambien voy a hacer que la estrategia para alcanzar el objetivo (la estrategia de ataque) se adquiera por herencia, aprovechando la herencia multiple de python, en vez de tener un objeto, tiene mas logica y queda mas reutilizable...

El tema de el mundo y el screen ira un poco mas tarde.

Una tarde?????

En fin....

Creia que iba a conseguir meter los mapas en una tarde... Y hasta hoy....

Ha costado, mas que el tema del mapa y las squads (que si que estaba practicamente implementado) el poder hacer factorias de objetos, se me han ocurrido diferentes estructuras que me iban gustando de mas a menos segun avanzaba el tiempo...

Al final me he decidido pq cada objeto (nave o bala) tenga como propiedad cual es el 'paraiso' al que tiene que ir cuando muera....

En fin, que he hecho una clase 'reciclador' que es la encargada de generar todos los objetos y reciclar los antiguos. Este reciclador tendra caches de todos los tipos de objeto y cuando le pidan uno de algun tipo especifico reciclara un objeto o creara uno nuevo. Cuando este objeto muera le informara al reciclador de que debe reciclarlo.

Cuando se reviva, el objeto pasara a formar parte de un container (uno diferente para amigos y enemigos) en el cual se le clasificara por nave o disparo (para calcular las colisiones mas eficientemente).

Funciona con peros:

• Aun no esta desarrollada la funcionalidad de 'morir' ya que no he activado las colisiones, de hecho quiero separar los conceptos 'mundo' donde se desarrolla el juego de 'screen' que seria lo que se muestra por pantalla y esto afectara, en cierto modo, a la destruccion de objetos...
• Hay codigo duplicado
• Tengo unexceso de constantes y de codigo spaguetti, debido tal vez a que hay ciertos contenedores de  protocolos entre diferentes objetos... En un principio no le veo mucha alternativa y podria parecerme hasta normal... pero no me gusta... a ver si se puede cambiar...

Bueno, aun asi estoy medianamente contento: Con los mapas y las animaciones practicamente he cambiado todo el programa, asi que es normal que me haya cosatado tanto.

Mas fregados:

Decidi postponer lo del corelian corvete. Ya estaban funcionales las rotaciones de las imagenes y los laseres salen con el angulo correcto, de modo que pense que lo siguiente era hacer que los tie interceptor saldrian e direccion al xwing....

El problema es que las naves estan hechas de una manera chavacana en el bucle principal, lo cual es una mierda que solo vale para hacer pruebas de que las cosas que voy haciendo van funcionando, pero ahora que ya tengo las naves mas o menos completamente refinadas va siendo hora de hacer un mapa en el que colocar todos los grupos de sprites y que gestione como tienen que aparecer y que hacen cuando desaparecen....

De modo que me he puesto con el mapa, todavia estoy implementandolo, la idea es introducir:

1. Una clase 'squad' que representaria a un grupo de naves atacando (p.ej. en formacion en 'V'
2. Un mapa en el que haya:

• Una lista de las squads que deben aparecer en orden cronologico
• Un periodo T que me dira cuando tengo que lanzar siguiente elemento de la lista de squadras
• Un almacen para cada nave de jugadores y uno para todas las naves enemigas (de modo que pueda controlar quien ha disparado que tiro para en el futuro asignarle una puntuacion)
• Un almacen de naves y balas para cada tipo de nave, de modo que no tenga que hacer y destruir objetos cuando mueran enemigos: esto es, tener unos almacenes de naves 'vivas' que cuando mueran pasen a almacenes de naves 'muertas' y de ese modo no haya que crear objetos. Del mismo modo haria con los disparos

De modo que tambien he tenido que cambiar las fabricas de naves y disparos, ahora solo deben crear cosas nuevas si sus correspondientes almacenes de objetos 'muertos' estan vacios.

Esta 'mas o menos' hecho, tengo que sustituir la logica antigua por la nueva y hacer que todo funcione, pero es un cambio curioso, por lo menos me llevara una tarde.

Ademas estoy cambiando alguna bala: las que dispara el xwing, al ser calculadas por separado, a veces ocurre que se redondean diferente la coordenada 'y' y dos laseres que van a la par comienzan a ir uno por detras del otro... no mola, de modo que voy a ver si pienso como meter un laser como subobjeto del otro (con un offset en x) y asi solo tengo que calcular la posicion de uno

Vuelta a la realidad

Vuelvo, lo he dejado durante un par de meses pq he tenido examenes en la UNED y eso... Uno bien y el otro.... me faltaban apuntes, de modo que bastante mal...

En fin, he cogido ya el libro de openGL para la asignatura de este cuatrimestre, ya se dibujar rectas y puntos...  wow :P

El juego, ademas, ha sufrido importantes cambios en esta ultima semana, a saber:

-Acabe el tema de las animaciones, ahora cada tipo de objeto -nave, bala....- tiene un 'ImageAnimator' que es un contenedor de todos los frames que puede mostrar dicho objeto, internamente maneja 'animations' que son todos los frames que muestra un objeto al hacer algo (por ejemplo girar a la derecha, explotar...).

-Cambio, por lo tanto, la manera de dibujar los objetos del motor, ahora en vez de recibir 'dibujame este rectangulo de la imagen de frames del objeto en la pantalla' viene a ser 'dibujame el frame X de la animacion Y de el objeto Z', y como cada objeto tiene asociado un ImageAnimator, el motor va alli y se lo pide

- Me meti con las rotaciones de las imagenes de los objetos. Curioso, al rotar las imagenes no las rota sobre el centro de la imagen (no gira sobre su centro) sino que gira la imagen tomando como centro el extremo superior izquierdo de la imagen, esto es: si la imagen fuera un foleo la gira como si cogieramos por el extremo sup izquierdo y lo mantuvieramos fijo al girar... En fin, que hay que hacer una pequeña translaccion de ejes... La he hecho creando unos offsets que se restan a las coordenadas a la hora de pintar. El problema es que no se como afectara a las colisiones y a el calculo del movimiento (creo que solo afectara a las colsiones, pero tengo que probarlo...)

Tengo que probar tambien el tema de las mascaras, que debieran funcionar...

Ademas tengo un dibujo de un corellian corvete por ahi que va a ser lo proximo que haga:

Que aparezca en el juego y que tenga torretas que apunten y disparen....

Para hacer eso, se me ha ocurrido, puedo utilizar el nuevo invento de los offsets y hacer 'subObjetos' a los objetos, siendo estos subobjetos objetos cuya posicion depende de la de otro objeto, asi puedo meter ahi torretas, escudos, cañones adicionales (para power ups)....

Mmmmmmm no me acordaba de lo entretenido que es hacer esto-....