Comunidad Game Maker

De acuerdo al manual sí hay una diferencia, dependiendo de dónde pones las constantes: si quieres que las constantes que definas estén disponibles para todas las configuraciones, las colocas en all configurations; si sólo estarán disponibles para la configuración por defecto, las pones en default. Cada vez que agregues una configuración, aparecerá su nombre en la zona de constantes y podrás definir constantes específicas adicionales para esa configuración. Por cierto, las configuraciones sólo están disponibles en la edición pro de GMS así que si usas la versión standard simplemente coloca las constantes en la carpeta all configurations.

Sobre lo segundo, las carpetas sólo sirven para ordenar los recursos del árbol de recursos, no tienen ninguna otra función.

En los eventos vk_button del objeto jugador, antes de moverlo revisa si su futura posición provoca una colisión con el objeto que lo persigue.

evento vk_button, pseudocódigo:
if !place_meeting(nueva posición, objeto que lo persigue)
    { tu código que lo mueve a la nueva posición }

Mi primera experiencia con GM fue en 2002, en ese tiempo estaba recién aparecida la versión 5. A la comunidad GM llegué en 2007, luego tuve un receso entre 2009 y 2014 y ahora me encontré con el GM Studio. Buen programa, pensé en algún momento empezar a programar juegos en C++ pero GM es más que suficiente para lo que necesito por su potente lenguaje GML (aunque algunos piensan que Construct lo supera).

Cita de: LowHertzs en Agosto 02, 2014, 05:25:34 PM

Debo de tener una idea poco clara, las instancias desde el poco conocimiento de gm que tengo son propiedades de los objetos no?

Más bien es lo contrario: los objetos definen las propiedades de las instancias. Tu código hp-=1 no funcionaba porque lo estabas aplicando a todas las instancias del objeto, por eso Maximo te indicó que lo aplicaras a la instancia específica más cercana en vez de a todas las instancias de tipo obj_enemy_flame. Respecto al por qué el enemigo muere de golpe, Maximo ya te explicó por qué; supuso que tu código estaba en el evento step y eso implica que se ejecuta permanentemente. Esto muestra la importancia de indicar en una pregunta en qué evento colocas el código.

No has indicado en qué evento llamas al script. Puede que tu error sea llamarlo en el evento step. Por otra parte, este código:

obj_enemy_flame.hp -=1;

precisamente afecta a todas las instancias del objeto obj_enemy_flame. ¿Tienes clara la diferencia entre un objeto y una instancia?

¿Puedes poner una imagen de la distorsión en GM8 y en GM:S para compararlas?

Cuando pongas un código, tienes que indicar en qué objeto y evento está. Indica también dónde inicializas la variable hp.

Cita de: eams1986 en Agosto 02, 2014, 01:37:47 AM
Que es lo que quieres en realidad
Que gire el objeto o que gire alrededor de otro objeto .

Quiere ambas cosas.

Me parece que lo más práctico es que uses una variable que guarde el ángulo que forma el objeto centro con el objeto orbitando y que al presionar arriba o abajo se decremente o incremente esta variable respectivamente:

En el evento create del objeto satélite:

a=0;//guarda el ángulo del vector centro-satélite (en radianes)
r=200;//la distancia a la que orbita el satélite del centro
d=0.1;//velocidad angular de giro traslacional del satélite (en radianes)

En el evento keyboard flecha arriba del satélite:

a-=d;
x=o_centro.x+r*cos(a);
y=o_centro.y+r*sin(a);

En el evento keyboard flecha abajo del satélite:

a+=d;
x=o_centro.x+r*cos(a);
y=o_centro.y+r*sin(a);

Tienes que calibrar las variables a, d y r a tu gusto. El siguiente código aparece en ambos eventos:

x=o_centro.x+r*cos(a);
y=o_centro.y+r*sin(a);

Ese código puede ir en el evento step en vez de duplicarse, pero toma en cuenta que cuando el satélite no esté moviéndose se estará ejecutando innecesariamente.

Para que gire en torno a sí mismo, basta con que modifiques la variable image_angle del objeto satélite.

La respuesta es muy simple: sí, puedes.

Si omites las llaves, sólo la próxima instrucción de código se considera parte del if. Las llaves sólo son necesarias cuando múltiples instrucciones se deben ejecutar luego de un if con condición verdadero.

Has dicho lo que pasa pero no lo que quieres que pase. Aparentemente quieres que el timer se quede en 0 durante los 3 segundos que le toma a la alarma dispararse. Si es así, puedes ignorar el código del evento step durante esos 3 segundos:

if alarm[0]=-1
{ tu código del evento step }

Para que durante esos 3 segundos el timer se mantenga en 0 en vez de 90 seg, tendrás que modificar el código que activa la alarma en el evento step:

if minutes<0
{
minutes=0
seconds=0
alarm[0]=90
}

Estuve experimentando un poco ya que tuve el mismo problema que tú hace un tiempo. De acuerdo a lo que encontré, las dimensiones del primer room (o su view, si está activa) son las que se usarán para definir el tamaño de la ventana del juego, de modo que cualquier room o view posterior que tenga otras dimensiones distintas al primero será escalado para encajar en las dimensiones éste. Si lo que quieres es que cada room se vea con sus dimensiones originales, es decir, con una ventana de juego cuyas dimensiones sean iguales a las del room o view, tendrás que usar window_set_size (con el consiguiente efecto de blur producto del escalamiento de la imagen). Usar views y manipular los viewports de los demás rooms no te servirá de nada dado que el tamaño de la ventana de juego ya está fijado por el primer room... sin embargo, puedes crear un view del tamaño del room en el primer room y asignarle un viewport de dimensiones iguales al segundo room, con el único propósito de que la ventana de juego sea del tamaño suficiente para albergar al segundo room. El primer room aparecerá escalado pero no tendrá el efecto blur que se obtiene con window_set_size y el tamaño de la ventana de juego permanecerá constante. Para tu caso sería lo siguiente:

En el primer room:
view width:320
view height:240
port width:640
port height:480

El segundo room no necesita activar views.

Cita de: Tony en Julio 24, 2014, 02:07:35 AM

Cita de: Guacusio en Julio 24, 2014, 01:31:05 AM
Asegúrate de que tienes activado draw background color o que tienes un background que dibujar en la pestaña background de las propiedades del room, al parecer no estás limpiando la pantalla en cada paso y por eso aparecen los restos de eventos draw anteriores.

Lo he intentado y nada..

Eso es raro. Descargué tu juego y lo probé, y tiene activado draw background color y se ve con total normalidad como era de esperarse, y si desactivo draw background color ocurre el problema que dices. ¿Estás seguro que el personaje deja una estela al moverse y que tienes draw background color activado?

Mis impresiones y sugerencias son las siguientes:

-Gráficos muy simples, como tu mismo dices. Demasiado simples.
-El personaje se atasca en algunas partes.
-Los mensajes de encontrar llaves son para usar durante el diseño como herramienta debug, en un juego terminado desentonan totalmente y te sacan de un modo full screen (si lo hubiera). Deberías inventar un sistema propio para mostrar esos mensajes.
-Es mejor un círculo iluminado a un cuadrado, y que tenga un difuminado gradual hasta hacer desaparecer la luz en el borde. Consulta el uso de draw_set_blend_mode.
-Los zombies son muy predecibles. Crea paths para ellos, dales velocidades distintas, dales una mínima inteligencia para seguirte si estás en su campo de visión, etc.
-Cuando se rebota en una pared y no se suelta la tecla, el personaje camina de espaldas indefinidamente. Arregla eso.
-El jugador se puede salir del room en algunas partes.
-Algunos zombies y muros se ven incluso fuera del cuadrado iluminado.

Asegúrate de que tienes activado draw background color o que tienes un background que dibujar en la pestaña background de las propiedades del room, al parecer no estás limpiando la pantalla en cada paso y por eso aparecen los restos de eventos draw anteriores.