Alguien conoce alguna web que te enseñe los algoritmos necesarios para la programacion de una aventura grafica estilo EL DIA DEL TENTACULO? Se que hay multitud de herramientas y kits para realizar juegos de este tipo, pero estoy buscando informacion para realizar mi propio motor.
Yo hace unos años me puse a crear un motor para crear aventuras graficas. Avance bastante pero es un trabajo inmenso y al final acabe posponiendo (o cancelando :( ) el proyecto por falta de tiempo.
Yo no me base en ningun tutorial ni en ninguna web que explicara los algoritmos usados por otras aventuras graficas, fui desarrollando los algoritmos que fui necesitando. Un algortimo existente que utilice fue el A* para encontrar el camino mas corto entre dos puntos.
Si tienes alguna duda en concreto lo mismo me pegue con ella en su dia y te puedo echar una mano.
Gracias por tu ofrecimiento.
Mas que ayuda con los algoritmos, que esta claro que tengo que usar el pathfinder, tengo dudas sobre el planteamiento de la estructura general del juego.
Todos sabemos como se estructura un juego de este tipo. Basicamente el juego consta de varios escenarios en los que en cada uno hay que hacer una serie de acciones (mirar, hablar con..,moverse, coger, soltar, activar... ) y se producen unas reacciones (cambio de variables, mostrar animaciones...).
Mi duda es: ¿Como gestiono las escenas?
Posibilidad 1)
Creo una función general para todo el juego en la que controlemos en que escenario estoy y gestiono todas las interacciones.
Posibilidad 2)
Creo funciones separadas para cada escenario y controlo solo las interacciones que ocurran en el.
Lo bueno del Metodo 1 es que no repito código pero a poco que tenga 10 o 15 estancias se lia un pitote de codigo que pa que.
Lo bueno del Metodo 2 es que el codigo queda mas claro, no mas eficiente. Y que programar eventos especiales y especificos para cada escena no alterara el funcionamiento del resto del codigo para otros escenarios.
Crear una clase de accion / reacción me parece demasiado cuadriculado para un juego de este tipo.
¿Que opinais?
Darago_malaga, normalmente se gestiona por escenas/estados. Hace tiempo escribí un artículo sobre ello, en aquella ocasión usando Python y Pygame, pero la idea de aplica a cualquier lenguaje: http://razonartificial.com/2010/08/gestionando-escenas-con-pygame/
Un enfoque parecido es este de David Saltares, en este caso usando Ogre y C++ en el que utiliza una pila de escenas (él los llama estados): http://siondream.com/blog/games/gestion-de-estados-de-juego/
Espero que te sirvan.
Yo si no recuerdo mal lo monte de forma global y por estados porque los escenarios no serian estancos y las acciones en uno podrian tener consecuencias en otros.
Si no es tu caso podrias separarlo por escenarios para tenerlo mejor organizado.
En cualquier caso no deberias repetir codigo. El codigo deberia ser unico y lo que cambie de un escenario a otro serian los datos (que acciones producen que consecuencias, eventos, dialogos, etc)
Muchas gracias Adrigm. Son muy útiles los links que me has recomendado pero creo que están mas enfocados a la gestión de las escenas de un juego, entendiendo por escena a las diferentes partes de un juego como; Menú, Pantalla de configuración, Créditos, Pantalla de juego..etc. Yo me refería a escenarios como a; Salón, pasillo, porche, jardín...
bml, gracias. A unas malas siempre puedo usar Variables Globales.
Cita de: Darago_malaga en 23 de Enero de 2013, 09:05:04 PM
Son muy útiles los links que me has recomendado pero creo que están mas enfocados a la gestión de las escenas de un juego, entendiendo por escena a las diferentes partes de un juego como; Menú, Pantalla de configuración, Créditos, Pantalla de juego..etc. Yo me refería a escenarios como a; Salón, pasillo, porche, jardín...
Es que la lógica viene a ser más o menos la misma, distintos estados del nivel de juego. Tu puedes definir dentro de estado juego otra pila de estados que sean las distintas escenas de la pantalla que estés jugando.
En mi caso, que siempre he estudiado juegos como Prince of Persia o Another World, que se juegan por "habitaciones" por llamarlo así, no dejan de ser estados de un nivel concreto del juego. Piensa en estados como si fuesen escenas realmente, por que en el ejemplo anterior, el menú principal o la pantalla de créditos no dejan de ser escenas del juego.
Salu2...
Con el debido respecto, yo intentaría usar alguno de los motores existentes. Wintermute Engine es totalmente gratuito, y con el se han desarrollado varios juegos comerciales. Te permite usar 2d o escenarios 2d con personajes 3d. Además puedes adaptarlo a tus necesidades programando pluggins etc. Permite hacer muchas cosas de forma gráfica, y el código es una variante de c++.
Yo no trataría de reinventar la rueda, sino que trataría de buscar nuevos compuestos mejores que el caucho para hacerla más eficiente.
Te doy ánimos para que sigas adelante con tu sueño; soy un aventurero de pro, y todo lo que sea solucionar las cosas por medio de la lógica tiene mi apoyo.
http://dead-code.org/home/
pruébalo, no pierdes nada.
Mucha suerte!!
Muy interesante. Le echare un vistazo. La verdad es que mi intencion era crear algo para iOS y al parecer este motor esta un poco verde en este sistema. Pero siempre es bueno ver el planteamiento que proponen.
Muchas gracias. Ire informando de los pequeños progresos que haga para buscar consejo entre las mentes del lugar.
Ahora estoy liado con el PathFinder y en su variante de NavMesh. Muy entretenido y didactico.
Yo me monté un motor de aventuras desde 0... y no te lo aconsejo. Te vas a tirar años (si, años) para que la cosa sea realmente funcional y luego casi no te quedan fuerzas para montar la propia aventura, jejeje.
Y si no te convence ninguno de los que ya hay, recicla código y algoritmos y hazte el propio. Usa un script ya hecho (no programas el tuyo), lo mismo con la busqueda de caminos, etc.
Como digo, si lo que quieres es hacer una aventura... si quieres disfrutar y aprender del proceso, adelante con ello! yo aprendí mucho muchísimo!
Gracias por el consejo Vil. Como bien dices me encuentro en el caso de crear el motor desde 0 mas que nada por el disfrute de hacerlo.
He visto que tienes un enlace a una web sobre una acebtura grafica FREGOCLES. Es tuya??? La terminaste???
Si, es mía (y de algunos amigos que ayudaron bastante) y el proyecto se canceló hace ya algunos años. Desde la misma página puedes descargar (imagino que aún puedes...) el primer episodio entero. Avanzamos bastante en el segundo... pero ahí se quedó :)
Bueno...pues de momento he finalizado el tema del PathFinder. Finalmente he optado por la utilización de NavMesh. Esto consta en delimitar la zona por la que nuestro personaje puede caminar mediante una serie de polígonos, como se muestra en esta imagen:
(http://imageshack.us/a/img59/2350/imagen1kek.png)
He simplificado los polígonos a triángulos, formados por vértices. Desde un punto de inicio (punto verde) buscamos el triangulo que lo contiene. Y luego saltamos de vertice en vertice por el camino mas corto usando el algoritmo de dijkstra hasta un triangulo que contenga el punto de destino (punto rojo). Por ultimo simplificamos el camino de un vertice a-b-c si desde a se ve de forma directa c eliminando b.
(http://imageshack.us/a/img707/2683/imagne2.png)
Te recomendaría que en vez de pasar por los vértices de los triángulos, pases por los baricentricas de estos. Más que nada para que el personaje camine por el medio del camino, y no por los bordes, que parece un fórmula uno siguiendo la trazada XD
Tienes razón en lo que dices. Y mirando la imagen que he puesto del MonkeyIsland puede parecer el metodo mas correcto. De hecho es la forma de proceder en el 99% de los sitios que he consultado. El problema me vino al ver este video:
http://www.youtube.com/watch?v=Yhqs8crnIbU
Si te fijas, al ir de un cuadrante a otro, usa el centro de la union para trazar el camino. No se...pero a mi eso me parece muy poco natural. Me parece mas natural que al doblar una esquina me acerque a esa esquina y luego busque el punto de destino. Segun esta imagen:
(http://imageshack.us/a/img46/6782/caminos.png)
El camino propuesto por el metodo del centro de la union es el rojo y el que usa los vertices seria el verde. Me parece mas logico / natural usar el verde.
Yo he usado recientemente un algoritmo lllamado funnel que crea el camino verde.... este es el link donde explica el algoritmo... http://digestingduck.blogspot.com.es/2010/03/simple-stupid-funnel-algorithm.html
Yo también vi esta pagina y la encontré muy interesante. La única duda era como se comportaria el algoritmo en una intersección. Pudiste comprobar su comportamiento en estos casos???
El único problema que se me dió es debido a:
1) que tengo en cuenta el radio del modelo para separar el camino del vértice lo suficiente para que el modelo no pase por encima de una pared.
2) Que usé cajas de tamaño maximo fijo como zonas convexas, lo que hacia que cuando lelgaba al maximo y cuando juntaba cuatro cajas e intentaba ir al vertice comun, al aplicar el radio de separacion no permitia acceder a zonas dentro de ese radio y además hacia un camino que esquivaba al vértice...
esto es fácilmente solucionable, de dos formas teniendo en cuenta que ese vértice es especial y usar un radio cero o no permitiendo ese tipo de vértices... que es lo que hago ahora...
Aquí puedes ver las cajas que genero para un mapa... cada zona delimitada con lineas verdes es una zona convexa.. y las rellenas de rojo/amarillo/azul son transitables/puertas/escaleras
(http://www.charcostudios.com/files/screen_shot_02.png)
Que chulo! Ademas usando rectangulos te ahorras un monton de calculos. Tienes razon en lo que dices de tener en cuenta el radio del modelo para no pisar en las paredes. Yo tenia pensamiento de algo al respecto. Mi intencion era adaptar la el NavMesh a la zona transitable y retraerla un poco de las paredes para que no diera la sensacion de pisarlas. Pero eso que me dices es muy buena opcion tambien.
Que duro ha sido estar todo el mes sin internet por culpa de una mudanza. Buffff!!!
Bueno pues ya estamos dando el callo un poco mas. El siguiente paso lógico ha sido añadir la animación del personaje. Este ha de mirar en la dirección en la que camina, dejar de realizar la animación de caminar cuando se para y hacer un escalado para simular la perspectiva en los escenarios. Básicamente esto lo he realizando teniendo en cuenta el valor Y de las coordenadas que ocupa y luego aplicar un factor de escala que se corresponde con el foco de la cámara en la escena.
(http://imageshack.us/a/img22/3276/conpersonaje.png)
El siguiente paso logico será añadir una imagen de fondo y gestionar los tokes en el escenario para interactuar con los objetos del mismo.
Yo tb en su dia intentçe hacer una aventura grafica y lo que hice fue crear una imagen-mascara por donde el personaje podia pasar y calculaba la colision mirando pixeles del personaje y de la mascara.
Asi pues leer esto que comentais me da ganas de volver a retomarlo, jeje.
Bueno pues tras currar un poquito os traigo algunos avances en el proyecto:
- Ahora el proyecto cuenta con fondos en los escenarios, estos pueden ser del ancho de una pantalla o apaisados, es decir que ocupan mas del ancho de la pantalla y l protagonista, al desplazarse lateralmente, la pantalla realiza un scroll horizontal. Podemos movernos entre las distintas escenas usando el procedimiento habitual de habitaciones.
- La animación del personaje se hace por animación procedural o jerárquica, usando Spriter. Que lo podeis encontrar en http://www.brashmonkey.com Un editor de animaciones 2D muy bueno y simple. Ya se comento algo sobre esto anteriormente. Se realiza un escalado del personaje para simular la profundidad en los escenarios.
- Aprovechando las funciones del NavMesh para realizar la interación con los elementos de la pantalla. Se declara una maya sobre el fondo y a cada triángulo se asocia un valor para detectar el objeto seleciconado.
- Un sistema de dialogos. Podemos mostrar textos procedentes de un fichero que puede ser modificado para poder soportar distintos idiomas.
(http://imageshack.us/a/img42/1227/mayo01.png)
- Un sistema de inventario. Podemos usar objetos con el escenario o combinar objetos entre si para obtener nuevos objetos.
(http://imageshack.us/a/img547/5852/mayo02.png)
¿Que falta? Un millón de cosas, pero a bote pronto:
- Personajes secundarios con los que entablar conversaciones complejas.
- Objetos en pantalla que puedan "taparnos"
- Efectos de iluminación
....
....
....