jajaja, hombre no he usado nada raro, KeyEvent y keyListener no deberían dar problemas no?? ;)

Solo tienes que clickar en DOWNLOAD y luego hacer doble click sobre el .jar,  no son applets, son ventanas, exigencias de la JAVA4k...

:shock: ¿ventana chica que se regenera?

:evil: Odio Linux :P

Editado: Se me ocurre... Si podéis probar ESTE JUEGO o ESTE OTRO Y decirme si os funcionan me haríais un favor. Son otros dos mini juegos mios y cada uno de ellos utiliza el teclado de forma distinta, a ver si os funcionara alguno  :wink:

Mmm estoy mirando un poco en google y por ahora no encuentro porqué podría ser... En la documentación del KeyEvent no habla de ninguna incompatibilidad y no encuentro apenas resultados de foros o problemas similares.

Mi código es bastante simple en este aspecto:

public void keyPressed(KeyEvent e) {
      
      //variables locales
      int letra = e.getKeyCode();
      
      
      //codigo
      switch(letra){
         case KeyEvent.VK_W: jugador.setAcelerar(true); break;
         case KeyEvent.VK_S: jugador.setFrenar(true); break;
         case KeyEvent.VK_A: jugador.setGirarIzquierda(true); break;
         case KeyEvent.VK_D: jugador.setGirarDerecha(true); break;
.
.
.

Simplemente recibe el KeyPressed, toma el código de teclado y comprueba qué tecla se pulsó... ¿Alguién sabe qué puede ser?

Mars Attacks, ¿no te va el ratón o el teclado? Yo uso firefox en windows y un amigo lo ha probado en exprorer, pero nade en Linux que yo sepa

¿Alguien con linux que comente que tal le va?

[Definición:]

Antes que nada agradecer a aquellos que votaron en la encuesta del foro y más aun a los que comentaron su opinión. Gracias por el apoyo y vuestros consejos.

Dado que la encuesta ha resultado en una aplastante victoria de los algoritmos, voy a centrarme más en ellos. Pero shephiroth me dio una idea que me gustó que es la de hablar de algoritmos pero mostrar aplicaciones prácticas y ejemplos. Procuraré traer un algoritmo o grupo de algoritmos nuevo cada semana, pero también habrá semanas que dedicaré a un modelo de juego o a ejemplos de juegos que aplican algoritmos ya vistos. Como siempre los comentarios, críticas y aportaciones son bien recibidas.

Hoy voy a hablar un poco de detección de colisiones y al final traigo una pequeña sorpresa, para los que sean capaces de leerlo completo :P

Definición: Tomaremos como Algoritmos de Detección de Colisiones (a partir de ahora ADC) aquellos que se ocupan de que, en la geometría de un juego, no haya intersecciones entre objetos. Además estos algoritmos pueden indicar cómo debe reaccionar determinado objeto en caso de intersecar a (chocar con) otro.

Dificultades técnicas: Los AGC son, si no los acotamos, algoritmos muy costosos, ya que tenemos que calcular la intersección de cada objeto con todos los demás y para cada caso tendremos que comprobar cada pixel o cada vértice de cada objeto... Esto los hace en principio muy costosos computacionalmente, y por eso son uno de los temas más tratados en programación de juegos. Para acotar el problema e incluso reducir su orden de complejidad tenemos que saber bien qué resultados queremos obtener y qué es lo que realmente necesitamos. Por ejemplo:

   * Si los enemigos y objetos del juego siguen un camino predefinido o son estáticos no necesitarán de estos cálculos y podremos aplicar el ADC sólo al jugador principal.
   * Si la forma de los objetos de nuestro juego es cercana a un cuadrado o un círculo (un cubo y una esfera en 3D) no necesitaremos algoritmos complejos y este será un problema casi resuelto.
   * Tenemos que saber cuánta exactitud queremos conseguir y cuanto sacrificio computacional representa.

Como dijo Jack el Destripador: Vayamos por partes...

Muchas librerías y motores traen funciones más que de sobra para hacer el trabajo sucio por ti. Si estás utilizando o pretendes utilizar cualquier motor o librería, lo que debes hacer es leer qué funciones te provee y cómo puedes utilizarlas para cumplir tu objetivo. Si eres un campeón y estás escribiendo tu juego desde cero o simplemente quieres aprender cómo va esto de la detección de colisiones... Sigamos ;)

Lo primero que debemos hacer, una vez evaluado nuestro problema, y si necesitamos velocidad y tenemos muchos objetos que comprobar, es dividir el escenario en una cuadrícula. Si tenemos un escenario 2D esto será fácil, si tenemos 3D, pero básicamente los movimientos son a lo largo y ancho de un escenario, podremos dividir igual que antes, el plano XY. Si no, tendremos que dividir en cubos. ¿Para qué hacemos esto? Para acotar el número de objetos con los que haremos cálculos. De todos los objetos que necesiten ser revisados por el ADC, eliminaremos aquellos que se encuentren en cuadros separados de la cuadrícula, con lo que ahorraremos mucho cálculo inútil. En el dibujo de ejemplo, solo calcularemos la intersección del jugador (azul) con los objetos rojo oscuro, que son los que se encuentran dentro de sus cuadrículas (verde).


Dibujo1: División del escenario.

Una vez reducido el número de objetos que necesitan comprobación pasaremos al test de intersección propiamente dicho. Aquí también hay muchas técnicas, voy ha hacer un pequeño repaso de peor a mejor:

   * Si estamos en 2D podemos comprobar pixel a pixel si dos sprites se superponen, esta es la técnica que afina al máximo, pero muy costosa.
   * Tanto en 2 como en 3 dimensiones podemos aplicar la técnica de cajas o esferas envolventes o bounding boxes/spheres. Esta técnica consiste en definir un cuadrado o círculo que acota completamente cada objeto. Hacer cálculos con éstas cajas es muy sencillo ya que son formas sencillas:

     
     Dibujo 2: Bounding boxes/spheres
         o - Para comprobar colisiones con el rectángulo del jugador, para cada vértice de un rectángulo objeto comprobamos:
           SI (xPunto > xJugador) Y (xPunto < xjugador + anchoJugador) Y (yPunto > yJugador) Y (yPunto < YJugador+largoJugador) ENTONCES El punto se encuentra dentro del rectángulo -> COLISIÓN DETECTADA.
         o - Para comprobar colisiones con círculos:
           SI (suma de los radios) > (distancia centroJugador, centroObjeto) ENTONCES COLISIÓN DETECTADA.
   * Si los objetos del juego están constituidos por vértices y aristas podemos aplicar funciones de intersección entre aristas, puntos y planos. Esta es una solución más costosa pero más certera que la anterior. Podríamos obstar por soluciones intermedias, como tener un modelo en muy baja poligonización para la detección de colisiones y otro para la representación gráfica. O tener al jugador dividido en partes y aplicar bounding boxes a cada parte para luego comprobar a nivel de superficie sólo las partes que dieron positivo en el primer test.
   * Podemos usar árboles BSP (partición binaria del espacio) para dividir recursivamente las BB y obtener más precisión

.
.
.

Hay decenas de técnicas, por ahora creo que está bien como introducción, más abajo dejo unos cuantos links para los que quieran profundizar. ¡¡Y ahora viene la sorpresa!!

Esta semana me puse un ratillo y completé el menú y el sistema de fases de un juego inspirado en el Asteroids que comencé hace tiempo. La verdad es que quería añadir algunos detalles más, sobre todo gráficamente para explotar un poco el pequeño sistema de partículas que implementé, pero hacía tiempo que no lo cogía y le había perdido ganas, así que por ahora estoy contento con poder mostrar un juego cerrado. Es totalmente procedural, como todos mis jueguecillos hasta ahora (nada de imágenes, solo código).

La detección de colisiones es a nivel de aristas, Java provee de funciones para el cálculo de intersecciones entre aristas y rectángulos y decidí utilizar las aristas ya que los polígonos de los meteoros y la nave están almacenados como listas de vértices. No divido la pantalla ni en cuadros ni nada de eso ya que el juego no requiere demasiado y yo no quería meterme en más fregados (a mi no me consume ni un 10% de CPU, comentadme que tal os va).

Espero que os divertáis un poco, si os picáis dejadme comentada vuestra puntuación máxima. ;) Yo no he podido jugar mucho, ni siquiera he llegado a los octaedros, me quedé en los 32000 puntos. :P

El juego: Podéis jugar desde el Blog o pinchando AQUÍ

(Para jugar es necesario tener instalado el JRE 1.6 - Java Runtime Enviroment -)

Enlaces para ampliar: (en inglés, encontré poco que rascar en español...)

GamesPP - Varios tutoriales, desde lo más básico a técnicas avanzadas.
N toturials - Explicaciones básicas con código y un bonito Applet de ejemplo.
Team gamma - Más técnicas, papers, videos...
Esto mismo en BLOG - algo mejor formateado y más accesible :)

HEY! Yo soy de Málaga! Y tengo tantas ganas de trabajar que yo creo que me pasa algo malo... :P Pero estoy con el proyecto de fin de carrera y no tengo experiencia, así que no me quiere nadie  :cry:

Yo creo que también los empresarios tienen muchos pájaros en la cabeza o no comprenden lo que piden, a menudo me encuentro con ofertas de trabajo en las que tienes que saber C#, JAVA, PHP, SQL, Administración de redes, tener mínimo 2 años de experiencia, y te ofrecen 13000 al año. Vamos que quieres un informático que te haga el trabajo de 2 y cobre menos que un repartidor de pan...

Si las empresas ofrecieran mas trabajos a personas sin experiencia y los formaran dispondrían de personal especializado en las tareas que ellos necesitan y al precio que quieren pagar. Pero claro, me diréis que yo no soy empresario y que esto va de ganar el dinero tú y explotar a los demás... xD

¿Cuál se parece a Carmack?? Eran simples bocetos de "modelos de frikis" :P

Hombre esa era la intención, hacer un personaje que resultase familiar y simpático. Son solo propuestas, a ver si se anima un poco la cosa. Aunque lo siento por Ager, pero parece que si quieres más participación vas a tener que plantear un concurso o algo, ¡Estos grafos que no menean el culo! :P

Tener sprites de la carretera por cada ángulo de curva consume mucha memoria y es poco flexible.

Evidentemente, si estamos tratando con móviles por ejemplo tendremos que optimizar todo lo posible y la fórmula que propones sería mucho mejor. Si estamos en PC o en las portátiles actuales (ds, psp...) no creo que fuera un problema tener 5 o 6 frames para cada tipo de escenario (cesped, desierto, etc) que darían para de sobra para representar curvas más y menos cerradas y es más sencillo de implementar.

Si es cierto que en la fórmula que propones sería más suave, más frexible en cuanto a introducir lineas de carretera o irregularidades y claro está, más barato en memoria. Como dices, habría que ver si merece la pena en cada caso...

Ok, podemos decir que este es el bueno, siento el desaguisado :P

En cuanto a la pregunta, me has hecho pensar un poquito, no había hablado de cómo dibujar este tipo de juego, así que vamos un poco a ello:

En el modelo de carreras con vista trasera y sprites se me ocurren dos representaciones completamente distintas:

La primera sería tener un mapa del circuito de la misma forma que lo tendríamos en el de vista cenital y según la posición en la que se encuentre nuestro coche dibujar el sprite de escenario adecuado:



En el dibujo, el punto blanco es nuestro coche, los puntos verde oscuro son árboles y las lineas azules marcan el horizonte y el punto más cercano a cámara. La linea roja imagina que es perpendicular a la azul y coincidente con el coche, de esta forma tenemos el punto central de la visión, y podemos saber como de a la derecha o a la izquierda queda la carretera y dibujar uno de los sprites de la derecha, o sus invertidos, según convenga. Para el caso del retrovisor sería igual, solo que hacia atrás.  Esto es muy visual y es lo primero que me vino a la mente, pero es muy engorroso de programar e innecesario. Luego añadiríamos los sprites de los árboles y los coches enemigos (en celeste) más o menos lejos según donde estemos en el circuito. Y eso me lleva a la segunda implementación.

La segunda opción, que veo mucho más cómoda de implementar y más versátil incluso al ser más procedural es:
Tenemos una batería de sprites de fondo como los tres dibujos de la derecha, todos los necesarios. Los sprites de los árboles o lo que queramos y demás. Y el circuito en este caso es simplemente una lista o array de duplas: (distancia,tipoDeCurva) y otro de tuplas con los elementos del escenario: (distancia,posiciónHorizontal,objeto) De esta forma, solo tenemos que tener en cuenta cuánto avanzamos en función de nuestra velocidad e iremos recorriendo el array y dibujando el sprite que apunte tipoDeCurva cuando nuestra posición sea mayor o igual a distancia. Con los objetos, si   la distancia del objeto menos nuestra posición es menor que un determinado valor (horizonte) lo dibujamos en una altura proporcional a este esta diferencia. Con los coches enemigos igual. Para el retrovisor de nuevo solo tendríamos que tener sprites adecuados (tal vez escalando e invirtiendo los de la carretera...¿?) y marcar una distancia de horizonte negativa para representar objetos y enemigos (ahora de frente, eso son algunos sprites más ;P)

Como verás esta representación es más abstracta pero mucho más potente y cómoda de implementar. Operando un poco sobre el array/lista en tiempo de ejecución podríamos tener una carretera infinita que no se repitiera o ir cambiando el tipo de escenario gradualmente apuntando a distintos frames de fondo...

¡Hola Ager! El otro día tenía ganas de garabatear y te hice estos dibujillos ;) Si alguno te gusta (o quieres crear un hibrido o algo parecido a alguno de ellos,   en el estadio "boceto" todo es altamente modificable xD) dímelo, puedo pasarlos a limpio y darles color y demás, de 3D nada, pero algo decente en 2D si que puedo hacer :)

Son distintas versiones de un hipotético personaje: NJ, que sería la representación del periodista o quiosquero de NoticiasJuegos :) El último en versión Demonio corre-ve-y-dile-cabreado :P

ohh cuanto apoyo!  :oops: Gracias a todos. Tomo nota de las sugerencias. No sé cambiar la encuesta, así que el que quiera votar "Que se quede como está" que comente, que además me sube el ánimo :P  

El caso es que a mi me gusta hablar de las dos cosas, y también había pensado hablar de las dos pero por turnos, una semana de jugabilidad y otra de algoritmos. Ya que tampoco quiero aburrir hasta a las vacas escribiendo 4 o 5 páginas cada semana sobre un mismo juego, ni sé si tendría tiempo de tanto... ;P

Hola, no sé si alguien lo notó, pero esta semana faltó mi comentario de modelo de juego, estuve de viaje y no tenía nada preparado con antelación, mea culpa. Pero para resarcirme, y en vista del nulo éxito de la última entrega voy a hacer una pequeña encuesta hasta el siguiente:

¿Preferís que hable de algoritmos útiles en modelos de juegos o del gameplay de juegos en general, mas o menos punteros?

Es decir, a partir de ahora me centraré en una de las secciones para poder escribir más de ella, ¿cuál preferís?

Ok xD emm... si en java.. asi ya esta para celu y lo puedo jugar por ahi xD

¿Entonces en qué tenías pensado hacerlo?

el verde furioso no! Very Happy o ese color es asi para luego reemplazarlo por otro?

Voy a aventurarme a responder por tutiman, pero da la impresión de que el verde es el "color transparente" para que veamos cada sprite individualmente sobre un fondo no negro... ¿no?  

Por cierto, mejor el nuevo Game over, el oso sanguinoliento me traumaba xD

Eyh tutiman, yo estoy debatiéndome entre mirar flash o J2ME para la campus, el segundo tiene más puntos porque ya sé Java, solo que la gente lo putea mucho...

Este finde me voy por ahí (hasta el martes, qué finde más largo xD) pero si quieres a la vuelta hablamos. Me gusta la idea del pong para móviles, tenía ganas de hacer una colaboración y se te ve con ganas y sin muchas pretensiones :D