Comunidad Game Maker

Activa una view que no estés usando, colócala en la posición de la ventana que quieras usar con el alto y ancho que quieras usar, los valores Top y Left deben ser 0.

Ahora crea un nuevo objeto, o modifica un objeto controlador que ya estés usando. Dale una profundidad por encima de todos los demás objetos, y en su evento Draw pon este código, modificándolo para usar la view que apartaste para el minimapa:

if (view_current == 1){
  var scale;
  scale = view_width[1] / view_width[0];
  draw_rectangle(0,0,view_width[1],view_height[1]);
  with(all){
    if variable_local_exists("Map_Icon")
      draw_sprite(Map_Icon,-1,x*scale,y*scale);
  }
}

Ese código dibujará solamente en la view seleccionada, dibujando un rectángulo para cubrir el fondo de la view y luego dibujará sprites representativos de las instancias en una posición relativa a su posición en la room.

Solo instancias que tengan la variable Map_Icon serán dibujadas en el minimapa, y dicha variable debe contener el sprite que será dibujado en el minimapa.

Dejo un ejemplo:

El código debería funcionar correctamente, asegúrate de haber marcado los sprites para detectar colisiones precisas. También a tener en cuenta, el objeto no subirá cuestas con inclinación superior a los 45 grados.

Puedes usar la función collision_point, dicha función devuelve la id de la instancia con la que encuentra colisión, en el caso de encontrar varias instancias en la misma posición devuelve la id de la instancia con menor profundidad y menor id.

Esto quiere decir que devuelve el id de la instancia que el GM dibujaría por encima de las demás.

Podrías usar esta función de dos maneras:

if collision_point(mouse_x,mouse_y,all,1,0) == id {
  //Código de click
}

Donde el código de lo que quieras que ocurra con click estaría dentro del if de collision_point, el cual se ejecutaría si la id del objeto es la misma que retorna la función.

O puedes usarla así al principio del código:

if collision_point(mouse_x,mouse_y,all,1,0) != id exit;

Donde el evento de click se terminaría inmediatamente al encontrar que la id de la instancia no es la misma que retorna collision_point. Con este método ni siquiera tienes que ponerlo en el mismo bloque de código que el resto del evento, puedes agregarlo en un bloque aparte al principio del evento.

Ahora bien, entiendo que preferirías que esto fuese automático, para no tener que estar agregando tú esa pieza de código, y puede hacerse, por ejemplo este código:

if mouse_check_button(mb_left){
  mouse_clear(mb_left);
  with(all) {
    if collision_point(mouse_x,mouse_y,object_index,1,0) {
      event_perform(ev_mouse,ev_left_button);
      break;
    }
  }
}

Ese código se usaría en el evento step begin de un objeto en la room, cualquier objeto. Se activa cuando presionas el botón izquierdo del mouse, limpia el estado de dicho botón para evitar que los eventos se ejecuten como normalmente lo harían, y luego busca entre las instancias una con la misma id que la devuelta por collision_point para ejecutar su evento del botón izquierdo del mouse manualmente. Sin embargo esto trae su propios problemas como, por ejemplo, la función que limpia el estado del mouse hace que no se puedan registrar eventos al soltar el botón izquierdo, y el evento del botón presionado solo se ejecuta una vez, en lugar de seguir ejecutándose mientras se siga presionando el botón.

Estos son problemas que se pueden solucionar usando métodos alternos, como eventos de usuario en lugar de eventos de mouse, así no es necesario limpiar el estado del botón del mouse, pero sinceramente me parece que el esfuerzo necesario para hacer una pieza de código que funcione sin ningún problema supera al esfuerzo necesario para copiar y pegar un bloque en los objetos que tienen eventos de mouse.

Dejo un ejemplo, puedes hacerle click a los círculos para cambiarles de color, notaras que, aparte de que los círculos respetan el orden en que están dibujados a la hora de hacer click, solo podrás hacerle click a los círculos que están por encima de instancias barrera.

El ojo humano no tiene una medida especifica de cuantos fotogramas por segundo puede observar, varía según la situación, pero fácilmente supera los 200 fotogramas por segundo, si bien a mayor número de fotogramas mejor, lo importante acá no es el número mayor, sino el menor, valores inferiores a 24 simplemente no se ven fluidos.

Y desde el punto de vista de tener movimiento más fluido, poner la velocidad del room a 300 es inútil porque la frecuencia de dibujado del GMS no puede superar la frecuencia de actualización del monitor, mi monitor tiene una frecuencia de 60 Hertzios, si pongo la velocidad del room a 300 steps por segundo todo se moverá más rápido y el GM seguirá dibujando los 300 frames, pero el monitor solo será capaz de mostrar 60 por segundo por lo que el esfuerzo por dibujar los otros 240 frames se desperdicia.

Si a 60 va muy rápido puedes modificar el juego para que los objetos no se muevan tantos pixeles por frame y los sprites cambien de subimagen cada más frames, aunque comprensiblemente es algo molesto de balancear si el juego ya está casi completado. Usualmente esta es la clase de decisión que debe tomarse temprano en el desarrollo del juego para evitar dolores de cabeza después.

Las condiciones en los if hacen que pasado xstart+2000 alfa1 no cambie, esto debido a que cualquier coordenada sea mayor a xstart+2000 también sera mayor que xstart+1020, ambos if se ejecutan y alfa1 queda con el mismo valor que el step anterior.

Cambia las condiciones en el primer if para que también dependa si x es menor que xstart+2000.

De hecho ese es un error que aparece en algunas versiones pirateadas de Studio, y es algo que lógicamente no permitirían nunca que ocurra en la versión legal. Es posible que la mala impresión que te dio GMS fuera el resultado de una versión pirata bugeada? No puedo evitar notar que también te quejas del 8.1, que fue cuando el DRM online de yoyogames y las actualizaciones constantes del software fueron implementados, dificultando el pirateo.

Sinceramente no consigo entender cómo es que la gente llega a la conclusión de que GM8 es más rápido que GMS, acá hay una rápida comparación:



Acá tenemos al GMS, con 16386 instancias en pantalla, y aún con sus 30 frames por segundo, las instancias se mueven a cada paso en una dirección y velocidad elegidas al azar al momento de su creación, y se mueven al otro lado del room al salir de sus límites. Las instancias crean una instancia nueva del mismo tipo cada vez que se hace click, aumentando exponencialmente el número de instancias.



Acá tenemos al GM8, las instancias tienen exactamente el mismo comportamiento, la única diferencia sería que la instancia encargada de dibujar los datos en pantalla realiza un cambio de fuente porque de otra forma la fuente por defecto de GM8 no se distinguiría muy bien. Hay 4097 instancias en pantalla, y los frames por segundo ya están empezando a bajar a 26.

16 mil contra 4 mil, estamos hablando de 4 veces más instancias en pantalla y los fps de GMS aún no bajan.

Ahora, si pueden señalarme bajo cuales circunstancias el GM8 es más rápido y eficiente que el GMS, entonces quizás podríamos tener un debate sobre cual GM es auténticamente mejor. Me gustaría pensar que tengo una mente abierta y que estoy dispuesto a aceptar cuando me equivoco.

Muchas funciones se volvieron obsoletas en el paso de GM8 a GMS, en su mayoría funciones dinámicas, las otras serian de audio, splash screens, manejo de archivos y registro y modificación de partículas, que me acuerde en este momento.

Por otro lado GMS gano shaders, físicas, soporte ogg, compilación de código, imágenes vectoriales y animaciones esqueletales hechas con el software Spine, buffers, un mejor debugger y eventos y funciones asincrónicos.

Con todo eso dicho, recomiendo el Studio por encima del GM8 SI SE VA A EMPEZAR UN PROYECTO NUEVO.

Si estás muy avanzado en un proyecto complejo en GM8, es más fácil terminarlo en GM8, que adaptarlo a GMS, y solo valdría la pena si se necesita una mejora en el rendimiento o si alguna de las nuevas características del GMS resultan indispensables para el juego.

Usa views (en el editor de rooms, la pestaña views) para mantener un tamaño de ventana constante entre rooms de distinto tamaño.

La variable transition_steps controla la duración de las transiciones, a mayor el número asignado mayor la duración, por defecto es 80.

No, tanto el evento de colisión como la función place_meeting usan la máscara de colisión del objeto, por lo tanto si se usan coordenadas o pixeles para determinar de si hay una colisión depende de si la máscara es precisa o no.

El evento colisión checa por colisiones en la posición del objeto, la función place_meeting esencialmente mueve la instancia a la posición donde se quiere checar por colisiones, checa por colisiones y luego regresa la instancia a su posición original.

El evento solo puede usarse para comprobar colisiones con instancias de un objeto especifico, la función puede buscar colisiones con instancias según objeto, con instancias especificas según su ID, con todos las instancias existentes usando la palabra clave all, o en casos donde aplique, instancias identificadas mediante la palabra clave other.

El evento colisión se ejecuta una vez por cada colisión, si hay 5 objetos que generan colisión en el mismo lugar el evento se ejecutará 5 veces, la función solo regresa true o false, sin importar cuantas colisiones ocurrieran durante el chequeo.

GameMaker usa el método de fuerza bruta para encontrar colisiones, esto quiere decir que revisa todas las instancias que podrían cumplir la colisión sin importar si las instancias podrían realísticamente entrar en colisión. La diferencia entre place_meeting y el evento colisión en este caso es que place_meeting deja de buscar colisiones cuando una ha sido encontrada, pero como el evento colisión se ejecuta una vez por colisión el evento debe seguir buscando colisiones hasta agotar las posibilidades.

Esto hace que la función place_meeting sea más rápida que el evento colisión solo cuando una colisión es encontrada temprano en el bucle, si la instancia que produce la colisión se encuentra al final del bucle, o simplemente no hay colisión entonces place_meeting es tan eficiente como lo sería el evento colisión.

Puedes usar este código cada vez que quieras crear una fruta nueva:

var fruta;
do fruta = choose(pera,papaya,banana...mango);
until(!instance_exists(fruta));
instance_create(x,y,fruta);

Donde se elige una fruta y se revisa si la fruta ya existe, si aún no existe se crea la instancia de la fruta, si ya existe se vuelve a elegir una fruta hasta que se elija una que aún no exista.

Los módulos normales de GMS también son compilados, la diferencia esta en que un módulo normal es compilado a una máquina virtual, mientras que con el YYC la compilación se hace a código nativo, que no es lo mismo que código binario.

Con eso dicho, según la página de ayuda de YoYoGames, cuando se usa el YYC el compilador elimina funciones innecesarias y realiza diferentes técnicas de optimización, que resultan en un ejecutable de menor tamaño y mayor eficiencia.

En la pestaña de Licenciamiento se puede elegir la opción de usar APK Expansions:


Eso hace lo que quieres.

En el mercado hay dos recursos para teclados en moviles:

https://marketplace.yoyogames.com/assets/299/android-keyboard es solo para Android y cuesta 1$

https://marketplace.yoyogames.com/assets/245/keyboard es para Android e iOS, cuesta 10$

O claro, siempre podrías escribir tu propia extensión para Android o iOS, pero necesitarás conocimiento en Java y/u Objective C, respectivamente.

GameMaker 8 no puede exportar a Android, ni tiene acceso a los servicios de Google Play.