Comunidad Game Maker

En versiones anteriores a :GMS: y sin usar el YoyoCompiler, el código es más lento que las funciones pre-compiladas. Sin embargo, para eventos del teclado la diferencia de velocidad sólo es apreciable si hay cientos de instancias que reaccionan al teclado. Si sólo controlas a un personaje, usa el evento que te sea más cómodo.

Adjunto la versión .gmk
También se pueden convertir los proyectos usando ENIGMA.

Muy bueno, pero hay unas cosas que se podrían mejorar:

• En Windows los controles son un poco raros, creo que sería más intuitivo si se usan las teclas arriba y abajo
• Se debería agregar la opción de jugar en modo ventana
• Y poner una opción para activar la sincronización vertical

En las propiedades físicas de la casa marca la casilla kinematic, así ningún objeto podrá afectarle.

Para que el personaje no rote, primero establece una fricción angular alta, en el evento Create:
[gml]phy_angular_damping = 100;[/gml]
después, en el último evento previo a Draw, anula la velocidad angular y la inclinación:
[gml]
phy_angular_velocity = 0;
phy_rotation = 0;
[/gml]

Así debería funcionar, sin embargo este método está gastando recursos en exceso al estar simulando cosas innecesarias, sólo es recomendable si el escenario va a tener pocos objetos colisionables.

random_range o irandom_range deberían funcionar, la secuencia se repite porque se está usando la misma semilla generadora, usa la función randomize en un evento previo para cambiar la semilla de forma aleatoria.

Eso ocurre cuando la imagen se escala a un valor no entero y está desactivada la interpolación entre pixeles, como resultado se obtienen pixeles con formas y tamaños irregulares, esto se debe a que a que se escala con el método de "color del pixel más cercano".

Existen varios métodos para evitar artefactos desagradables al escalar las imágenes. El más común utiliza surfaces: primero se crea una surface con el tamaño de la view a escala 1:1, la escena se dibuja en esa superficie también con escala 1:1. La ventana o "port" debe ser más grande que la view. Se crea otra superficie igual al port, o más grande, cuyo tamaño sea un múltiplo entero de la primera vista. Entonces la primera superficie se dibuja en la segunda con la interpolación desactivada, para tener como resultado una imagen a escala con pixeles perfectamente cuadrados. Por último la segunda superficie se dibuja en el evento Draw de un objeto controlador con el tamaño del port y ,ahora sí, activando la interpolación.

Otro método sería utlizar un shader que realice un tipo especial de interpolación, que el color de cada pixel en la pantalla se forme con porciones de los colores de los pixeles de la imagen dependiendo de su cercanía.

Este ejemplo usa shaders para suavizar los bordes: https://marketplace.yoyogames.com/assets/1911/better-scaling, tal vez se pueda modificar para conservar los pixeles, pero mejor escalados. Aquí hay otro ejemplo: https://marketplace.yoyogames.com/assets/2382/flexi-full-scale, pero no se en qué consiste.

Mejor compila como "single executable", para que no sea necesario instalar.

Para que funcione el código, los dos objetos deben estar en contacto, si el cohete está un poco alejado ya no tiene efecto.

Se me ocurrió otra solución, justo antes de separar el cohete de la roca, se podría aplicar un impulso hacia atrás al cohete para que empuje a la roca, y después una fuerza hacia adelante para que se mueva normalmente. Hay que tomar en cuenta la masa de la roca para que la magnitud del impulso sea capaz de moverla, también se debería poner la restitución al mínimo para que el cohete no rebote con demasiada fuerza.

Unas preguntas, ¿cómo está unido el cohete a la roca al principio?, ¿hay una fuerza de gravedad?

Hay varias opciones para dibujar:

Una es guardar los puntos en una "path" y usar la función draw_path. El problema es que hay un límite segmentos que pueden dibujarse con esa función, la función es lenta y sólo se puede dibujar con un grosor. En la red hay algunos scripts que permiten dibujar una path con diferentes grosores, aun así, este es el método menos recomendable.

Puedes usar el mismo método mostrado en este hilo, y en lugar de usar una "surface" desactiva el dibujo del background, así todo lo que es dibujado (en el evento Draw) se mantiene hasta que se cierra el juego. El problema es que esto puede complicar el dibujo de una interfaz con menús y botones. Se puede cambiar el color de fondo si al iniciar la room se dibuja un rectángulo abarcando toda la pantalla.

También es posible dibujar líneas con "anti-alias", el método más rápido es dibujar un sprite deformado (como se muestra en este enlace: http://gmc.yoyogames.com/index.php?showtopic=376776). Una vez encontré un ejemplo que dibujaba figuras con anti-alias con puro código, pero no recuerdo dónde, el resultado era mejor, sin embargo, el código era muy lento.

Y para borrar:

Se puede dibujar el mismo color de fondo, pero si es necesario mantener la transparencia, entonces se debe usar una surface y para borrar se debe cambiar el método de mezcla (blend mode), de modo que el canal alfa se haga cero en los pixeles requeridos. Esto también se podría hacer con un shader que inserte un color con alfa igual a cero.

Antes de iniciar el ciclo for, no olvides poner
[gml]suma = 0;[/gml]

También puedes utilizar una ds_grid y usar la función ds_grid_get_sum, debería ser más rápido, sin embargo sólo sería apreciable si se realizan cientos de sumas.

Si es un impulso, es decir, si la fuerza que se aplica a la roca no es continua y sólo ocurre en un instante infinitesimal, justo en el momento en el que el cohete se separa de la roca, se podría usar la función physics_apply_impulse, tomando como origen del impulso las coordenadas del punto de propulsión del cohete en ese momento, y como componentes del impulso el vector negado de la fuerza que se aplica al cohete.

Pero si el empuje aplicado a la roca es continuo y no ocurre cuando está en contacto con el cohete, sino cuando está en contacto con el fuego que sale de este, entonces se debería hacer la simulación de un fluido. Afortunadamente GMS integra el paquete Liquid Fun. No lo he utilizado aun, pero no parece tan complicado.

Veré si puedo hacer unos ejemplos.

Sólo se puede usar un argumento dentro de un with.

Una solución es crear un objeto padre que englobe todos los objetos que quieres modificar, pero recuerda que afectará a todas las instancias definidas con esos objetos.

Sí sólo quieres modificar a determinadas instancias podrías guardar sus ids en algún arreglo o estructura de datos (list, stack, queue). Después se pueden usar muchas variantes de código:

[gml]
with( all )
{
    if ds_list_find_index( lista, id ) >= 0
    {
        //acciones...
    }
}
[/gml]

el código anterior se puede optimizar con un ciclo for
[gml]
for( i=0; i<ds_list_size(lista); i+=1 )
{
    with lista[| i]
    {
        //acciones...
    }
}
[/gml]

si quieres borrar los ids conforme pasan por el with puedes usar este método
[gml]
while ds_queue_size( queue ) > 0
with ds_queue_dequeue( queue )
{
    //acciones...
}
[/gml]

Pues el manual pone propone un ajuste de velocidad de las instancias como función del tiempo transcurrido entre steps. Sin embargo, me parece poco recomendable porque tendría varias consecuencias desagradables. La más importante es que, al bajar la cantidad de steps por segundo, la detección de colisiones se haría menos veces y por lo tanto muchas de estas no serían detectadas, provocando que algunos ataques no impacten a los enemigos (aunque las trayectorias parezcan correctas) o que algunos obstáculos puedan ser atravesados. Lo anterior se podría evitar si la precisión no estuviera condicionada por la cantidad de veces que se detectan las colisiones, usando técnicas como "raycasting". Además el cambio de velocidad no sería coherente con movimientos que tienen aceleración, como los saltos en un juego de plataformas, lo correcto sería ajustar la gravedad de forma dinámica, pero eso requiere unos cálculos más complicados.

Lo mejor sería crear un sistema de salto de fotogramas, ya que por lo general el evento Draw es el que consume la mayor cantidad de tiempo. Esto se haría desactivando el dibujado automático (existe una función para eso, pero no recuerdo cuál es, también se podría hacer con la variable visible), y revisando en cada Step el valor de delta_time, el fotograma actual se dibujaría sólo si el valor de delta_time se encuentra dentro de los límites.

Hice un ejemplo. El movimiento se activa con la variable global.mover, y se cambia en el objeto obControl.

Los objetos móviles están vacíos, pero son hijos de obPadre, ahí se encuentra todo el código de movimiento. Primero se crea la variable alineado = true, y en Step se controla el movimiento.
[gml]
///Mover y envolver

if( global.mover ){
    vspeed = 8;
    alineado = false;
}
else{
    vspeed = 0;
    if( not alineado )
    if mp_linear_step( x, (y div 50)*50+50, 8, false )
    alineado = true;
}

if( y >= room_height-25 )
y -= (room_height - 100);
[/gml]

Hola, ya jugué la demo, debo decir que necesita muchas mejoras. El logo se ve muy bien, al principio pensé que las líneas se dibujarían de esa forma, pero se dibujan cuadros que no son tan llamativos. El movimiento del personaje necesita mejorar, debería poder subir las pendientes y deslizarse sobre ellas. Ya que se usa el ratón y el teclado a la vez, el movimiento del personaje se debería controlar con WASD. Y la ventana de juego debería ser más pequeña o escalable, porque en pantallas pequeñas no se ve completa.

En vez de dibujar cuadros sería mejor si se dibujaran círculos, también sería más agradable si los personajes fueran circulares. No recuerdo el nombre del tema, pero en el foro hay un ejemplo hecho por [user]Guacusio[/user] que muestra cómo distribuir de manera uniforme instancias sobre una línea.