Comunidad Game Maker

Hola!

Hace tiempo hice una pregunta similar. Y a dia de hoy, aun no lo he solucionado. Mirando los mapas que se hacian de 8 bits (en el ejemplo Cauldron 2 de ZX Spectrum):

http://maps.speccy.cz/map.php?id=Cauldron2&sort=4&part=1&ath=

Dejo tambien la web donde salen todos los mapas. Una delicia para las capacidades de esos ordenadores:

http://maps.speccy.cz/index.php?sort=4&part=0&ath=#list

El mapa estaba dividido en habitaciones o roms (como en gamemaker). Pero cuando el personaje llegaba al final de esa habitacion, y por ejemplo, daba un salto, aparecia en la siguiente habitacion terminando ese salto. Dichas habitaciones debian estar bien planificadas. Ya que no era logico que llegara al final de esa habitacion y en la siguiente hubiera un muro. Si al final de esa habitacion saltaba desde una plataforma, en la siguiente debia haber otra plataforma para acabar el salto.

Si ibamos por una habitacion y habia un agujero, debiamos caer a la habitacion de abajo respetando la animacion y la secuencia del juego.

Os pongo un video de dicho juego pa tenerlo mas claro. Es la version de Commodore 64.

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

Lo que no veo claro, es poner nuestro personaje en cada room desde dicho editor. Me gustaria que el personaje se creara en el primer nivel del juego y que desde alli, por medio de coordenadas o lo que fuera, siguiera la logica de las habitaciones.

Es un tipo de juego que no tiene scroll. Se basa en el cambio de rooms, niveles o habitaciones a medida que avanzamos. Pero manteniendo la secuencia y logica de la animacion.

Para tu pregunta de mantener la animación entre cambios de room, puedes hacer que el objeto personaje sea persistente y así al cambiar de room mantendrá la posición en la secuencia de subimágenes.

Para tu segunda pregunta, se me ocurrió una forma de hacer que una instancia viaje a través de un mapa de rooms manteniendo las condiciones de borde de éste (es decir, que si sale por la derecha de un room luego aparezca por la izquierda del room contiguo hacia donde entra). Mi idea es la siguiente:

-Crea a mano un esquema con el mapa de los rooms para visualizar qué room está contiguo a otro. Usa las mismas dimensiones para todos los rooms
-En el objeto jugador guarda un par de variables, digamos gx,gy que representen las coordenadas del jugador respecto al mapa de rooms, considerando (0,0) la coordenada (0,0) del room de más arriba a la izquierda en el mapa de rooms.

En el evento outside room:

-Actualiza estas variables en función de las coordenadas del personaje (x,y) y del room en que se encuentra
-Determina a qué room debe ir el personaje en función de los valores de (gx,gy)
-Actualiza las coordenadas (x,y) del personaje antes de ir al nuevo room

Por ejemplo, teniendo 5 rooms llamados A,B,C,D,E agrupados en el siguiente mapa:



En este mapa se puede pasar de A a B avanzando hacia la derecha desde A, pero no se puede salir de A avanzando hacia abajo ya que no hay room bajo A. Así mismo, no debe permitirse al personaje salirse del perímetro del mapa y tendrás que asegurarte de que así sea revisando sus coordenadas o colocando muros.

En el objeto personaje coloca el siguiente código:

Create:
w=room_width;
h=room_height;
scr_actualiza_gx_gy();

Outside room:
var r;
r=-1;
scr_actualiza_gx_gy();
if gy>=0 and gy<h
    {
    if gx>=0 and gx<w
        r=A;
    else if gx>=w and gx<2*w
        r=B;
    else if gx>=2*w and gx<3*w
        r=C;
    }
else if gy>=h and gy<2*h
    {
    if gx>=w and gx<2*w
        r=D;
    else if gx>=2*w and gx<3*w
        r=E;
    }
if r=-1//no hay room hacia donde va el personaje
    {
    show_message("Fuera del escenario");
    x=xprevious;
    y=yprevious;
    exit;
    }
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);

Script scr_actualiza_gx_gy:
switch room
    {//actualiza gx:
    case A:
        gx=x;
        break;
    case B:
    case D:
        gx=x+w;
        break;
    case C:
    case E:
        gx=x+2*w;
        break;
    }
switch room
    {//actualiza gy:
    case A:
    case B:
    case C:
        gy=y;
        break;
    case D:
    case E:
        gy=y+h;
        break;
    }

Queda a tu voluntad la manera en que controlas al personaje para cambiar sus coordenadas (x,y). Para otros mapas de rooms tendrás que modificar los if y switch para abarcar las maneras que tengas de pasar de un room a otro contiguo. Nota que este método no necesita que el personaje comience en el primer room (el room A en el ejemplo); puede partir desde cualquiera.

No tengo GM8 pero en caso de que alguien use GMS adjunto el ejemplo que indiqué.

Muchas gracias. Es mas o menos lo que buscaba. He probado con GMS y funciona. Tengo la version gratuita stantard.
Como bien dices, en esos paseos por las rooms hemos de diseñar bien los niveles. Osea, no seria viable que entre A y B hubiera una pared. O que en B hubiera un agujero en el suelo y el personaje no callera a la room D.

En esta imagen usando el programa mappy se puede observar a lo que me refiero. Las lineas azules serian las divisiones entre rooms. Y al hacer el mapa de esa manera es mas dificil que nos equivoquemos entre las entradas y salidas de las rooms. Ya que en GM se suele tratar el mapa de forma individual. De room en room ¿Conoces alguna forma de crear el mapa de forma general y luego pasarlo a GM?

http://www.mojontwins.com/wp-content/uploads/2010/05/mapaejemplo1.png

Supongo que para no poner tantos if y case se deberia recurrir a arreglos y a sus indices.

Por otro lado, ¿La funcion scr_actualiza_gx_gy() es exclusiva de GMS?

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.

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.

Esa es otra solución, aunque tiene la desventaja de que todas las instancias dentro del room estarán activas consumiendo recursos, pudiendo ser necesario desactivar las instancias fuera del view.

Cita de: Jangse en Agosto 08, 2015, 07:05:20 PM
En esta imagen usando el programa mappy se puede observar a lo que me refiero. Las lineas azules serian las divisiones entre rooms. Y al hacer el mapa de esa manera es mas dificil que nos equivoquemos entre las entradas y salidas de las rooms. Ya que en GM se suele tratar el mapa de forma individual. De room en room ¿Conoces alguna forma de crear el mapa de forma general y luego pasarlo a GM?

No conozco una utilidad como Mappy para Spectrum que sirva para diseñar los mapas y luego exportarlos a GM.

CitarSupongo que para no poner tantos if y case se deberia recurrir a arreglos y a sus indices.

Por otro lado, ¿La funcion scr_actualiza_gx_gy() es exclusiva de GMS?

Se puede hacer con arreglos, aunque primero tendrás que definirlos elemento a elemento. Por ejemplo, se puede guardar en un arreglo las coordenadas de la esquina superior izquierda de cada room dentro del mapa, tomando esta forma para el ejemplo anterior:

[A  0   0]
[B  w   0]
[C  2w  0]
[D  w   h]
[E  2w  h]

Queda un arreglo donde la primera columna representa el room y la segunda y tercera sus coordenadas dentro del mapa.

Pasando esto a código:

Evento create:
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;
nrooms=5;
scr_actualiza_gx_gy();

Evento outside room:
var r;
r=-1;
scr_actualiza_gx_gy();
for(i=0;i<nrooms;i+=1)
    {
    if gx>=rooms[i,1] and gx<(rooms[i,1]+w) and gy>=rooms[i,2] and gy<(rooms[i,2]+h)
        r=rooms[i,0];
    }
if r=-1//no hay room hacia donde va el personaje
    {
    show_message("Fuera del escenario");
    x=xprevious;
    y=yprevious;
    exit;
    }
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);

script scr_actualiza_gx_gy:
for(i=0;i<nrooms;i+=1)
    {
    if room=rooms[i,0]
        {
        gx=x+rooms[i,1];
        gy=y+rooms[i,2];
        }
    }

Esta es una forma mucho más estructurada de manejar el problema ya que para cambiar la configuración del mapa sólo se requiere modificar el arreglo en el evento create.

La función scr_actualiza_gx_gy no viene como parte del repertorio de funciones de GM, la inventé yo para calcular gx,gy pues necesito hacerlo en 2 partes distintas, y su código lo indico arriba. Adjunto el mismo ejemplo modificado para funcionar con arreglos.

Excelente trabajo Guacusio!

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.

Lo de la lógica de juego lo podrías solucionar calculando en que sección del room estas e inicializando a los objetos que allí se encuentran, esto se puede hacer con un poco de ingenio pero igualmente el juego tardaría muchísimo en cargar en rooms grandes  porque debería cargar todos los objetos y el room completo antes de comenzar. Y luego al desactivar los objetos lo mismo seguiría consumiendo recursos porque tendría cargado todos los fondos, los tiles, etc no sabia q los niveles eran tan grandes y por eso di esta otra idea aunque tambien pense en esto del consumo de recursos antes de publicar mi comentario pero igualmente lo publique para dar mas opciones para toda la gente q lee estos post y quizas le pueda servir a alguien mas aunque debi haber aclarado lo del mayor consumo pero igualmente se aclaro despues. Lo de gaucusio anda de maravilla y es bueno para todos los casos especialmente para hacer los juegos en dispositivos andoid porque no derrocha recursos solo carga lo q usa y ademas iniciaría mas rápido el juego. Esta forma es la mas eficiente y al que valora eso aun en niveles chicos debería usarla. Asi que es muy bueno el Manejo de rooms y se me viene a la mente usarlo en un juego llamado prince of persia q era como del 89 o 90 por ahí, viene genial para eso.

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.

Hola ,buenas,el ejemplo lo podrias poner para  :GM8:?
Una duda que me ha surgido sobre este tema,Cuando hago el fondo a base de tiles,¿el programa carga todo el mapa,nivel?.Lo expreso para saber si puedo hacerlo tan grande como se me antoje,sin que afecte el rendimiento.
Otra cuestion,sobre mapas,¿hay alguna funcion donde teniendo un scroll ciclico pueda pegar un grafico en una coordenada del scroll?,asi no utilizo objetos,pues el grafico se pega al fondo.
Por cierto,me llamo Oscar y espero aprender bastante con vuestra ayuda .

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!

Cita de: oskarg en Agosto 10, 2015, 01:37:51 PM
Hola ,buenas,el ejemplo lo podrias poner para  :GM8:?
Una duda que me ha surgido sobre este tema,Cuando hago el fondo a base de tiles,¿el programa carga todo el mapa,nivel?.Lo expreso para saber si puedo hacerlo tan grande como se me antoje,sin que afecte el rendimiento.
Otra cuestion,sobre mapas,¿hay alguna funcion donde teniendo un scroll ciclico pueda pegar un grafico en una coordenada del scroll?,asi no utilizo objetos,pues el grafico se pega al fondo.
Por cierto,me llamo Oscar y espero aprender bastante con vuestra ayuda .

No tengo cómo grabarlo en formato de   :GM8: pero puedes copiar y pegar el código que indiqué en los eventos correspondientes del objeto jugador. Si no lo consigues aun así, avísame para ver qué podemos hacer.

Cita de: Jangse en Agosto 15, 2015, 07:17:40 PM
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!

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.

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.

Cita de: Jangse en Agosto 16, 2015, 09:03:15 AM

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.

Efectivamente, el código es idéntico al anterior, sólo cambié el origen de los sprites del personaje y agregué bloques de continuidad fuera de los rooms en las paredes que empalman entre rooms.

Cita de: Jangse en Agosto 16, 2015, 09:03:15 AM
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:

Código [Seleccionar] Expandir

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.

La sintaxis del GML es bastante flexible a la hora de escribir código. Cuando existe una sentencia que implica la ejecución de una serie de otras sentencias (como cuando se usa if, while, with, etc.), las llaves sólo son necesarias si ese conjunto de otras sentencias son dos o más. Por ejemplo:

if a=b
    c=1;//sin llaves ya que sólo es una sentencia la que se ejecuta si el if es verdadero

if a=b
    {
    c=1;//requiere llaves para englobar todo lo que se debe hacer si el if es verdadero.
    d=2;//si no se usaran llaves, sólo se ejecutaría la primera sentencia del grupo (c=1)
    e=3;
    }

Si quieres puedes usarlas de todas maneras cuando se sigue una sola sentencia en vez de varias, pero no es necesario

Cita de: Jangse en Agosto 16, 2015, 09:03:15 AM
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:

Código [Seleccionar] Expandir

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.

w y h son el ancho y el alto de los rooms (que deben ser los mismos en todos para que el método funcione). Lo que el arreglo hace es guardar para cada room (donde cada fila del arreglo está asociada a un room) sus "coordenadas" dentro del mapa general de rooms, donde por "coordenadas" me refiero a las coordenadas de su esquina superior izquierda:



Donde el arreglo bidimensional tiene esta forma:



Para que la room cambie antes de que el personaje desaparezca completamente, se requieren modificaciones importantes del código. Si quieres implementarlo de esta manera, tendrías que cambiar el evento outside room por intersect boundary y dentro de éste calcular cuál de los 4 lados del room es el que fue intersecado por el personaje para saber a qué room viajar; también tendrás que calcular las nuevas coordenadas x,y del personaje de otra forma, ya que el personaje no se moverá continuamente dentro del mapa sino que pegará un salto dentro de éste.

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