Comunidad Game Maker

Lo que quieres hacer es complejo. Siendo riguroso, lo que GM permite mostrar en el room es una malla axonométrica con simetría vertical, es decir, las aristas de los rombos pueden tener cualquier dimensión pero siempre son simétricos respecto a un eje vertical (la perspectiva isométrica es un caso especial de perspectiva axonométrica en que además los ejes forman un ángulo de 120º). Por lo tanto, lo que quieres hacer es una perspectiva axonométrica sin simetría (lo que equivale a "rotar" los rombos, como dices) y eso no lo puedes hacer directamente. Sin embargo, se me ocurre algo que puedes intentar: calcula las dimensiones que necesitarían los rombos en GM de modo que si los rotaras coincidan con los rombos no isométricos que quieres usar; utiliza esa malla en el room y coloca tus instancias (se verán desalineados en un principio). Tienes que definir en el room un punto que haga de origen, en torno al cual todos los rombos de GM rotados calcen con tus rombos no isométricos. En el evento create de los objetos, calcula sus coordenadas x,y modificadas aplicando una transformación en función del ángulo de rotación y las coordenadas originales y en el juego aparecerán las instancias en sus ubicaciones correctas.

Citarse supone que si creo una constante, esta es global. La creo para todo el juego y no va a haber marginación de ningún tipo.

No necesariamente. Ese es el meollo del asunto: las constantes globales pueden estar disponibles para una u otra configuración, dependiendo de dónde la definas. Por eso GM:S permite definirlas inicialmente en 2 configuraciones distintas (all configurations o default) o más, si creas nuevas configuraciones. Pero como te decía, si no creas configuraciones por tu cuenta, simplemente defínelas en all configurations.

Con configuraciones me refiero al conjunto de opciones, archivos incluidos, extensiones, etc. que van a aplicarse para una plataforma o cliente específico y que pertenecen al mismo juego. Las configuraciones que creas dentro de un juego indican qué opciones y archivos aplican para android, windows, para una versión "pro" de tu juego, etc. Más información la puedes encontrar en el manual:

http://docs.yoyogames.com/source/dadiospice/001_advanced%20use/007_configurations.html

Tu problema me parece extremadamente raro, las pistas que entregas van todas en la dirección de que existe algún código para el evento colisión del objeto que sigue el path con un objeto sólido (como dijo Clamud). Que el objeto que sigue el path sea sólido o no debería ser irrelevante.

Dices que cuando los objetos sólidos dejan de ser sólidos el problema desaparece, o cual apunta a una sola cosa: la única diferencia entre un objeto no sólido y uno sólido es que el último provoca que la instancia que colisiona con él regrese a su posición previa, siempre y cuando esta instancia tenga definida alguna acción en su evento de colisión con el objeto sólido. Sería más fácil encontrar una respuesta si indicas qué eventos y códigos tienes en el objeto que sigue el path.

Me parece que no podrás pausar el juego dentro del script, todas las funciones que pausan el juego quedaron obsoletas en GM:S y te verás obligado a usar alarmas y continuar el código en otro script.

Una forma es usar move_outside_all. En el evento create de las gotas:

move_outside_all(90,-1);

Eso desplazará la gota creada hacia arriba hasta que no haya colisión. Si quieres una separación mayor, puedes hacer esto:

en el evento create:
if place_meeting(x,y,obj_gota)
    {
    move_outside_all(90,-1);
    y-=borde;//borde es el Nº de pixeles libres verticales que quieres dejar entre las gotas
    }

Tu problema no debería ser causado por el orden de creación de las instancias. Las instancias colocadas en el room, si bien unas antes que otras, se crean todas dentro del mismo step, antes del evento draw. Por lo tanto cuando se dibuja el view en el primer step de ese room ya tienen que existir todas las instancias (por cierto los view no muestran una parte aleatoria del room, muestran la parte que tú le indicas). ¿La view sigue instantáneamente al objeto o tiene una velocidad finita de seguimiento? Si es lo último, para que la view no se tenga que desplazar hasta llegar al objeto a seguir, coloca desde un principio las coordenadas X e Y correctas del view en la pestaña views del room, donde dice view in room, para que la view no necesite moverse al principio.

CitarEl codigo resulto buenisimo funciona con todos los colores exepto el multicolor ya que es un sprite de 8 subimagenes y como i=0 solo me muestra la primera, tuve que modificarlo para que si sprite_index=spr_ball_multicolor{image_speed=0}else{image_speed=1}
pero igual me sigue mostrando la primera imagen que estoy haciendo mal  :'( Muchas Gracias por el codigo Guacusio  :D.

Estás poniendo la condición al revés, debería ser así:

if sprite_index=spr_ball_multicolor
     image_speed=1;
else
    image_speed=0;

Cita de: Lc96 en Agosto 05, 2014, 10:30:04 PM
Muchas gracias,  :D :D yo también tenia ese problema pero ahora me surge otro. El objeto al que le cambio la profundidad ahora me queda por encima de otro que esta parado y por el que debería pasar debajo ayudaa!! :'(

Si te queda por encima del que está parado, aumenta el valor de su variable depth para que sea mayor que la del objeto parado (recuerda tomar en cuenta el signo, por ejemplo -10 es menor que -5).

Tienes que aclarar algunas cosas primero:

¿en qué posición se crean las 2 gotas generadas por la gota destruida?
¿las gotas caen todas con la misma velocidad?

CitarLo que me gustaría es que cuando aparezcan no estén superpuestas, creando como una especie de area, si es posible, pero que al colisionar continuen cayendo

¿A qué te refieres con "una especie de area"? ¿qué pasa cuando colisionan, acaso dejan de caer? ¿puedes poner el código de las gotas para cada evento?

La verdad es que no se entiende (tanto por la explicación insuficiente como por las faltas ortográficas).

¿El room o algún objeto es persistente? ¿Qué hace el continue cuando lo seleccionas? ¿Cómo llevas la cuenta del round en que estás?

La pregunta sigue ahí porque la estás haciendo 9 veces. Tu código está muy repetitivo, en vez de preguntar en forma innecesaria deberías preguntar una sola vez y usar un switch en vez de todos esos if:

var color,i;
if room_exists(color_ball)
{
color=get_string("¿Que color eliges? ","");
switch color
{
case "blanco":
i=0;
break;
case "amarillo":
i=1;
break;
.
.
.
case "multicolor":
obj_ball.sprite_index=spr_ball_multicolor;
i=0;
break;
default:
i=-1;
}
if i!=-1
obj_ball.image_index=i;
else
show_message("El color no existe");
room_goto(room1);
}

Este código asume que en el caso multicolor el sprite comienza mostrando la subimagen 0 y en caso de que no se ingrese un color válido, muestra un mensaje de advertencia pero tú debes decidir qué pasa en ese caso.

Puedes inspeccionar la variable room para ejecutar un código según su valor:

Pseudocódigo:
if room=menu
    { código a ejecutar si se está en el room menu }

Cita de: Marth en Agosto 05, 2014, 12:51:58 AM
si pongo una constante en "all configurations", esta constante se aplicara a otros juegos, por lo que si en otro juego uso esa constante ya estará en el valor que le pusiese la primera vez, pero si lo pongo en default, puedo en otro juego usar una constante que se llame igual, pero que tenga un distinto valor.

No me queda claro si con "juegos" te refieres a configuraciones. Lo que dices es correcto: las constantes definidas en all configurations están disponibles para todas las configuraciones. Sobre el conflicto de nombres, si usas el mismo nombre para una constante en 2 configuraciones, GM tomará el valor que corresponde a la configuración seleccionada; si el mismo nombre aparece en all configuratios y en otra configuración x (o default), GM usará el valor de la configuración x antes que el de all configurations (suponiendo que está seleccionada la configuración x).