Comunidad Game Maker

Te adjunté un archivo fuente que puedes descargar. Con la idea del comentario anterior hice un pequeño script llamado  "igual" que verifica si dos valores pasados por parámetros son iguales y devuelve "true" si lo son y "false" si no lo son. Aquí su código:

epsilon = 0.0001;

if((argument0-argument1) < 0)
   return((argument1-argument0) < epsilon);
else
   return((argument0-argument1) < epsilon);
   
y en lugar de:

if( r!=r1 or r!=r2 or r!=r3 ) show_message("radio incorrecto"); 

(en el script scCirc) lo reemplazo por su equivalente pero con la función nuestra:

    if !(igual(r,r1) and igual(r,r2) and igual(r,r3)) show_message("radio incorrecto");

y parece que funciona.

Tengo dos alternativas, la más rápida sería la segunda pero de todas formas las listo a las dos:

PRIMERA ALTERNATIVA
¿la función abs es lenta? porque podrías comparar de la siguiente manera:

en lugar de: if (a == b) podrías hacer:

Primero definir una tolerancia o epsilon, como por ejemplo:0.0001;
if( abs(a-b) < 0.0001)

esto sería como decir: la diferencia entre esos dos valores numéricos es menor a 0.0001, si lo es entra en el if considerándolos iguales.

SEGUNDA ALTERNATIVA
sino tambien sin usar abs:

diferencia = a-b;
if (diferencia < 0) diferencia *= -1;

if (diferencia < 0.0001)
{

}

o incluso mejor, ahorrando un cálculo de multiplicación y una escritura de menos en la variable diferencia:

if ((a-b) < 0) 
    diferencia = b-a;
else
    diferencia = a-b;

if (diferencia < 0.0001)
{

}


lo que no llamaría a ninguna función. Esto sería muy rápido.

Y como última alternativa quedaría que luego de diferencia = a-b; quitarle el bit de signo a la variable diferencia mediante alguna operación de bit (primero hay que saber la estructura interna de las variables numéricas de game maker) antes de hacer la comparacion . Pero creo que sería innecesario complicarse, el último código dado sería muy rápido.

Hola acabo de hacer un código en Game Maker Studio para que lo veas.

Hice tres room, una para la pausa llamada "sala_pausa" y otras dos llamadas "sala_1" y "sala_2"

La sala_1 y la sala_2 tienen ambos un objeto, mas concretamente una pelota.
El de la sala_1 es de color rojo y al iniciar el room aparece en la esquina superior izquierda del mismo. El de la sala_2 es de color amarillo y aparece en su esquina inferior derecha.
También los fondos de los rooms son distintos para diferenciarlos.

Estas dos salas están marcadas como "persistente" que creo que así debes tener tus rooms.

La idea es que puedes cambiar la posición de las pelotas con el mouse para dejar la sala en un estado, probar la pausa y cuando elijas la opcion que quieras (continuar o reiniciar) veas los resultados. El de continuar debería llevarte a la sala que habías abandonado y con la pelota en el mismo lugar y reiniciar debería aparecer en esa sala pero con la pelota en la posición inicial. Funciona, puedes ver el código e implementarlo en el tuyo.

El juego tiene las instrucciones de como pasarse de sala en sala, poner el juego en pausa y demás opciones.

Tengo un objeto "controlador" que es persistente que es el que tiene todo el código.

Esto te podría ayudar:

http://www.comunidadgm.org/preguntas-y-respuestas/problema-enemigo-aleatorio-sin-colision-%28solucionado%29/

Ese efecto de la salpicadura de agua es increíble, le da nivel al juego

Listo! aca te paso el fuente. Recuerda que no solo simplifiqué el código sino que también el algoritmo cambió como lo explico en mi comentario anterior. Por ello si tenés armadura 10 y recibís un impacto de bola_10 no recibís ningún daño a diferencia del algoritmo anterior que recibías un 20% de daño. Pero sin embargo la vida útil de la armadura se va reduciendo hasta que se destruye y te quedas sin armadura. Fijate si es más entendible el código luego en base a esto se puede ir modificando.

El fuente que te pasé tiene dos bolas como el fuente anterior: bola_10 y bola_26 pero podés agregar nuevas bolas creando un objeto para cada nuevo tipo de bola y definiendo su evento create como tienen las demás.
Para lanzarla usa el mismo código que tiene el chip_principal en el evento del mouse.

Pero ten en cuenta que para potencias de bola muy fuertes como 1000 o 2000 debes pensar en que un solo disparo de esos mataría al jugador en caso de que no tuviese armadura. Entonces o permanentemente tiene que tener una armadura puesta en estos niveles (y en caso que no la tenga esquivar todas las bolas porque una sola te mata) o fortalecer al jugador también (además de mejorar las armaduras, por supuesto, para estar a la altura de esos impactos eso lo damos por obvio).
 

No te preocupes, vamos a hacer un código mas simple para que se entienda y luego lo iremos mejorando si hace falta. No usaremos un solo objeto para todas las bolas ni la velocidad ni tiempo relativos por ahora.

1) Vamos a hacer un objeto bola por cada tipo de bola. Es decir, si existen 4 tipos de bola con potencia 10, 26, 50 y 100 entonces vamos a crear 4 objetos:

bola_10
bola_26
bola_50
bola_100

En cada uno de esos objetos le asignas su sprite correspondiente, vamos a hacer un evento "create" en cada uno de ellos y en el mismo le vamos a asignar valores, como por ejemplo su potencia y velocidad. Por ejemplo en la bola 10:

potencia = 10;
velocidad = (la que querramos)

asi bien simple, entonces al crear una instancia del objeto automáticamente se le asignan esos dos valores establecidos en el evento "create". La dirección se la deberíamos asignar después de crear la instancia según donde se quiera disparar en el juego y no en el objeto create.

luego creas un objeto llamado simplemente "bola" y no le asignas ningún sprite ni código ni nada. Luego de crear este objeto, procedes a definir en todos los objetos bola distintos (bola_10, bola_26.. etc) su "parent" (que esto se encuentra en las opciones del objeto cuando le haces "doble clic") y eliges el objeto "bola".

¿Para que sirve esto? Te lo explico. Como el evento de colisión no está en cada bola sino en el personaje mismo, sería muy impráctico que este personaje preguntara: ¿me toco una bola 10?, ¿me tocó una bola 26?, me tocó una bola 50?, ¿me tocó una bola_100?. Entonces le decimos a Game Maker que todos esos objetos: bola_10, bola_26, bola_50 y bola_100 (y los que haya en el juego) tienen la misma característica y es que todos son bolas. Entonces por eso definimos un objeto "bola" que los agrupe y todos tienen esa misma característica, el mismo objeto "parent" o "padre". Y entonces el objeto jugador, en el evento colisión, simplemente pregunta ¿colisioné con alguna bola? esto se logra poniendo el evento colisión con ese objeto "bola" que definimos.  Y ahí ponemos el código.

El cálculo del daño de la armadura y de la vida la haremos con una fórmula simple lineal, es decir, proporcional en lugar de la cuadrática que habíamos definido antes. De esta base simple haremos el código. Y ya te lo pasaré

Pero haré un cambio de concepto para hacerlo aún más simple. La armadura de valor x cubre todo daño de bolas de potencia x o inferior. Pero al recibir los impactos su vida útil se deteriora hasta que se destruye la armadura. Potencias superiores a la armadura el jugador recibe daño excedente a lo que cubre la armadura, y la armadura se deteriora también proporcionalmente. Es decir sencilla la cosa para comenzar

Como dicen algunos técnicos en fútbol: equipo q gana no se toca.

¿te sigue funcionando? Dale para adelante hasta q no te funcione.  :D

Me gusto la idea del llamado recursivo de la alarma porque es una forma de hacer cíclico el llamado a la misma.

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.

Excelente trabajo Guacusio!

Ya vi el código y es sencillo cualquier cosa que no entiendas consultame

lo que quieres es esto:

http://gmc.yoyogames.com/index.php?showtopic=594671
Dentro de esa página haz clic en cada "spoiler" en el boton "show" para expandir y ver el código.

busca "light game maker" en google y youtube creo que hay bastante material, y bueno si sos como yo que no manejo el inglés te puede sacar de paso el traductor de google.

Adjunto un fuente de esa página que te pasé. Hay otros efectos mejores en el link tenés que verlos.

Es lo único en lo que te puedo ayudar ojalá alguien con más conocimientos pueda responderte.

Acá te hice un codigo. Además de lo que vos me pediste hice otras cositas

1) Implementé algo nuevo (al menos para mi, porque se me ocurrio hoy) para la declaración de las variables globales y es usando la estructura ds_map. Trae algunas ventajas, por ejemplo yo necesitaba armar un nombre de variable por medio del manejo de cadena textos y luego decirle a Game Maker que esa cadena de texto es en realidad una variable. Con ds_map esto es posible, porque usa cadenas como "clave" y luego el valor que querramos. Pero para que no sea aburrido usar ds_map hice dos script: cod_set_global y cod_get_global para guardar un valor global y para leerlo. Algunos piensan que el manejo de ds_map es algo lento pero no creo que lo sea porque hice miles de lecturas simuladas y no vi demoras considerables.

2) Una recomendacion de Game Maker es usar prefijos para los recursos del juego. Yo traté de hacer esto a modo de ejemplo: en los script use el prefijo "cod_", en los fondos el prefijo: "bck", en los sprites el prefijo: "spr" y esto es para esclarecer el código cuando hacemos referencia a uno de estos objetos sabiendo en un golpe de vista de que se trata. También para evitar nombres repetidos. Yo a los objetos no les pongo prefijo.

3) También es útil organizar los recursos en carpetas y subcarpetas para poder tenerlo más organizado porque el tema es cuando dejes el código y el año que viene lo quieras modificar
y se puede complicar la cosa. Por eso puse un ejemplo de esto sobre todo en los sprites.

4) Puse un objeto controlador llamado chip_principal que es el que crea las variables globales del juego, y también controla otras cosas como por ejemplo la salida por pantalla de los valores de las variables, la deteccion de los clic del mouse. Este tipo de objetos son útiles y lo puedes implementar, yo lo puse como objeto persistente que si bien no cambia nada en este gmz que te mandé si lo haría en un juego real para que siga existiendo a pesar que se cambie de room, por eso lo puse en persistente como ejemplo.

5) A ese objeto controlador lo ordeno al principio con el boton "instance_order"  que está en la ficha "settings" de las propiedades del room para que la primera instancia que se cree sea este controlador, después fijate que esto se puede manipular desde esa ventana.

6) Hice un solo objeto bola que luego se le asignará el sprite y la velocidad que la saca de un valor global mediante las funciones que incorporé para ello. Entonces ese objeto "bola" funciona como comodín para todas las bolas.

7) Si quieres agregar otro tipo de bola, lo único que debes hacer es crear un sprite con el nombre: "spr_bola_" y el número de su potencia, por ejemplo: sprite_bola_15;
en el evento "create" del "chip_principal" asignarle una velocidad con cod_set_global("bola_15_vel", 30); por citar un ejemplo. Lo que olvidé es poner una velocidad por defecto en caso de que no se asigne ninguna. Luego en algún lado con cod_bola_crear(15);
sería todo, y no habría que modificar nada porque los códigos son genéricos.

8) Hice un evento en las balas que si salen del room sean destruidos, esto es muy importante porque si tiras 100 balas y no las destruyes al salir del room seguirían existiendo haciendo pesado el juego

9) Hice un ejemplo de velocidad relativa y tiempo relativo. En el caso de la velocidad relativa me refiero a que si en un futuro en alguno de tus juegos modificas la velocidad del room al doble (por ejemplo), que esto no haga que todos tus personajes vayan el doble de rápido sino que su velocidad sea igual lo que debería cambiar es la fluidez, es decir, el doble de transiciones en los movimientos. Entonces puedes setear la velocidad del room dependiendo la potencia del dispositivo en el cual se corra y sin alterar las velocidades de los objetos.
El tiempo relativo quiere decir que si haces que una animacion dure 5 cuadros tardando 1/6 seg en un room de 30 step/seg, al  duplicar la velocidad del room esa animación no dure 1/12 seg sino que debería durar lo mismo (caso similar al de la velocidad)
Entonces en lugar de usar velocidades y duracion de step fijos (absolutos) los haces relativos.
También existe la posición relativa pero no lo incorporé en mi ejemplo porque ya estaba algo cansado ja.

10) Para aumentar la velocidad de las balas incorporé la variable "factor_velocidad" que al estar en 1.1 aumentaría un 10% de la velocidad normal de las bolas. al estar un 1.5 la aumentaria en un 50% al estar en 2 el doble, y en un 0.5 a la mitad, etc

11) El código del manejo de la armadura y la vida la hice como me pediste. No hay deterioro de la armadura sino que se "deteriora su vida util" o se reduce su vida útil, es decir, el hecho que esté dañada a la mitad no hace que proteja menos. Cuando se dañe totalmente se destruye, eso creo que era lo que querías.

12) La función del daño de las bolas a la vida y armaduras son en forma relativa a la protección de la armadura y la potencia de la bola y funcionaría también para todas las bolas creadas en el futuro sin tener que modificar nada de código para incorporarlas (esto es lo bueno de manejar datos relativos y no valores numericos fijos). La misma está explicada dentro del "evento" colisión del jugador.
La función no es lineal sino cuadrática está explicado en los comentarios, pero podría mejorarse con una variable que disminuya la pendiente cuadrática cosa que olvidé hacer para que no sea tan abrupto la diferencia con lo lineal.

13) Los valores de la vida del jugador y de la armadura como otros datos como la velocidad del room, etc. pueden verse en tiempo real porque los muestro en la esquina superior derecha.
También podes modificar algunas variables en tiempo real mediante unos botones que te dejé en la parte inferior, tan solo hay que hacerles clic.
Con clic izquierdo en cualquier lugar del room (excepto en los botones de la parte inferior) se dispara una bola 10 y con el clic derecho una bola 26.

14) No he tenido tiempo de testear esto, pero creo que funciona bien para ir probandolo.
Recuerda leer los comentarios del código.

Saludos. Te adjunto el fuente

P.D.: Hice que el daño recibido con una bola de la misma potencia que la calidad de defensa de la armadura, es decir, potencia de bola 10 con armadura = 10, el daño sea del 20% porque la armadura cubriría el 80%. Ese dato del 80% se toma como base (y se puede cambiar en el código). Cuando el valor de la armadura es distinto al valor de la potencia de la bala se hace una función cuadrática que amplifica las cosas. Si la bala es débil que la armadura aún más debil se hace y si la bola es más fuerte que la armadura más fuerte se hace. Esto porque 100 balas de potencia 0.5 no le hacen nada a una armadura de 10. Pero una sola bala de 50 haría mucho más daño, entonces la cosa no es lineal.

Los datos de vida y armadura del jugador no los hice globales sino que los definí dentro del mismo objeto (se puede hacer también de esta forma) lo bueno de esto es que si hay más de un objeto jugador cada uno llevaría su propia cuenta acerca de su vida y su armadura.

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.