Quisiera saber si alguien me puede ayudar, tengo un problema en mi juego RPG Isometrico estoy utilizando una IA para los enemigos en la cual para el seguimiento estaba utilizando mp_potential_path, pero dado a que cuando son varios enemigos en el room se pone lento el juego es que opte por utilizar mp_potential_step, el cual a su ves funciona bastante bien para lo que necesito, el unico problema es que al esquivar alguna que otra caja solida es como que el enemigo se queda pegado por un rato en el lugar al colisionar, quisiera saber como puedo hacer para que esto no pase, osea se puede verificar de alguna manera que momento antes de colisionar la esquive asi no pasa esto o algun otro metodo. desde ya mil gracias.-
Saludos Makero the_blade:
Como bien dice la explicación de la función esta no está exenta de errores, puede fallar. Aun así dice que en la mayoría de los casos puede llegar a alcanzar el objetivo. :-[
Un posible error en tu código puede ser que el tamaño del "stepsize" sea muy grande y a en el momento de chequear colisiones ya se encuentre dentro del objeto a evitar. :-\
Una solución a largo plazo puede ser crear tus propios "scripts" de movimientos donde chequees los espacios cuadrados que ocupan los objetos. Claro esto es válido si el juego que estás haciendo se mueve según el tamaño del "tile" del suelo, o sea un "tile" es un paso. :)
Si fuera así solo tienes que crear un "array" de todo el terreno a chequear donde los números cero (0) sean los espacios vacíos, uno (1) los espacios ocupados con objetos inmóviles y dos (2) los espacios ocupados con los personajes amigos y enemigos. ;)
Cada vez que un personaje se vaya a mover, chequeará en el "array" si la posición a la que se mueve está vacía (o mejor dicho tiene un cero (0)), si ese así se mueve y actualiza los números en el "array". Este chequeo de colisiones es bueno no solo para el personaje jugador al moverse sino también para las IA enemigas para alcanzar un objetivo esquivando los obstáculos. :D
De esta manera controlas cuantas veces quieres que un enemigo chequee las colisiones y el juego no estará lento. 8)
Si tienes dudas puedes preguntar... 8)
Gracias amigo como recomiendas utilizar el stepsize en esa funcion para un optimo rendimiento? por otro lado te comento que tu metodo debe ser muy eficas aunq no se si podria adaptarlo dado que en mi juego la mayoria de las instancias tienen diferentes tamaños, por ejemplo ahy cajas, tarros y enemigos, todos de diferentes tamaños, o crees se podria hacer de otra manera mejor, no se me ocurre como hacerlo y necesito una solucion lo antes posible. gracias.-
Saludos makero the_blade:
Lo del tamaño del "stepsize" es más bien una suposición, no estoy seguro que sea eso. No he trabajado mucho con esas funciones.
En cuanto a lo de chequear el espacio por uno mismo, si tienes diferentes tamaños en los espacios que ocupan los elementos del mundo, puede ser un inconveniente. ¿Acaso no utilizastes "Snap" para colocar los objetos en el "room"? ¿En la ventana del "room", donde dice SnapX y SnapY qué número colocaste?
En caso de hayas puesto un número mayor de diez es posible subdividir el espacio y realizar por nosotros mismos los chequeos de la IA.
espero respuesta...
en la ventana del room de cada nivel tengo puesto 16x16, tienes alguna idea en definitiva me interesa que los enemigos puedan esquivar cajas, tarros y a su ves se puedan esquivar entre si porq sino se suben unos arribas de otros si me podes ayudar a implementar tu sistema te lo agradeceria muchisimo y por otro lado te mando por mensaje privado mi msn para que me agregues si es que tenes asi si podes hablamos por ese medio, un abrazo.-
Makero the_blade:
El MSN no me será útil ya que vivo en Cuba y no tengo opción de ningún tipo de chat. Las comunicaciones deberán ser a través de la ComunidadGM.
Si tienes puesto 16x16 significa que los objetos y personajes ocupan uno o varios cuadros de esas medidas. Igual puedes decir en el "array" de control de colisiones que más de un cuadro están siendo ocupados y no se puede mover a esa dirección. Da igual que un objeto ocupe uno o más cuadros, el hecho es que todos esos cuadros deben aparecer como ocupados en el "array" para chequear la colisión antes de moverse.
Esto se parece mucho al GIA Tetris, donde una ficha ocupaba más de un cuadro en el campo. Mi solución fue crear un cuadro que tomo como punto centro o pivote. A partir de él documento todos los demás cuadros que este objeto debe ocupar. Todo lo hago relativo al cuadro pivote.
Por ejemplo: este personaje "cofre" ocupa a partir del cuadro pivote, un cuadro a la derecha, otro cuadro hacia abajo y otro a la derecha y abajo, sumando todos los cuadros incluyendo el de pivote son cuatro cuadros. Cada vez que ese "cofre" se mueva a la derecha debe revisar en el "array" si sus cuatro cuadros están desocupados, entoces se desplaza y actualiza en el "array" los cuadros que están ocupados en el mundo.
Este método es muy eficiente, no carga la PC y tienes control de lo que sucede todo el tiempo.
Una cosa que se me pasó por alto es que el juego es isométrico. ¿Lo estás haciendo desde cero o ya tienes mucho adelantado? Lo pregunto porque para que en un isométrico los objetos se dibujen unos sobre otros en dependencia de la lejanía con la cámara debes tener una relación de la profundidad/posición y controlarla. Según la fila de cuadros que ocupas en el mundo será tu profundidad a la hora de dibujar. Para esto puedes utilizar el mismo "array" del que estamos ablando.
Mi opinión es que bases todo el juego en este sistema. Una vez implementado solo tienes que dedicarte a diseñar los elementos del mundo, pues las colisiones y orden de dibujado estarán controladas por un objeto controlador al respecto. El objeto que contendrá el "array" del mundo y le dirá a cada objeto su profundidad para ser dibujado...
Voy a almorzar, puedes escribir, pero responderé después de media hora...
gracias ferhand mira si el juego en si esta bastante avanzado quizas vistes algo en su momento en la seccion galeria se trata del juego The American Conqueror: The Unknow Coast, y es por eso queria utilizar algo simple como mp_potential_step pero si decis q es mas eficiente ese sistema tendrias algun ejemplo o algo cortito como para estudiarlo y ver como la adapto a mi juego si es que no es muy complicado ya que el juego tiene aproximadamente 4 niveles ya hechos y muchos objetos en el mismo.-
Makero the_blade:
Sí, he visto las imágenes y son sorprendentes su calidad. El juego tiene buena pinta, pero sin un sistema robusto pasarás bastante trabajo para organizar y controlar todo su contenido.
No te mentiré, los cambios que planteo no son "coser y cantar", levan su trabajo y análisis, pero mejorarían mucho el control de colisiones para que no se cargue la PC, te ayudarían a controlar el dibujado de profundidad, podrías generar tus propias IA sin que carguen demasiado la PC, todo eso solamente porque controlas las posiciones de los objetos sin tener que preguntarles a cada uno.
Si todos los espacios que ocupan los objetos son múltiplos de 16x16 entonces es posible hacerlo, pero no está exento de trabajo.
Es tu decisión. :-[
mira ferhand si crees poder ayudarme como para que funcione bien el sistema y no tenga inconvenientes en el juego dime q hacer o como puedes ir ayudandome, no se bien lo de los espacios porahy se podria arreglar como dices ya que por ejemplo si bien un arbol es grande por ejemplo el sprite ocupa 496x440, solo necesitaria que colisione la parte de abajo del tronco o un poco menos total lo demas no importario y objetos mas grandes como efificios porahy se podria limitar como dices con varios cuadrados aunq con que no puedan pasar por arriba ya esta osea directamente se bloquearian los border, ahora decime por favor como hago necesito una solucion lo antes posible.-
Primero lo primero:
Cada objeto de tu mundo ocupa diferente cantidad de cuadros de 16x16, esa es el área de colisiones a chequear al mover.
Cada objeto debe tener determinada el área que ocupan en el mundo. (imagen anexa)
Mañana te traigo el algoritmo que utilicé en GIA Tetris modificado para que te sirva de ejemplo...Ahora debo ir a casa. :-[
usa verificaciones de colision antes de indicar el movimiento, ya lo hice antes y funciona.
un ejemplo. (el codigo es largo)
if !place_meeting(x+lengdir_x(direction,speed*2),y+lengdir_y(direction,speed*2),other.solid)
{direction=point_distance(x,y,enemigo.x,enemigo.y) speed=8;}
else
if place_empty(x-32,y) and !place_meeting(x-32,y,other.solid)
{direction=point_distance(x,y,x-32,y) speed=8;}
else
.......
lo que haces es antes de ordenar el movimiento, verificas si en esa nueva posicion a moverse no colisiona, siendo true, es decir si no colisiona, se puede mover en la nueva direccion, de lo contrario verifica, espacios libres para desviar su camino y evitar la colision.
ferhand muchas gracias y bueno espero el algoritmo y elviskeley tambien gracias ahora decime ese ejemplo que me das es para usar con el mp_potential_step? y falta parte de codigo verdad?
Si falta gran parte del codigo, el codigo real son 157 lineas.
Esto solo era un ejemplo, o una idea, pero puedes usar grillas, controladas por alarm.
Primero lo primero:
Cada objeto de tu mundo ocupa diferente cantidad de cuadros de 16x16, esa es el área de colisiones a chequear al mover.
Cada objeto debe tener determinada el área que ocupan en el mundo. Yo particularmente lo determinaría con un "array". Dicho "array" tendría la forma de determinar todos los cuadros que ocupa dicho objeto a partir de un cuadro pivote (o de referencia) de la siguiente manera:
Representaré las columnas como "b" y las filas como "a". Tomo como pivote el cuadro rojo con la "palomita" y a partir de él redacto matemáticamente donde están los demás cuadros rojos. Un cuadro está del cuadro de pivote a un cuadro más por las columnas en la misma fila, lo que es igual a: a+0, b+1. Otro cuadro está situado debajo del cuadro de pivote lo que equivale a un cuadro más por las filas en la misma columna: a+1, b+0. El último cuadro está situado del cuadro pivote a un cuadro más por las filas y un cuadro más por las columnas: a+1, b+1.
En dicho, que estará presente en cada objeto, solo guardo las posiciones relativas al cuadro pivote del objeto en cuestión. ¿Por qué relativas a un punto? Por que solo podemos posicionar a un objeto con un punto, pero si a partir de es punto conocemos el área que ocupa, que son sus cuadros, podemos controlar si colisiona o no en su totalidad con solo un punto.
Cada vez que el objeto se vaya a mover solo moverá el cuadro de pivote a las coordenadas de GM y a partir de él preguntará si el resto de los cuadros están vacíos o no.
Para saber que espacios del mundo están vacíos o llenos tendremos que llevar un "array" a modo de matriz con los cuadros del mundo ya ocupados. Para tener todos los datos actualizados en la matriz crearemos un algoritmo que recorra el mundo una sola vez, al inicio del juego para que sitúe los objetos inicialmente y otro algoritmo que escribirá y borrará los objetos móviles cada vez que se muevan.
Las bases del algoritmo son las ya mencionadas. Ahora presentaremos los pasos que debe hacer el juego para el control de colisiones y así sabremos nosotros que debemos programar:
1 el juego se inicia por lo que el objeto controlador crea la matriz del mundo, un "array" bidimensional (array[a,b]). Recorre todo el mundo ("room") y localiza cada objeto situado en él y lo registra en la matriz cuadro por cuadro. Ya está listo para empezar.
2 Cada objeto antes de moverse debe:
2.1 verificar si está vacío el cuadro de la matriz que coincide con la posición nueva a moverse, en caso de que esté vacío debe comprobar que el resto de los cuadros que componen al objeto pueden posicionarse también. En caso de que todo de positivo debe indicarle al objeto controlador que va a moverse y este borrará la posición vieja y escribirá la nueva en la matriz. Luego el objeto ejecuta la animación de moverse. En caso de que cambie de fila en la matriz debe actualizarse la profundidad para dibujar al objeto.
Implementar todos esos pasos es sencillamente meticulosidad, nada complicado solo trabajoso. Una vez esté implementado se verán las ventajas a la hora de implementar un algoritmo de IA que busque caminos posibles, que persiga, que esquive los obstáculos, incluso que realice emboscadas con cierto grado de inteligencia.
Esto es solo lo que debe hacer el código, para programarlo solo hay que ir paso a paso para evitar errores o variables inservibles.
Sería bueno saber como tratas los niveles, si es un "room" completo o solo una parte de un "room" gigantesco. Para determinar el tamaño de la matriz a utilizar en cada momento pues podemos tener, por ejemplo: una matriz mundo grande y otra pequeña que será solo del tamaño de la "view" porque en el juego ustedes decidieron que lo que estaba fuera de la "view" no se movería ya que no es multijugador.
Necesito saber las características del juego para poder diseñar los algoritmos óptimos pues se ajustan a las particularidades de cada proyecto. A demás no tengo mucho tiempo, mi idea es que aprendan en el proceso y lo programen ustedes, así sabrán mejor arreglarlo a la hora de los errores.
Si no entiendes dímelo que estoy en línea.
muchisimas gracias ferhand dime que caracteristicas necesitas saber del juego, yo creo q aunq sea con poco de ayuda y con algunas bases del codigo voy a poder ir armandolo. porque de momento nunca trabaje con ese sistema parece muy interesante.
Saludos makero the_blade:
Necesito saber como quieres que se gestione el juego, saber como lo has hecho:
* tamaño de los "rooms"
* tamaño de las "views"
* saber si vas a gestionar todo el "room" o solo la "view" u otra área
* saber cómo se mueven los personajes, qué función utilizan, si utilizan motion_set(), move_towards_point(), etc.
* Todos los detalles globales para poder tener una idea de que vamos a gestionar...
bien ferhand te comento las room generalemente son grandes aunq las he divido en varios, de aproximadamente 6000x3000, el tamaño de las view por ahora utilizo 1920x1080 debido a la resolucion de mi monitor pero la idea es que se adapte a cada pc, todo lo que se ejecuta durante el juego se hace solo dentro de la view, todo lo que esta afuera se dashabilita, por una cuestion de mejorar el rendimiento, los personajes en primera instancia se estaban moviendo con el mp_potential_path aunq se pone muy lento por eso queria utilizar mp_potential_step, luego los personajes llevan muchisimos sprites divididos por direccion, osea en ocho direcciones y cada direccion guarda la animacion de correr, parado, atackar, herido, muerte1, muerte2, con un tamaño de sprites de 173x227, los arboles, los arboles 446x440, las cajas 91x101, un monumento 346x291 (solo te dije estos por darte algunos ejemplos de la diferencia de tamaños), la room tiene snapx y snapy de 16, pero porque esta predeterminado asi de eso no cambie nada, y el personaje principal se utiliza tanto para enemigos como jugador y con una variable diferenciamos y a su vez en el evento endstep seteamos todos los sprites, acorde al tipo de personaje, a su vez tiene una maskara de 41x50. y bueno no se que mas decirte.-
Saludos makero the_blade:
Revisando el GM, en l asección de edición de "rooms" me percaté de una pregunta que no te había hecho:
¿Cuál es el ángulo del "sistema isométrico" utilizado por ti? Me explico:
Un cuadro de un sistema isométrico tiene sus cuatro lados iguales, pero la línea que lo cruza de arriba hacia abajo es más corta que la línea que lo cruza de un lado a otro.
Para haber construido un sistema isometrico debes haber utilizado un tamaño de cuadro común para todas las piezas. Ese es el cuadro que utilizaremos para la matriz y para las colisiones. Esa es la medida que estoy necesitando: La dimensión de las líneas que cruzan los cuadros bases que conforman el área de superficie de los objetos.
En las imágenes que te envié se muestran los cuadros de que hablo; serían los rombos de colores que formaban el área que ocupaban los objetos cilindro y pared de la imagen.
Saludos ferhand en realidad te comento que para implementar el sistema en si si bien creo que se ve bien no hice nada complicado simplemente dicha perspectiva esta ajustada desde el modelador 3D, en el mismo programa de diseño que utiliza (Blender 3D), y luego las imagenes ya me las envia en esa perspectiva, entonces lo unico que hago es editarlas y cargarlas en el game maker, y a cada objeto le doy profundidad con el codigo este:
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//Profundidad Del Objeto
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
depth=-Z;Z=y
en el evento Create.-
Makero the_blade:
En un entorno 3D, el hecho que tenga vista isométrica es por el ángulo de la cámara con respecto a la superficie del suelo. Pero en un ambiente 2D las bases de los objetos son rombos, más largos que altos, para dar la sensación isométrica. Siempre la base es una figura romboide y las medidas que las cruzan son las utilizadas para colocarlas en el mapa, desplazarlas o chequear colisiones.
Si realizaste las imágenes en un editor 3D, lo más probable es que no tengas las medidas que te pido, pero estas pueden inferirse de las imágenes ya creadas. ¿Cuando tomas las fotos de los elemento 3D las tomaste desde la misma altura? ¿No acercaste o alejaste la cámara de los objetivos? Si todos los elementos 3D fueron tomados a la misma distancia significa que todos tienen las mismas medidas en los rombos que conforman las bases. Podemos determinar por comparación las medidas mirando tres imágenes distintas en tamaño en el editor de GM.
Puedes pasarme tres imágenes para intentarlo o puedes hacerlo por ti mismo. Es sencillo:
1 Toma una de esas imágenes y a través del editor de imágenes de GM, colócale el centro en la esquina izquierda de la posible base de la imagen.
2 Crea un objeto y después de adicionarle la imagen, ponlo en un "room".
3 Luego selecciona la opción de ver las cuadrículas en perspectiva y comienza a cambiar el tamaño de las mismas hasta que veas que las líneas coinciden con los bordes de la base de la imagen.
4 Repite todo des el principio pero con otra imagen y con otro objeto en el mismo "room", hasta terminar con las tres imágenes y ya tendrás las medidas del rombo. El resto es puro Pitágoras.
Puedes hacer como quieras, pero si me envías las imágenes hoy tendré el resultado para el Lunes, lo peor es que tendrías que enviarlas antes de una hora pues se cierra el centro de trabajo y me voy a casa.
Como prefieras... ;D
como bien dijistes ferhand no tengo dichas medidas, dado que el ajuste isometrico lo hace mi hermano desde el editor 3d, por eso opte por enviarte dichas imagenes dado que si implementas tu sistema seguramente sera un modelo a seguir para ya instalarlo en mi engine y utilizarlo asi, aqui te adjunto las 3 imagenes en formato de game maker.-
Makero the_blade:
Creo quwe tengo ya la medida que utilizaremos en la matriz de tu juego.
Aquí te envío un editable con un "room", mira en la edición del "room" las medidas de los rombos a utilizar...
perfecto ferhand ahy lo vi es 98 x 49 y me parece perfecto porque de hecho nunca habia utilizado o prestado atencion al tema de las grillas y creo que tenes razon puede ser la medida correcta, estoy seguro que con ese sistema va a quedar perfecto.-
Saludos makero the_blade:
Ya sabemos las medidas de los cuadros de la cuadrícula. Todos los niveles deben tener medidas que sean múltiplos de esos números [98 px x 49 px]. La matriz que crearemos será una representación "cartesiana" de esas posiciones, las filas y columnas de la matriz se multiplican por estos números y tendremos la posición en el "room". Por ejemplo:[a,b]=[filas, columnas] La cuadrícula [1,1] está ne la posición[1*98, 1*49] = [98, 49], la cuadrícula [2,3] está en [2*98, 3*49] = [196, 147]
Solo debemos acceder al valor guardado en la matriz para saber las posiciones que están ocupadas o vacías. Para saber la posición en el "room" solo debemos multiplicar las medidas de los cuadros por las filas y columnas de las posiciones chequeadas.
Una limitante en este sistema es que en un cuadro solo puede estar un objeto y un objeto solo puede estar en un cuadro. Con esto quiero decir que si en tu sistema un personaje pudiera caminar medio cuadro en este puede caminar como mínimo un cuadro de 98 x 49 completo. No puedes estar con una mitad del cuerpo en un cuadro y la otra mitad del cuerpo en otro cuadro. Esto tal vez cambie la forma que tienes de desplazar los objetos.
En caso de requieras que un objeto personaje pueda posicionarse a mitad entre un cuadro y otro debemos tener entonces otras medidas de cuadro, una que coincida con el tamaño del paso de los personajes. ¿Esto es sí? ¿Cómo funciona el desplazamiento en tu mundo? ¿Se avanza un cuadro completo en cada paso o la medida de recorrido está dada por otros valores? ¿Caminan también en diagonal? Se que deben caminar en diagonal pues me comentaste que un "sprite" de un personaje tiene ocho posiciones.
Necesito saber las respuestas a estas preguntas para entender mejor las peculiaridades de este mundo.
estoy en línea... ;D
bien ferhand en si te comento los personajes se mueven en ocho direcciones, y si en diagonal tambien y respecto a lo que dijistes te diria que seguramente en mi juego seria necesario que a veces pisen en la mitad de algun recuadro por el ello que como tiene animacion cuando corren si caminas de a cuadros grande seguramente no quedara acorde la animacion con lo que avanza, y por otro lado tene en cuenta que si te basas en los sprites para las medidas de los recuadros quizas tienen un recuadro grande por ejemplo los sprites de los personajes por una cuestion de que como las animaciones estan divididas por direccion, entonces por ahy pasas que en un mismo sprite tenes la animacion de parado la cual no requiere un cuadro tan grande si le recortamos los bordes, pero no puede ser asi porque la animacion de muerte ocupa mas espacio en el recuadro, es entonces para que entre todas las animaciones bien que se opto por esa medida de recuadro en los sprites y no se recorto tanto.-
te paso un ejemplo que baje capas lo podes adaptar porque no se si se adapta al sistema que me estas planteando, es mas seguro tu sistema es mejor.
cualquier cosa si conseguis armas algo o cualquier cosa avisame ferhand yo ahora tengo que salir pero mañana me conceto todo el dia a ver si podemos solucionar este sistema. muchas gracias.-
ferhand de acuerdo a lo que preguntabas de los movimientos, bueno te adjunto una imagen del personaje principal moviendose de costado, y te cuento que se mueve el personaje sumandole a x 10, osea x+=10 al pulsar la tecla derecha por ejemplo, te la adjunto asi podes probar y verificar que quede bien la animacion acorde a lo que avanza. salu2.-
Makero the_blade:
Sabiendo que necesitas posicionar un objeto personaje entre dos cuadros de los ya mencionados no utilizaremos esa medida de cuadro para desplazarnos.
Si queremos un sistema de colisiones eficiente debemos tener menos puntos que recorrer para chequear. La matriz era para eso, cada 98 x 49 píxeles se contarán como uno solo y el recorrido se reduce considerablemente. Además el chequeo se limita a solo conocer el valor de una celda de un "array" que es mucho más eficiente que chequear si en ciertas coordenadas hay un objeto y tener que revisar todo el "room".
De la medida que lo vayamos a realizar, al menos los objetos estáticos como muros y casas deben estar posicionados con cierta relación. Osea deben corresponder a algún sistema de cuadrícula (grilla) que escojas, no pueden estar posicionados al azar. Es posible que tengas que mover muchos objetos inmóviles de lugar para lograr esto. De esta forma utilizaríamos la cuadrícula para saber las posiciones ocupadas y crear un camino ("path"). Un camino se puede crear con un nodo de partida, otro de llegada y el tamaño del nodo (cuadro, paso). Si tenemos una matriz ("array") que contiene las posiciones de los objetos es más fácil determinar el camino, el problema es el tamaño del nodo (cuadro).
No tiene desplazarse todo el nodo en un solo paso, este se puede recorrer en varios pasos, pero si evitará todo un nodo en el que haya algún objeto a evitar. Le pasará a un nodo de distancia a no ser que la medida sea más pequeña, como por ejemplo un cuadro de 98 x 49 px esté compuesto por cuatro cuadros del tamaño de un cuarto de un nodo. En este caso cambiaríamos el tamaño de nodo a uno más pequeño y listo funciona igual.
Repito, no tenemos que desplazar los objetos tanto espacio, pero sí necesitamos una medida que contenga a todos los objetos del mundo. Una medida con la cual se pueda decir dónde está cada objeto del mundo, sin importar que un objeto ocupe varios cuadros él solo y otro objeto ocupe solo ocupe uno de esos cuadros, eso sí, la medida debe ser de carácter general, sin excepciones.
Veré si veo otra medida en casa con las imágenes que me mandaste. ;D
PD: ¿Escogiste el tamaño del paso del personaje según la velocidad de animación? ¿Qué acaso eso no lo escoge el programador y no el "sprite"? Con esa calidad de imágenes solo necesitan un buen motor no necesitan estar haciendo el juego según lo que tienen, sino según lo que quieren.
La animación no debería ser una medida de avance. Ustedes deben escoger la medida que se ajusta a su sistema. Por lo que me dices el objeto camina 10 px en cada paso, pero ¿es esa la medida del área que ocupa en el mundo? ¿Él entonces se desplaza menos distancia que el área que ocupa?
si ferhand por eso necesito tu ayuda para implementar el sistema, y bueno la idea es que el engine sea lo mas rapido y dinamico posible y en cuanto a la animación que me decis de cuando corren, por supuesto que la velocidad la definimos nosotros los programadores, lo que yo te queria decir es que quizas si tomabas el tamaño de las grillas para los avances por ahy quedaba mal, osea supongamos pulsas la tecla derecha y reproduce la animacion de correr normal pero avanza de a dos cuadros por ves y entonces en lugar de correr daria la sensacion de que hace un salto en largo, pero era solo una suposicion por eso te pase un ejemplo de animacion asi de esa forma vos vas a poder buscar quizas con las medidas que ya definistes la forma de que el personaje se mueva de manera correcta y acorde a la animacion que reproduce y lo haga de manera fluida, y de hecho si conseguis eso ya estaria casi listo porque todos los personajes tienen practicamente la misma animacion cuando corren, disparan o se mueven. bueno ferhand no veo la hora de que pongamos en funcionamiento tu sistema ya que como dices teniendo un buen sistema todo seria mas rapido y efectivo.-
PD: seguramente como me dijisten en su momento una ves que definas bien el sistema voy a tener que cambiar la posicion de varios objetos y adaptarlos acorde a las grilla seleccionada, de hecho va a ser asi porque dado que no tenia experiencia en este tema y gracias a vos me estoy interiorizando, todos los objetos estaban ubicado en el escenarios medio al azar, osea de acuerdo a como me gustaba pero no respetaba ninguna grilla y seguramente fue por eso que tenia problemas con las colisiones cuando utilizaba path o petential_step.-
Saludos makero the_blade:
La pregunta es ¿qué medida de avance quieren para su juego? Debo saber la medida para ajustar el diseño a ella.
La matriz de colisiones la usaremos para determinar las áreas que están desocupadas. Debemos determinar ya una medida que ajuste lo más posible al tamaño de paso de los personajes. Si el tamaño es muy pequeño la búsqueda en la matriz se hará más lenta, pero la precisión a la hora de realizar los chequeos será igual de sólida.
Otro cambio es que los objetos estáticos como casas y árboles sean dibujados en los niveles por un solo objeto. Este objeto solo dibujará los objetos que estén en la "view", el resto no, así se agilizará el procesado del juego.
Son cambios substanciales. Ahora mismo estoy mirando las imágenes para seleccionar un tamaño de paso posible.
hola ferhand si queres utiliza la medida de avance que dijistes en un principio o otra que te paresca adecuada de acuerdo a las imagenes que te mande y de ultima si en algun monto ubiera que cambiar dicho tamaño por algun motivo calculo que no deberia ser tan complicado, en cuanto al dibujado de objetos desde uno solo habira que implementarlo pero por ahora lo que mas me interesa es aplicar la IA ya que en unos dias tengo una expo aca en mi ciudad y quieren que mostremos un demo del juego y lo idea seria poder mostrar el demo con este sistema ya listo por una cuestion de que no seria adecuado mostrar el juego y que tenga fallas o que los personajes caminen por arriba de las casas.jajajajaj. Saludos.-
FERHAND aca te adjunto imagenes completas de animacion del personaje de costado asi ves todo lo que hace cada una de las animaciones y de ahy calculas las colisiones, los tamaños y eso y calcula que para todos lados es generalmente igual salvo arriba y abajo que quizas se acorta un poco la imagen por la direccion en la que se hallan, espero con eso encuentres la solucion ya que necesito implementar el sistema lo antes posible. gracias.-
Saludos makero the_blade:
Disculpa nuevamente por los retrasos y las faltas de ortografía, esta PC que estoy utilizando hoy no tiene corrector para el español. :-[
Como habíamos acordado, las medidas de 89 x 49 px son las medidas optimas para nuestra cuadricula (grilla). Ese sera el espacio menor que ocupara cualquier unidad. El área de un elemento puede ocupar uno o mas cuadros de dicho tamaño. Ejemplo: Una casa, un segmento de un muro, un personaje, etc.
Los elementos que son fijos, no tienen animación, no requieren de un objeto por cada uno para ser representados. Un solo objeto puede encargarse de el dibujado de todos los elementos fijos. Estos elementos no se moverán de su sitio por lo que las posiciones en la matriz serán fijas. Estos a su vez se pueden dividir en dos grupos:
* los que no colisionan con nadie
* y los que son obstáculos, o sea colisionan con todos.
Estas diferencias debemos marcarlas en la matriz para que al chequera las posiciones en busca de posibles colisiones se detecte a tiempo los objetos obstáculos. Por ejemplo: un numero cero (0) para las posiciones en blanco, un numero uno (1) para los elementos que no colisionan, un numero dos (2) para los elementos obstáculos que no se mueven ni tienen animaciones, un numero tres (3) para los elementos obstáculos que no se mueven pero si tienen animaciones, un numero cuatro (4) para los elementos obstáculos que son móviles pero no causan daño, un numero cinco (5) para los elementos obstáculos que son móviles y si causan daño, etc...
Por supuesto ya hemos hablados de los elementos que causan daño, que son móviles, que son obstáculos, etc. Todos estos elementos ocupan uno o varios cuadros de 89 x 49 px.
Actividades a realizar:
* Crear un nivel para pruebas con los elementos colocados en un "room" que tenga una cuadricula isometrica de (89px x 49 px). Tener en cuenta que los espacios transitables entre los elementos obstáculos debe ser de un cuadro o mas. Ningún espacio para pasar puede ser menor de estas medidas.
* Crear un objeto controlador que se encargara de contener la matriz, dibujar los elementos fijos, etc.
* Agregar una matriz área ("array") a todos los objetos que representan elementos en el mundo. Dicha matriz contendrá todos los cuadros que ocupa dicho elemento. En el espacio [0,0] se colocara la cantidad de cuadros total que ocupa dicho objeto, el resto de los espacios los explicare con un ejemplo en .gmk.
* Crear un "script"que reciba la posición (X e Y) de un objeto y el cuadro a chequear colisión (con dos números) y que sea capaz de devolver el tipo de colisión posible en el cuadro indicado. Ejemplo:
argument0 = # // valor de coordenada X del elemento
argument1 = # // valor de coordenada Y del elemento
argument2 = # // valor de desplazamiento a partir del cuadro pivote del elemento
argument3 = # // segundo valor de desplazamiento a partir del cuadro pivote del elemento
return # // el numero que esta guardado en la matriz en dicho cuadro. (0, 1, 2, 3, 4, etc)
nota: este "script" sera reutilizado pues determina en un cuadro indicado que elemento se encuentra para realizarle transformaciones. Ejemplo: al moverse comprobar si se puede mover en la dirección de ese cuadro, al atacar comprobar si golpeo en esa dirección, etc.
Lo difícil de explicar es el hecho de guardar en un "array" los cuadros ocupados por un elemento en forma de referencia a partir de un cuadro determinado como pivote. El cuadro pivote sera el cuadro (espacio de la imagen) al que se le colocara el centro de la imagen en el editor de GM. Cuando se posicione en el "room" el objeto sera por estas coordenadas. El resto de los cuadros que ocupa se escribiran relativos a este cuadro, por ejemplo: un cuadro mas arriba, dos cuadros a la derecha, etc. Claro se escribiran de forma matematica, con numeros. La importancia de esto es que no importa donde se coloque el elemento siempre sera posible determinar los cuadros que lo componen necesitando solo este "array area" y la posicion (X,Y) del elemento.
Esto sera mejor con un ejemplo, por lo visto tendré que programar... :'(
Eso si, con estas medidas el tamaño del paso al desplazarse sera del tamaño del cuadro de la cuadricula (89 x 49 px) o sea un objeto caminara desde una cuadricula a otra, nunca se detendrá en el intermedio. Esto lo veo en muchos juegos en aras de gestionar mejor las colisiones y el orden de dibujado...
Si esto les parece bien... solo queda ponernos manos a la hora...
PD: dame un tiepo para el envío del ejemplo con las matrices, los tipos de objetos posibles, etc.
Ferhand me parece perfecto y si quiero tener ese sistema en mi juego, lo unico que te pido es que una vez que me pases el editable si no logro entender algo por favor me ayudes a adaptarlo a mi engine asi ya estaria todo listo. y bueno nuevamente muchas gracias amigo y bueno espero el editable entonces. un abrazo.-
Saludos makero the_blade:
Aca te dejo la primera parte del editable para que comprendas mas o menos por donde empezar.
En el se expone una pequeña matriz de 6 x 6 cuadros donde se colocan a cero (0) los espacios vacíos y a uno (1) los espacios ocupados por los bloques.
Trata de recorrer el código que es lo básico para emprender este sistema. Si tienes dudas redactalas y te las contesto mañana.
Un abrazo... ;D
ahy lo pruebo ferhand gracias.-
PD: ahy lo probe mas o menos por lo que vi generastes una matriz, donde los 0 son espacios vacios y 1 los ocupados y dibujastes una caja en la primera posicion de la grilla, con el tamaño de 98x49 verdad, en el segundo room no entendi bien que es lo q hace por lo visto solo colocastes graficos en la grilla, ahora se supone q todo lo que cargue en el room sera a atraves de codigo verdad, osea cada objeto del juego sera colocado desde codigo verdad, o exite la posibilidad de alinearnos acorde a la grilla definida en el room desde el mismo editor y desde codigo verificar que ese espacio donde se halla determinado objeto por ejemplo esta ocupado? eso haria mas facil la edicion de mis rooms. salu2.-
Cita de: the_blade en Octubre 16, 2012, 10:36:08 PM
ahy lo pruebo ferhand gracias.-
PD: ahy lo probe mas o menos por lo que vi generastes una matriz, donde los 0 son espacios vacios y 1 los ocupados y dibujastes una caja en la primera posicion de la grilla, con el tamaño de 98x49 verdad, en el segundo room no entendi bien que es lo q hace por lo visto solo colocastes graficos en la grilla, ahora se supone q todo lo que cargue en el room sera a atraves de codigo verdad, osea cada objeto del juego sera colocado desde codigo verdad, o exite la posibilidad de alinearnos acorde a la grilla definida en el room desde el mismo editor y desde codigo verificar que ese espacio donde se halla determinado objeto por ejemplo esta ocupado? eso haria mas facil la edicion de mis rooms. salu2.-
Saludos makero the_blade:
El otro "room" fue solo para determinar las medidas de la matriz. :-[
En el editor de "rooms" lo que colocamos son objetos con o sin "sprites", pero objetos en sí. Lo que queremos es tener la menor cantidad de objetos en el "room" y que un solo objeto dibuje los elementos no móviles, para eso necesitamos guardar las posiciones donde va cada uno de ellos. Incluso, si te fijas mejor verás que el ejemplo es solo para elementos de un solo cuadro. En el caso de que un elemento tenga más de un cuadro debemos tener otros datos según el tipo del elemento. Datos como: un identificador para cada tipo de elemento, una matriz donde se guarde la cantidad de cuadros que tiene dicho elemento y el desplazamiento del resto de los cuadros a partir del cuadro pivote. Esta última matriz se utilizará para cuando se vaya a colocar un elemento en el "room" se puedan colocar todos los cuadros de los que está compuesto.
Esto es un poco difícil de entender, déjame realizar un ejemplo editable de un objeto con varios cuadros. :-[
Tienes razón, será más complicado editar los "rooms" de esta forma, pero es el precio a pagar por tener mejor eficiencia. Una manera que yo utilizo es crear un objeto con cada imagen a colocar y colocar los objetos en el "room" como quiero que queden. Luego determinar cual fila/columna ocupa el cuadro pivote de cada objeto y esa será la posición para rellenar en le matriz. Los niveles serán lentos de diseñar, pero más eficientes. 8)
Ahora debo irme a casa, hablamos mañana...Disculpa, pero parece que no habrá tiempo para tenerlo todo el día 20... :'(
gracias ferhand si es seguro de que no llegamos para ese día asi que no te hagas drama por ahora opte por el sistema de path comun y corriente el cual para esta expo va a andar bien y bueno cuando mas o menos lo tengas vemos asi lo implemento en el juego pero mas tranquilo. nos vemos.-
Saludos makero the_blade:
Ahora mirando mejor el ejemplo encontré un error que yo ya sabía que debía tenerlo en cuenta, pero se me pasó. Los valores (X,Y) para mostrar los elementos en el "room" no son afines a todas las filas. Al ser isométrica la cuadrícula las filas consecutivas no coinciden en la misma columna. Por ejemplo las filas pares coinciden las columnas entre sí pero no con la impares y las filas impares coinciden entre sí pero no con las pares.
Eso debe estar reflejado a la hora de mapear de una celda de la matriz a una posición del "room". Lo tendré en cuenta en el ejemplo próximo.
disculpa la demora, hermano... ya se que lo implementaremos con tiempo, aun así me siento presionado... :-[
Muchas gracias ferhan y no te sientas presionado no es tu responsabilidad ayudarme, asi que si en algun momento te aburres lo entendere. saludos amigo y gracias por la atencion.-
Saludos makero the_blade:
Esta es la actualizacion... 8)
...Espera proximo ejemplo... ;D
Dale ferhand ahy lo pruebo gracias..
ferhand respecto a lo que me pedistes por mensaje privado te comento que porahora no tengo objetos animados en el escenario mas q los personajes como el que te mande, lo demas son edificios arboles, etc pero graficos fijos por ahora.-
Cita de: the_blade en Octubre 22, 2012, 11:35:09 PM
Dale ferhand ahy lo pruebo gracias..
No olvides preguntar... XD
ferhand por lo que estoy viendo el codigo lo que hace es dibujar desde un solo objeto los sprites diferentes y los objetos que tenes ahy no lo estas usando verdad? osea dibujas el sprite y a su vez comprobas si determinada area esta ocupada por dicho sprite?
Cita de: the_blade en Octubre 23, 2012, 12:07:33 AM
ferhand por lo que estoy viendo el codigo lo que hace es dibujar desde un solo objeto los sprites diferentes y los objetos que tenes ahy no lo estas usando verdad? osea dibujas el sprite y a su vez comprobas si determinada area esta ocupada por dicho sprite?
Saludos makero the_blade:
Es cierto que dibujo los elementos a través de un solo objeto. Este objeto lee de la matriz los valores y a partir de ellos dibuja. Pero no he chequeado aun si el espacio está ocupado.
Para chequear si un espacio está ocupado solo tengo que entrar en la matriz y ver el valor de esa celda, según el valor estará ocupa o no y puedo saber por quién. Solo necesitas escoger una numeración para los diferentes elementos visuales. Mi propuesta es que escojas números enteros y que escojas un rango continuo para los elementos con colisión.
Esos números enteros serán un número por cada elemento. Por ejemplo: arbol=1, caja=2, casa=3, muro=4, etc. Esos números enteros corresponden con un cuadro, el cuadro pivote, en caso de que un elemento tenga más de un cuadro se utilizará el numero fraccionario. Por ejemplo: casa=3, pero está compuesta por cuatro cuadros en total por lo que el resto de los espacios en la matriz ocupados por la casa tendrán el valor= 3,5. En la matriz se verán cuatro celdas para la casa una con el valor 3 y el resto con los valores 3,5.
¿No se si entiendes?
Necesito alguna imagen con más de un cuadro de área para el próximo ejemplo. Yo mismo me encargaré de crearle alguna animación para ejemplificar también el dibujado de subimágenes.
hola ferhand si entendi perfectamente osea es facil con numero como dices dado que en alguna parte del codigo con comentarios especifico cada numero con cada objeto y cualquier duda de a que objeto pertenece cada numero me fijo en esa parte y listo y por otro lado lo de las fracciones tambien esta barbaro por que con los valores despues de la coma se entiende claramente que son las celdas de mas ahora que las verificara siempre hacia la derecha verdad ose si ponemos 3,4 sera una casa con 4 celdas de izquierda a derecha?
aca te paso un grafico de mas de una celda
Cita de: the_blade en Octubre 23, 2012, 10:06:41 PM
hola ferhand si entendi perfectamente osea es facil con numero como dices dado que en alguna parte del codigo con comentarios especifico cada numero con cada objeto y cualquier duda de a que objeto pertenece cada numero me fijo en esa parte y listo y por otro lado lo de las fracciones tambien esta barbaro por que con los valores despues de la coma se entiende claramente que son las celdas de mas ahora que las verificara siempre hacia la derecha verdad ose si ponemos 3,4 sera una casa con 4 celdas de izquierda a derecha?
aca te paso un grafico de mas de una celda
Saludos makero the_blade:
Lo de los números enteros es correcto, pero lo de las fracciones es solo para determinar que no es el cuadro pivote y sí corresponde a tal elemento. Por ejemplo: casa_pivote=3; casa_nopivote=3,5; muro_pivote=2; muro_nopivote=2,5. No debemos colocar el numero de cuadros para cada elemento en la numeración de la matriz o de lo contrario deberíamos tener un orden para determinar los cuadros no_pivotes.
De la forma en lo que tengo pensado los cuadros no_pivotes pueden ser determinados en cualquier orden y no implica error. En un final solo están expresados en relación al cuadro pivote, ese es su punto de partida.
El representarlos separados es para conocer a partir de cual cuadro tomaremos la referencia para colocar, mover o eliminar cualquier elemento.
Disculpas makero the_blade:
Acabo de darme cuenta de otro error solucionable. Los elementos formados por más de un cuadro tienden a ser invadidas sus áreas por otros elementos a la hora de ser dibujados en pantalla. Esto sucede con aquellos elementos cuya área de superficie no es convexa. En el ejemplo que estaba preparando el área que utilicé no es convexa, o sea que cada vez que trace una línea sobre su área no solo tocaré a los bordes en dos puntos. La razón es sencillamente que estamos representando objetos de dos dimensiones como si fuera en tres.
Las soluciones recomendadas son:
1 Que todas las áreas de los objetos de varios cuadros sean áreas convexas.
2 Que los elementos de varios cuadros sean divididos en varios cuadros separados y que la suma de sus partes conforma la imagen inicial.
La primera solución debe traer consigo que el punto de pivote esté localizado lo más al centro/derecha del área posible. Si los gráficos utilizados son de área convexa no habrán problemas.
La última solución puede traer beneficios gráficos posteriores, pero es más trabajosa ya que tendrían que cambiar todo los gráficos del juego.
Cada solución es excluyente.
Mi pregunta es la siguiente:
¿Son convexas las áreas de todos los elementos visuales de varios cuadros que han creado para vuestro juego?
¿Deseas que el ejemplo lo realice con la primera solución o con la segunda?
Adjunto el error y una imagen sobre la convexidad.
Saludos makero the_blade:
Anoche arreglé el ejemplo con una imagen un poco más convexa. :D
Ahí subo el ejemplo. Espero lo revises y me envíes las dudas, mientras le agregaré el control de colisiones a la matriz. :)
Luego del control de colisiones ya estaremos listos para implementar una simple IA. 8)
Te pido mil disculpas por la demora. :-[ :'( :-[ :'(
He tenido inconvenientes en el trabajo, mucha carga, ahora estoy un poco más libre. ;D