Comunidad Game Maker

Aunque parece que lo has solucionado ¿Has visto este video? Su autor esta aqui registrado y los tiene de muy buenos. Y sobre todo porque enseña GML.

https://www.youtube.com/watch?v=oTTw9CiMAGg

Cita de: Hektor en Agosto 31, 2015, 05:59:10 PM
así que lo único que puedo hacer es darte las gracias :)

Nada hombre...gracias a ti. Que eres el creador del curso. Ahora estare mas atento que entras en aguas pantanosas...el GML  :D

Cita de: Hektor en Septiembre 02, 2015, 12:20:39 AM
Gracias a los dos por la bienvenida.

En realidad yo tampoco utilizo el D&D pero quería ofrecer una introducción para aquellos que no saben programar, a partir de ahora todo será con GML. Ya tengo preparados los primeros vídeos y los publicaré esta misma semana.

La verdad es que empecé viendo varios Youtubers ingleses/americanos que van muy en serio con lo que hacen y éso me animó a hacer lo mismo, además es una forma de conseguir público potencial para tus futuros juegos lo cuál también está bien :)

Espero estar a la altura... vamos hablando  :D

Bienvenido!

Ya estaba ansioso por la serie de GML. Ya que el D&D abunda bastante por Youtube. Y como comentas, los Youtubers ingleses y americanos hacen maravillas con GML. Y tienen tropecientos videos. Con D&D, como quieras hacer algo decente, se lia un sidral con los iconos y es un rollo. Y no todo se puede hacer.

Lo que me da un poco de rabia, es que GameMaker no admita varios lenguajes como hace Unity. Ya que estoy tambien con Python y es un lio aprender dos lenguajes a la vez. Aun cuando el GML no sea excesivamente complicado. Mas bien parece un galimatias entre Pascal y Javascript.

Muchas gracias por el curso y esperando cosas avanzadas... ;)

Suscribo tus palabras una por una. Y eso que yo tampoco me puedo quejar ya que utilizo la version gratis (standard) que suministra GMS. Pero claro, si tuviera que pagar me lo pensaria muy mucho por todo lo que comentas. Ya que las ultimas mejoras que veo, son la creacion de nuevas funciones y la eliminacion de algunas que iban muy bien (sleep(), por ejemplo).

Y si, cuando editas una room, mucho zoom y tal. Pero solo puedes ver una room. Lo suyo seria poder ver un mosaico de rooms en el mismo editor. Para cuando hacemos un juego de que cada nivel es una room.

Luego, cuando quieres escoger un objeto para ponerlo en la room, muy intuitivo no es el sistema. Y para recortar los sprites tampoco es para tirar tracas. Muchos modulos la gente se busca la vida y ni utiliza los de GM. Ya que para hacer sprites o recortarlos, la mayoria tira de programas externos.

Pienso que deberian dejar un poco de la lado el GML y implementar lenguajes de toda la vida. Como unity, por ejemplo. Como minimo, el C#, Java y Python. Ya que el GML tiene una sintaxis tan abierta que te permite hacer cosas tan surrealistas como esto (y que sea lo mismo):

if a = 0
if a == 0

Osea, comparar y asignar lo traga igual.

Y erradicar el D&D.

Pienso, que de cara a futuras versiones, deberian mejorar un poco el editor de rooms. Es decir, el poder tener todas las rooms en el mismo editor. A modo de puzzle. Osea, no una room o nivel a la vez. Podriamos tener 30 o 40 rooms y de esa forma poder crear los mapas mas faciles. Que por cierto, no se por que no lleva un editor de mapas. Y no sera por las versiones que han echo de GM. Ahora con el fenomeno de la scene y retro, no todo el mundo programa para android. Pero parece que GM cada vez lo enfocan a lo mismo...a los telefonitos  XD

Sobre el hacer un mapa en un solo room, no se por que da tantos problemas. Si en las maquinas de 8 bits era perfectamente posible y para algunos juegos necesario. Por ejemplo, los que iban sobre buceo. No es logico ir pasando por el mar entre habitaciones o rooms. Y estamos hablando de ordenadores de hace 30 años.

Un ejemplo...el Titanic. Todo el juego en un nivel y mas real queda:

https://youtu.be/MxtuDahQkTc?t=27s

Y sus dos niveles o rooms (Que no son pequeños)
Nivel 1
http://maps.speccy.cz/map.php?id=Titanic1&sort=4&part=12&ath=
Nivel 2
http://maps.speccy.cz/map.php?id=Titanic2&sort=4&part=12&ath=

No tiene logica ver un pez y al pasar de room desaparezca. Cuando el mapa esta en una sola room, si el pez desaparece de la vista, lo podemos ver de nuevo si avanzamos y este pez va mas despacio.

Si un PC de hoy dia no puede mover unos niveles parecidos, apaga y vamonos...

Y como parece que se tiene que hacer todo por rooms, pues eso, que hagan un editor de mapas y faciliten el diseño. Digo yo...

Gracias de nuevo, Guacusio. Con toda esta informacion ya tratare de ir tocando un poco el codigo para ir ajustandolo al juego. Saludos!

Cita de: Guacusio en Agosto 16, 2015, 12:58:42 AM



El método que se me ocurrió es una generalización, no sirve para todos los casos tal como está. Esto se debe a que para que funcione, el origen del sprite que representa al jugador debe estar dentro de su bounding box. Ya que el evento outside room se gatilla al momento en que su mask está completamente fuera del room, es necesario que para entonces sus coordenadas x,y también hayan salido del room. En tu caso, el ejemplo no funciona porque al momento en que se gatilla outside room las coordenadas x,y del sprite siguen en el mismo room. Para solucionar esto, dejé el origen del sprite dentro del bounding box. Otra cosa importante a tener en cuenta para tu caso es el darle continuidad a las condiciones de borde de los rooms en lo que se refiere a paredes. Ya que tu engine usa gravedad, al momento de salir del room y no haber suelo, el personaje empezará a caer justo antes de hacer el cambio de room; ese pixel que alcanza a caer será suficiente para atascarlo cuando reaparezca en el nuevo room superpuesto a un objeto sólido. Por ello, recuerda agregar un bloque más de pared en los empalmes de éstas entre rooms para que el personaje no caiga antes de cambiar de room. Adjunto tu ejemplo modificado con lo que te acabo de explicar.

Muchas gracias de nuevo. Ahora funciona muy bien. Y por lo que veo no has modificado nada el codigo. Simplemente a sido poner un bloque mas en los cambios de rooms. Yo pensaba que con dar continuidad del suelo entre rooms era suficiente. Pero no, hacia falta ese bloque mas suelo (que queda fuera del editor) que hace como de puente entre ambas rooms.

Por archivos no te preocupes. He modificado el tema y el puesto el icono del GMS. Ya que tengo la version standard del mismo.

Una duda que tengo es del codigo de GML. Es un lenguaje que se puede escribir de muchas maneras y a veces crea confusion. Si te fijas, en el evento outside room hay un pedazo de codigo que lo acabas asi:

if x<0
    x+=w;
else if x>=w
    x-=w;
if y<0
    y+=h;
else if y>=h
    y-=h;
room_goto(r);

Y entre las sentencias if y else no pones las llaves. Cosa que si haces en otras partes del codigo. A mi de hecho ya me esta bien. Ya que suelo utilizar el lenguaje Python que no lleva llaves. Pero no se, si en GML,  es correcto no poner estas llaves.

Bueno, hablando del editable, ahora pondre algun enemigo para ver si respeta la animacion una vez entramos y salimos de las rooms. Que era otra duda que tenia.

Y me quedara por entender la logica de estos arreglos:

w=room_width;
h=room_height;
rooms[0,0]=A;
rooms[0,1]=0;
rooms[0,2]=0;
rooms[1,0]=B;
rooms[1,1]=w;
rooms[1,2]=0;
rooms[2,0]=C;
rooms[2,1]=2*w;
rooms[2,2]=0;
rooms[3,0]=D;
rooms[3,1]=w;
rooms[3,2]=h;
rooms[4,0]=E;
rooms[4,1]=2*w;
rooms[4,2]=h;

Osea que significa cuando hacemos 2 * w o rooms[0, 1] = 0
Ya ire trasteando a ver...

Es un codigo muy importante el que has creado aqui. Ya que es basico saber cambiar entre rooms o pantallas y respetar la continuidad del ciclo de movimientos del personaje.

Saludos!

MODIFICACION:

He añadido en la room B otro trozo de suelo fuera del escenario. Ya que cuando volvia de la room B a la room A, se quedaba trabado en la room A.

Adjunto un editable donde ya podemos pasear por las 5 pantallas. He tenido que crear entre rooms todos los enlaces de union entre rooms. Sino el personaje se quedaba trabado en alguna de ellas.

Solo me falta implementar que cuando la mitad del personaje este fuera de la room, la room actual cambie. Sino, muchas veces el personaje desaparece de la room actual y no da tiempo a este cambio de room. Aunque si seguimos apretando el boton de direccion, la room cambia perfectamente.

Hola Guacusio. He realizado una pequeña prueba del codigo que pasaste. En tu ejemplo funcionaba muy bien. Yo he realizado un pequeño test, pero no me funciona. Ha decir verdad, aun me falta entender bien el codigo que pusiste. Pero aun haciendo el copia-pega no me va.

En el ejemplo del archivo adjunto,  movemos el personaje con las teclas del cursor y salta con la tecla 'a'. Movimientos programados en el evento step. Pero si pasamos de pantalla el tio desaparece. Y tampoco se cambia de pantallo como en tu ejemplo. Se ve en pantalla pequeña pero se puede hacer mas grande. No quiero retocar mucho el codigo pusiste hasta que no lo comprenda bien.

Si puedes, echale un vistazo. Gracias!

Gracias, tomo nota de tu explicacion.

La duda venia, por que normalmente, se hacen rooms que ocupan unas cuantas pantallas. Y las views que definimos se encargan de gestionar todo esto. Osea, que al nosotros movernos se efectua el scroll hasta el fin de nivel. Pero claro, cuando cada pantalla es una room hemos de programar odo esto de lo que hablamos. Ya que en ese caso no puede existir el scroll.

Bueno, el titulo me ha quedao un poco largo...pero bueno  :-[

Cuando plantee hacer todo el mapa en una room,  era,  por que de esa forma,  los enemigos u obstaculos seguian la animacion cuando abandonabamos dicha zona.

Si hacemos el mapa divido en rooms (por ejemplo 40 pantallas) y visitamos la room del enemigo, este, tiene una secuencia. Es decir, va caminando. Si salimos rapido de esa room y volvemos a entrar ¿Es posible que dicho enemigo siga caminando respetando la trayectoria? Vamos, que de la sensacion de realidad. Me refiero que si volvemos a entrar a esa room el enemigo ya este en otro punto. No que congele su movimiento de caminar si salimos de esa room.

Lo curioso que viendo juegos antiguos (8 bits), a veces el enemigo nos perseguia entre pantallas (rooms). Me explico:

Estabamos en nuestro room y no pasaba nada. Pero al pasar a la otra habitacion el enemigo nos veia y nos perseguia entre las rooms (Y no me refiero con mapeado en scroll) .

¿Se puede programar que los enemigos nos persigan entre las rooms si salimos de donde estan ellos?

He buscado por el foro si es posible importar un mapa con un programa externo. Algunas consultas eran del GM 8 y por lo que respondia gente que dominaba el tema lo veian complicado. Pensaba si con la nueva version la GMS esto se habia solucionado o era mas facil. Ya, que es comun, hacer los mapas con otros programas para luego pulirlos con el motor que trabajemos. Queria separar este tema de otro que ya hice parecido. Ya que son dos consultas, creo, distintas.

Se supone que si importamos un mapa a GMS, luego hemos de crear instancias de objetos invisibles (que no se ven en el mapa) para crear las colisiones donde se necesiten (muros, plataformas, suelo, piedras, etc...).

Un editor de mapas que ya comente es el Mappy Win32: http://www.tilemap.co.uk/mappy.php Que tiene una version free. Y si miramos por la pagina hay un apartado que pone GameMaker y un editable de ejemplo. Aunque con extension gm6.
En ese editable esta el objeto myplane que tiene el script de la carga del mapa.

En todo caso, pensaba si con el GMS esto se habia automatizado un poco. Osea, el importar mapas de nivel.

Tambien hay un blog donde los Mojon Twins explican el uso de Mappy para sus juegos retro: http://www.elmundodelspectrum.com/contenido.php?id=833&d=Taller-Crea-tu-propio-juego-de-Spectrum-%28capitulo-3%29

EDITO:

Otra idea que se me ocurre es la siguiente:

Usamo el Tiled Map Editor. Y creamos el mapa a base de tiles. En el menu de archivo del programa escogemos exportar como imagen. Y podemos guardar el mapa como extension *.png. Luego, en GMS, creamos un sprite con el mapa y un objeto con ese sprite. Osea, spr_mapa y obj_mapa. Luego solo hemos de ir a rooms y colocar dicho obj_mapa en dicha room ¿Es buena idea?

Luego solo deberiamos crear un objeto colision (que fuera invisible) e ir colocandolo por el mapa. 

El Tiled Map lleva mas opciones de exportacion y guardado. Sobre todo la *.tmx pero no se como importarla luego al GMS.

Cita de: djboro88 en Agosto 10, 2015, 04:30:41 PM
Para GMS...
¿sabeis como hacerlo o bien algun video para GMS?

GMS es el programa. Y GML el lenguaje de scripting.

Es este video te lo explican. Eso si, en GML.

https://www.youtube.com/watch?v=NP2I81-83P0

La idea de hacer todo el juego en una room era para evitar errores de diseño. Ya que es mas facil construir el mapa por que lo ves todo en pantalla. Si construyes una plataforma en una room individual, en la siguiente room debe seguir en la misma cuadricula. Pero como dices, el sistema de Guacusio es lo mas razonable.

Cita de: fasst007 en Agosto 09, 2015, 07:27:35 AM
Excelente trabajo Guacusio!

Me uno a las felicitaciones por tu trabajo. Muchas gracias de nuevo, Guacusio  :)

Cita de: fasst007 en Agosto 08, 2015, 07:47:59 PM
También podrías hacer un solo room grande que encierre a todo el nivel y manejando los views hacer que solo se muestre una sección del mismo y cuando el personaje llegue al borde del view este se corra a derecha, izquierda, arriba o abajo una cantidad de píxeles igual al ancho del view (en caso de atravesar el lateral de la sala) o el alto del view (en el caso de atravesar el limite superior o inferior de la sala) en la dirección correspondiente. Entonces los movimientos del personaje serían fluidos y naturales y lo que daría la ilusión de cambio de sala es el cambio de ubicacion del view simplemente.

Esto ya lo habia pensado. Pero como dice Guacusio, pienso que consumira muchos recursos y se hara injugable.

Imagina que creo el mapa es una sola room. Y pido esta cantidad de habitaciones:

20 habitaciones * 20 habitaciones

Nos daria un total de 400 habitaciones (rooms). Se crearia un arreglo de esas 400 pantallas.

Si pedimos que cada habitacion (o room) haga 640 * 480 pixels la room que acogeria todo el mapa seria 12800 pixels de largo * 9600 de ancho. Es ese caso, es cierto, que no nos deberiamos preocupar por el codigo que gestionara el paso entre rooms. Ya que solamente la camara que sigue a nuestro personaje se encargaria de ir cambiando el escenario ¿No es asi?

Pero claro, en esa room de 12800 * 9600 deberiamos desactivar todas las instancias que no estuvieran en la vista. Otra cosa seria gestionar la logica del juego. Osea, que si eliminamos un enemigo este ya no apareciera de nuevo. Cosa que no ocurria en esos juegos de 8 bits. Cada vez que entrebamos en la pantalla de nuevo se refrescaba todo y estos resucitaban como si fueran vampiros. Por otra parte tambien era logico, ya que si desaparecian del todo el juego perdia un poco la gracia al no tener obstaculos en esa pantalla.