Comunidad Game Maker

Saludos.

Tengo un problema, a ver si me podeis ayudar.

Necesito montar un script para manejar las articulaciones del ultimo jefe de mi juego, pero para ello necesito dar solucion al siguiente problema:

CitarAveriguar las coordenadas x e y del punto al que apunta un vector (xf,yf) del que conozco:

• Las coordenadas x e y de origen del vector (xo, yo).
  
  
• La longitud del vector (long).
  
  
• La direccion del vector (dir).
  
  El cuadro de coordenadas de referencia tiene origen en la esquina superior izquierda de la pantalla.
  
  ----------------------------------------
  |
  |
  |   #(xo,yo)----------->#(xf,yf)
  |
  |
  |
  |

A ver si de paso aprendo/desempolvo algo de matracas, que desde que termine de estudiar no he hecho practicamente nada mas que sumar y restar.

Hola, no se si entendi bien tu pregunta pero creo que solo tienes que restar los vectores, es decir, tu tienes los vectores X0 y Xf, con la condicion que X0+Y=Xf donde Y es el vector que buscas por lo que Y=Xf-X0, saludos!!!

Calcula el componente vertical y horizontal de ese vector y sumaselo a "xo" y a "yo".

xf = xo + lengthdir_x(long,dir);
yf = yo + lengthdir_y(long,dir);



lengthdir_x devuelve "Ax" y lengthdir_y "Ay".

Suerte con el jefe  :)

Zeit, solo hay un vector, lo que queria calcular son las coordenadas de la posicion final a la que apunta, no la distancia que los separa.

La leche, no habia caido en que podia utilizar las funciones de GM para sacar los componentes x e y del vector y sumarselos a la posicion de origen. Visto asi parece una cagada.

Voy a probar, gracias a los dos.

No me qued? clara la relaci?n entre este asunto y las matrices. ?Podr?as explicar un poquito qu? tienes en mente? Yo tambi?n tengo personajes articulados en varios juegos pero no veo por d?nde una matriz podr?a ser ?til... No conozco los m?todos de matrices de rotaci?n en 3D, quiz? a eso te refer?as. Y quiz? con esto yo tambi?n pueda aprender algo para aplicar en mis personajes rotulados. Actualmente hago estos personajes calculando punto por punto las coordenadas de cada parte y su giro mediante trigonometr?a, pero puede haber una mejor forma.

En realidad es bastante sencillo.

Veras, lo que queria es conseguir una forma de obtener las coordenadas relativas de un objeto con respecto a un punto. Todo esto definido por un angulo, una distancia y una posicion inicial. Ya con eso en mente, es posible crear articulaciones tomando como punto de referencia un nodo. El tama?o de la "extremidad" es la longitud del vector y su inclinacion el angulo especificado.

En mi caso lo veo necesario porque mover y rotar las extremidades de un jefe por este metodo es mas sencillo que hacerlo a base de pixelar diferentes poses para la extremidad. Ademas de que el movimiento es mucho mas fluido, puede ser modificado sin mucha ciencia y no es preciso crear mas que un sprite para cada articulacion.

Por el momento es un experimento, os dejo un enlace para que veais como funciona el concepto. Aun tengo que seguir investigando, si os animais a experimentar para mejorar la idea, pues estupendo. Como es un concepto relativamente abstracto, puede tener utilidad en juegos de casi cualquier tipo.

Molaria que un dia de estos nos juntaramos unos cuantos para deconstruir un genero y crear scripts genericos (sistemas de colision para plataformas, inventarios para RPGs, GUIs...). Cada vez hay mas gente con buen nivel de programacion y es mas sencillo crear cosicas interesantes a base de ayudarnos unos a otros.

Hola, no habia entendido tu pregunta pero como dice Soujiro hay que calcular las proyecciones del vector formado por una lingitud y un angulos (direccion) hacia los ejes formados por el punto origen, yo tampoco sabia que habian esas funciones, yo hubiera calculado manualmente, jajaja, saludos!!!

No seria mala cosa que expusieras como se calcula de forma manual, me he quedado con la duda.

Bueno, acabo de crear un nuevo editable para controlar articulaciones, ya algo mas limpio. A ver como lo veis. ?Como lo simplificariais para hacer mas facil implementarlo, que le a?adiriais vosotros?

Por el momento necesita al menos dos objetos y utiliza 4 scripts, aunque de cara al usuario solo hay que manejar uno.

si ablas de como hacer de forma manual las funciones lengdir

x = coseno de angulo * modulo.
y = seno de angulo * modulo.

(lo hise mirando el esquema de Soujirocon el mismo sistema de cordenadas)

EL MODULO TIENE QUE ESTAR EN PIXELES SUPONGO  :-\

para las posiciones relativas solo le sumas las cordenadas que ya tiene

xf = xi + coseno de angulo * modulo.
yf = yi + seno de angulo * modulo.

Hola, pues como un punto (xf,yf) en un circulo de radio longitud y con centro en el (0,0) tiene coordenadas (xf,yf)=longitud*(coseno(direccion),seno(direccion)) donde direccion es el angulo, solo hay que trasladarlo a tu punto de origen (x0,y0), es decir, (xf,yf)=(x0,y0)+longitud*(coseno(direccion),seno(direccion))... Saludos!!!

Ya veo lo que tratas de hacer... mmmm... viendo algunas im?genes del juego Quantum Distortion de Raul_Omega (http://www.comunidadgm.org/index.php?action=blog;blog=136) y del juego en desarrollo de demon_hio Guerra de smillies (http://www.comunidadgm.org/index.php?topic=9421.0), me parece que intentaron lo mismo: marionetas articuladas para personajes, en vez de usar una infinidad de sprites para recrear las animaciones. De hecho, hace bastante tiempo vengo usando esta idea y la he aplicado a algunos juegos que hice, el ?ltimo de los cuales (Master of Mementors, en desarrollo) la usa en forma intensiva (http://www.comunidadgm.org/index.php?topic=2717.0).

Sobre lo que dices, estoy de acuerdo en que es una t?cnica extraordinariamente ?til y tiene resultados espectaculares; como dices, permite crear infinitas animaciones en base a rotaciones de las partes del esqueleto, todo con un pu?ado de sprites. Sin embargo, la desventaja est? en que he comprobado que el rendimiento en t?rminos de procesamiento puede decrecer bastante si hay muchas partes m?viles en juego y adem?s todo debe girar dentro del plano de la pantalla, a diferencia de los sprites animados donde puedes poner lo que te plazca y simular rotaciones fuera de ?ste.

Analizando tu ejemplo, me parece que funciona bien para simular rotaciones de cuerpo r?gido en torno a un punto, pero hay que tener cuidado del orden en que actualizas las posiciones y ?ngulos de las partes: si no partes por la base del esqueleto y luego por los "hijos", obtendr?s extra?os efectos de retardo (te lo digo por experiencia propia) as? que hay que tener cuidado con eso (me refiero, por ejemplo, a llamar al script sc_ctrlnodos() primero para la parte 5 en vez de la 1). Ahora bien, podr?a mejorarse notablemente el sistema si permitieras que cada parte gire en forma relativa a la parte de donde se sujeta: ah? tendr?as una enorme libertad para crear animaciones (y ah? es donde comienza a complicarse el asunto). No s? si alguna vez lo viste, pero en los tiempos en que exist?a GM Forge, expliqu? all? c?mo lo hac?a yo para lograr este efecto; de hecho invent? una aplicaci?n hecha en GM para crear modelos y animarlos usando esta idea. La animaci?n propiamente tal se basa en el uso masivo de timelines. Adjunto la idea que tengo y un ejemplo de c?mo lo hago hasta ahora, aunque s? que podr?a mejorarse bastante (en la demo, para simplicidad, no actualizo en el orden correcto cada parte y por eso se ve un peque?o desfase entre las partes rotuladas). En mi teor?a yo le llamo "amo" al elemento de donde se agarra una parte (t? le llamas padre[ i ], es lo mismo). Dejo los c?digos libres por si alguien se interesa en mejorarlos y que el conocimiento se disperse. Sobre la aplicaci?n, tengo que corregir algunos bugs as? que por ahora no la coloco (y nadie entender?a c?mo se usa, deber?a crear una gu?a  XD ).

mmm... Mas sencillo que eso, creo que con simple mecanica vectorial se puede resolver.

xo= long* (cos* dir) + xo
yo= ((long*(sen* dir) )*-1)+ yo

de hecho creo que es lo que zeit ya hiso, pero como que con eso de trasladar la direccion y el origen 0,0 pues como que me quedo duda de ver si lo hiso realmente o se fue por otro camino  :-\ .

Algo que creo no se not? es que en este caso, para el GM la suma de las coordenadas Y es hacia abajo y la resta es hacia arriba, cosa que nos dar?a un resultado "ambiguo" con el clasico Fy=F sen 0, por que si la direccion es hacia arriba entonces nos dar?a un resultado positivo, el cual se le sumaria a Y y por consiguiente en el GM la direccion apuntaria m?s hacia abajo  :-[

SALUDOS

Gracias por indicarme como se hacia el calculo manualmente. No tenia nada claro como se hacia.

Mmmm... Guacusio no se si te entendi del todo lo que indicas sobre permitir el giro de las partes de forma relativa a otras. Tal y como me parecio entender lo que dices, el editable ya lo hace. Cada parte se mueve de forma relativa al nodo anterior. Ahora bien, es cierto que le doy mucha importancia al orden en que se crean los nodos, lo hice pensando en que simplificaria su implementacion, pero repasandolo un poco he visto que en realidad lo que hace es complicar y limitar el script, ya que no permitirle al usuario definir con facilidad a que nodo quiere enlazar cada uno. Te dejo un nuevo adjunto teniendo en cuenta lo que comentas, ?es esto lo que proponias? por como he visto que funciona, creo que lo podrias aplicar a tu editable sin cambiar mucho su enfoque.

Con respecto al editable que expones, la idea de las timelines no me parece nada mala. Supongo que la idea es almacenar en una timeline diferente cada animacion y despues se las vas asignando al objeto a animar segun competa, de la misma forma que harias con sprites, ?no?. A mi a veces se me pasan esas cosas por falta de uso. Las IAs de mis jefes las controlo a manubrio con un sistema de rutinas y contadores, pero veo que hubiera podido simplificarlas si hubiera confiado en las herramientas que ya tiene GM en lugar de en mi afan por controlarlo todo. ?Has comprobado si las timelines aumentan el peso del ejecutable de forma diferente a como lo haria un Script?, lo mas seguro es que no, pero no he tenido tiempo de hacer la prueba.

Cita de: knd144 en Noviembre 21, 2009, 03:35:39 AM
mmm... Mas sencillo que eso, creo que con simple mecanica vectorial se puede resolver.

xo= long* (cos* dir) + xo
yo= ((long*(sen* dir) )*-1)+ yo

de hecho creo que es lo que zeit ya hiso, pero como que con eso de trasladar la direccion y el origen 0,0 pues como que me quedo duda de ver si lo hiso realmente o se fue por otro camino  :-\ .

Algo que creo no se not? es que en este caso, para el GM la suma de las coordenadas Y es hacia abajo y la resta es hacia arriba, cosa que nos dar?a un resultado "ambiguo" con el clasico Fy=F sen 0, por que si la direccion es hacia arriba entonces nos dar?a un resultado positivo, el cual se le sumaria a Y y por consiguiente en el GM la direccion apuntaria m?s hacia abajo  :-[

SALUDOS

Hola, si eso es lo que suger?, solo que tienes mucha raz?n, yo lo hice para un plano usual Euclidiano pero en Game Maker esta invertido sobre el eje de las Y por lo que es muy correcto invertir el resultado de yh multiplicando por -1, por cierto, tu forma de escribir cos*dir me hace pensar que hay que multiplicar una variable llamada cos con otra dir por lo que te sugiero que mejor uses: {[()]}, Saludos!!!

knd144 y zeit: tienen raz?n, como el eje Y avanza hacia abajo, hay que restar el resultado que entrega lengthdir_y(largo,direccion) de la coordenada Y inicial. Aclarado eso, tratemos de encontrar una forma eficiente de crear personajes a base de esqueletos rotulados formados por sprites.

Cuando digo que hay que permitir el giro relativo de las partes respecto a sus "padres", me refiero a que los cuadrados puedan rotar individualmente, manteni?ndose unidos a las dam?s partes con r?tulas. El ejemplo que dejaste permite rotar las partes, s?lo que no se nota porque dejas fijos los ?ngulos (0, 0 y 90). Dejo tu ejemplo ligeramente modificado para rotar las partes con las flechas. Pero yo me refiero a que las rotaciones no sean en ?ngulos absolutos, sino relativos a sus "padres". Por ejemplo, si rotas el nodo 2 en 45?, que el nodo 3 rote autom?ticamente lo mismo; imagina un brazo que sostiene una vara inicialmente en forma vertical y rotas el antebrazo en torno al codo... la vara dejar? de estar vertical y tambi?n rotar? apuntando hacia t?, no seguir? vertical a menos que t? gires la mu?eca hacia adelante para mantener la vara vertical. Bueno, tu ejemplo hace justamente eso: deja siempre la vara en forma vertical.

Respecto a las timelines, s?, cada timeline guarda una animaci?n completa. En este momento no sabr?a c?mo ver si las timelines ocupan m?s espacio que los scripts pero si existe una diferencia, debe ser m?nima; adem?s, me parece mucho m?s ordenado guardar las animaciones en timelines en vez de varios scripts.

Voy a dejar el editable del programa que usaba antiguamente para crear animaciones de humanoides, s?lo para mostrar a lo que me refiero con rotaci?n relativa al "padre": las teclas para usarlo est?n en el game information.

Creo que ya nos alejamos bastante del tema de tu pregunta. Quiz? sea mejor tratar este tema en otra parte del foro.