Hola gente linda de scenebeta, hace años que visito esta pagina y no me animo a postear.Pero viendo que LuaDev tiene bastante soporte posteo tal vez alguien me pueda ayudar. Soy un programador amateur y me estoy pasando de Lua a LuaDev. Estoy creando un juego sencillo estilo Air Hockey pero me estoy peleando con la fisica para la colision de la bola con los jugadores 1 y 2. Basicamente he logrado que la bola cambie su velocidad en forma random con math.randomseed pero aun asi no se ve bien el efecto.
Queria saber si me podrian ayudar aunque sea con un pseudo codigo para orientarme de como tengo que plantearme esta situacion. Por ahora la bola rebota en diferentes direcciones al golpear contra la pantalla pero siempre golpea en casi los mismos lugares, lo unico que logre cambiar es que a veces al pegarle a la bola vaya mas rapido o menos rapido.La intencion seria que tenga algun tipo de minima gravedad para que modifique la trayectoria de la bola y sea menos predecible el tiro
Estas son las dos funciones que estoy utilizando:
function movimientoBola()
if Bola.y <= 0 then
Bola.yvelocidad = 6
end
if Bola.y + Bola.img:height() > Resolution.height then
Bola.yvelocidad = -6
end
Bola.x = Bola.x + Bola.xvelocidad
Bola.y = Bola.y + Bola.yvelocidad
end
function verificaColision(obj1,obj2)
if (obj1.x + obj1.img:width() > obj2.x) and
(obj1.x < obj2.x + obj2.img:width() ) and (obj1.y + obj1.img:height() > obj2.y)
and (obj1.y < obj2.y + obj2.img:height() )
then
if (obj1.y > obj2.y) and obj1.y < (obj2.y + obj2.img:height()/2 ) then
obj1.yvelocidad = -6
else
obj1.yvelocidad = math.random(4,7)
end
if obj2 == Player[1] then
obj1.xvelocidad = math.random(4,7)
else
obj1.xvelocidad = -6
end
end
end
No importa si me pueden ayudar o no , pero agradezco de antemano a quien se tomo el tiempo de leer el post. Saludos
http://pixelperfectgames.blogspot.com mi blog de programador amateur, mis proyectos, mis avances
http://thegameisntover.blogspot.com mi blog de videojuegos en general, opiniones y visiones del mundo del videojuego
La programación y las matemáticas... suelen ir de la mano.
Esta duda te la respondo a tí, pero lo haré de manera que pueda servirle a más de uno, cuando estés desarrollando cosas así, intenta ir paso a paso, poner tus primeras ecuaciones en marcha, y ver qué ocurre, una vez averigues un problema, añadir ecuaciones, y seguir viendo qué ocurre, hasta que lo que veas, sea muy parecido a lo que tenías en mente al principio. Si bien esto es obligatorio para los novatos, cuando lleves un tiempo haciendo tus pinitos te darás cuenta de que configuras más ecuaciones inicialmente según vas adquiriendo experiencia en este bonito mundo de la programación.
Contando que tu air-hockey es bidimensional supongo, tenemos un plano con dos ejes, eje X horizontal y eje Y vertical.
Vamos a intentar identificar algunas "ecuaciones", o condiciones iniciales según lo que queremos realizar.
A)
Pensamiento inicial:
En este caso imagino es un air-hockey, bidimensional, y restringido al tamaño de la pantalla del PSP.
Deducciones extraídas:
Un plano 2D (X,Y), dónde el máximo es X=480,Y=272, y el centro estará en CX = 480/2=240, CY = 272/2=136.
Código extraído:
campo = { x=0, y=0, w=480, h=272, cx=240, cy=136 };
B)
Pensamiento inicial:
La pelota comenzará en el centro, y se moverá describiendo un movimiento uniforme sin aceleración, con una velocidad inicial hacia cualquiera de las dos "porterías" que se encontrarán una a cada extremo horizontal del campo. La pelota en el saque inicial no debe de ninguna manera quedarse atascada rebotando de arriba hacia abajo sin dirigirse hacia ninguna portería.
Deducciones extraídas:
Para la pelota necesitamos dos coordenadas para su posición (X,Y), y un vector dirección (VX,VY). La dirección inicial en el componente X no puede ser 0, y debería ser superior a VY. El movimiento uniforme sin aceleración presenta la forma X(t) = Xi(t) + V(t)*t, dónde X(t) es la posición en el instante t. t es el tiempo, V(t) es la velocidad en el instante t, y Xi(t) es la posición anterior al tiempo t. La velocidad inicial la consideraremos de un 50% a un 70% de la velocidad máxima en el eje X, y de un 10% a un 20% en el eje Y, para que salga horizontalmente, y algo inclinada.
Código extraído:
math.randomseed(os.time());
velocidadmaxima = 10;
bola = { x= campo.cx, y= campo.cy, vx= ((math.random(50,70) / 100)*velocidadmaxima), vy = ((math.random(10,20) / 100)*velocidadmaxima) }
--direccion inicial hacia cualquiera de los dos campos (50% probabilidad).
if math.random(0,100) > 50 then bola.vx = -bola.vx; end
if math.random(0,100) > 50 then bola.vy = -bola.vy; end
function pasobola()
bola.x = bola.x + bola.vx; -- ( x = x0 + v * t ) [ t = 1 frame. ] [ x = x0 + v ]
bola.y = bola.y + bola.vy;
end
C)
Pensamiento inicial:
No quiero que la bola se salga de los límites de la pantalla. Éstos actuarán como paredes y la bola rebotará.
Deducciones extraídas:
La colisión entre una bola y la pared, tiene en cuenta diversos factores, ángulo de incisión de la bola con la pared, rugosidades de los materiales y movimiento spin de la bola, así como su radio, pero para simplificar consideraremos rugosidades nulas, bola sin spin y radio de la bola nulo.
Código extraído:
function pasobola()
bola.x = bola.x + bola.vx;
bola.y = bola.y + bola.vy;
if bola.x < campo.x or bola.x > campo.w then bola.x = bola.x - (2*bola.vx); bola.vx = -bola.vx; end
if bola.y < campo.y or bola.y > campo.h then bola.y = bola.y - (2*bola.vy); bola.vy = -bola.vy; end
end
Hasta aquí, ya tenemos una pelota que comienza a rebotar desde el centro en todas las paredes, nunca acelera ni frena, y siempre se mantendrá dentro de la pantalla, de momento parece que somos fieles a nuestro diseño, así que deberíamos seguir añadiendo dos palas en los extremos horizontales, y ver si rebotan. En el caso de palas horizontales, se pueden usar las simplificaciones anteriores, en caso de palas circulares, deberia contemplarse el radio de éstas y el ángulo de incisión de la pelota, para poder averiguar el plano tangente con el que hace colisión, y calcular las nuevas velocidades.
Espero que siguiendo ésta metodologia, paso a paso ir probando cómo va quedando, y sobretodo intentar averiguar de qué expresiones sacamos el código, por que toda lei física que queramos representar tiene alguna fórmula matemática que nos puede ayudar a representarla.
En este caso por si no se entiende bien, x = xo + v * t, como queremos de frame a frame, simplificamos t = 1, y podemos sakar el incremento de posición como: x - xo = v * 1, IncrementoX = v, así que a cada paso, a X deberemos sumarle V, de ahí que X = X + V; en el codigo pasobola.
Espero que este tostón te ayude a intentar seguir con ese airhockey ;)
Edito:
Para los que no vean de donde sale el - (2*bola.vx) en el rebote, aquí va:
Si me he pasao del borde, retrocede una posición, cambia la direccion de la bola, y vuelve a dar el paso:
if bola.x < campo.x or bola.x > campo.w then
bola.x = bola.x - bola.vx;
bola.vx = -bola.vx;
bola.x = bola.x + bola.vx;
end
Imaginando que VX = 2, los incrementos a bola sería: -(2), cambio de sentido el 2, y sumo eso +(-2), == -4. ( con lo que -2 * bola.vx antes de empezar, funciona igual, o primero cambiar de sentido y luego bolax = bola.x + 2*bola.vx haría lo mismo, el caso es que nos ahorramos una linea. xD)
Actualmente desarrollando nuestra web y UXCode : http://www.gcrew.es
...
Y aún alucinan cuando les digo a mis amigos que física y matemáticas son necesarias saberlas para programar.
Genial explicado, Deviante. Parrafazos ;D
LOL
Contestaste lo mismo que yo XD
Wow es cierto jejeje
No vi tu comentario, pero si los dos hemos comentado lo mismo, es que es verdad :D
Mmm...
Y después me dicen: "¿Física y programación?, ¿Tu estás loco?". No se que entienden por físicas en un juego...
Espectacular explicacion
Muchas gracias Deviante voy a intentar alguna de las tecnicas , en realidad el air hockety ya lo tengo armado el tema es que la bola nunca desaceleraba o cambiaba su velocidad. Por lo cual era predecible su posicion.Era mas que nada la logica que no entendia para poder sacar las funciones. Con esta explicacion me puedo guiar mas . Asi que muchisisisisimas gracias.
PD: Deviante sacaras alguna nueva version de GDP? porque estaba demasiado bueno como para dejarlo a medio hacer. Realmente el homebrew con mas calidad de la scene PSP.
Saludos y gracias nuevamente
http://pixelperfectgames.blogspot.com mi blog de programador amateur, mis proyectos, mis avances
http://thegameisntover.blogspot.com mi blog de videojuegos en general, opiniones y visiones del mundo del videojuego
GDP volverá, pero triplicará
GDP volverá, pero triplicará en innovación y gráficos, respecto a su antecesor demo. :D
Genial!
Realmente Deviante si hay algo que me inspira es ver homebrew de calidad si bien estoy en proceso de aprendizaje es mi objetivo a futuro. Ese juego me parecio incluso divertido y algo que me daba un poco de bronca es que en el codigo hay bastante dialogo de diferentes tutoriales que no podemos divisar aun. Confio en que va a ser un gran juego pero realmente quiero animarte a seguirlo porque lo ddisfrute mucho sobre todo el tema de cambiar de camara , me hizo recordar a grandes clasicos como Virtua Racing de nuestra no tan difunta Sega Mega Drive.
Como digo , me inspira mucho el trabajo que hacen ustedes , confio en que va a quedar espectacular y sera muy divertido.
Yo la verdad en cuanto a fisica y matematica nunca fui muy bueno pero si lo era en logica y puedo diseñar, porque dibujo desde los 7 años. Estoy creando un juego de terror (aventura grafica estilo silent hill mobile)que me gustaria que me des tu opinion cuando puedas de lo poco que tengo armado.
Igual sea lo que sea sigue con tu genial trabajo!
http://pixelperfectgames.blogspot.com mi blog de programador amateur, mis proyectos, mis avances
http://thegameisntover.blogspot.com mi blog de videojuegos en general, opiniones y visiones del mundo del videojuego