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...
miércoles, 27 de octubre de 2010
martes, 26 de octubre de 2010
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....
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....
lunes, 25 de octubre de 2010
Empezando el multiplayer
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. :)
miércoles, 20 de octubre de 2010
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...
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)
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-.
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-.
domingo, 3 de octubre de 2010
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...
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...
Suscribirse a:
Entradas (Atom)