Comunidad Game Maker

Interesante, se nota que has invertido mucho trabajo en este juego, el problema es que no soy fan de este género, y me cuesta entender cómo jugar.

Aquí publicaron un código para eso:
http://gmc.yoyogames.com/index.php?showtopic=541440

En los tutoriales de GMS también hay un ejemplo:

Es un tutorial muy corto, tal vez lo traduzca en unos días.

Se puede hacer con un código como este en el evento Step:
[gml]
//ejes de movimiento (joystick)
jx = keyboard_check(vk_right) - keyboard_check(vk_left);
jy = keyboard_check(vk_down)  - keyboard_check(vk_up);

//mantener en un rango circular
j = sqrt( jx*jx + jy*jy );
if( j > 1 ){
    jx /= j;
    jy /= j;
}

//mover al personaje
x += jx*v; //(v = velocidad)
y += jy*v;

//disparar
if keyboard_check_pressed( vk_space )
with instance_create( x,y, obj_bala )
{
    speed = 12321; //velocidad de la bala
    if( other.jy < 0 ) direction = 45;
    else if( other.jy > 0 ) direction = 315;
    else direction = 0; //direccion de la bala
}

//sprite del personaje
switch( jy ){
    case -1: sprite_index = spr_arriba; break;
    case  0: sprite_index = spr_frente; break;
    case  1: sprite_index = spr_abajo;  break;
}
[/gml]
Me gusta usar dos variables como si fueran los ejes de un joystick para evitar que el movimiento sea más rápido en diagonal.
La dirección de la bala también se podría asignar con un switch-case, como se hace con el sprite. Revisa la velocidad de la bala, porque puse un valor exagerado.

Antes de poderte ayudar es necesario que nos digas qué tipo de juego quieres hacer y cómo son los controles.

Y pues para aprender GML, lo mejor es seguir tutoriales y leer el manual, al mismo tiempo vas a aprender a programar. Sin embargo, muchas veces la información que se da en los tutoriales no es muy precisa, por lo que te aconsejaría aprender un lenguaje de programación más formal, como C. Existen muchos libros sobre C, fáciles de seguir, por ejemplo el de Deitel Deitel. No te desesperes, para ser un programador experto se necesitan muchos años de estudio,  a menos que seas un genio.

Lo que había pensado, es que cada pieza guarde un array con los ids de las piezas colindantes (por lo general se guardarían 4 ids, pero las piezas de las orillas guardarían 3 o 2). Al momento de soltar la pieza, además de revisar la distancia a su posición inicial, se revisaría la distancia a unos puntos cercanos a la piezas que no se han unido. Cuando una pieza esté pegada a otra, el movimiento que se haga sobre ella se debe transmitir a la otra pieza. Y cuando se coloque en su posición inicial, se debe transmitir a la otra el estado CALZA.

Se me ocurre esto, sólo se usarían los eventos Step de los dos objetos
[gml]
///STEP (humano)

if( atacar == false ) //si no ataca
{
    z = instance_place( x,y, obj_zombie ); //buscar colision
    if( z <> noone ) //si existe colision
    {
        atacar = true; //activar ataque
        sprite_index = spr_atacar;
       
        with( z ) //con el zombie
        {
            atacar = true; //tambien se activa el ataque
            sprite_index = spr_atacar_z;
        }
    }   
    // otras acciones cuando no ataca ...
}

if( atacar = true ) //si ataca
{
    if not place_meeting( x,y, z ) //y ya no hay colision
    {
        atacar = false; //desativar ataque
        with( z ) atacar = false; //en las dos instancias
    }
    // otras acciones cuando ataca ...
}
[/gml]
[gml]
///STEP (zombie)
if atacar == false{
x+=1
}
[/gml]

Tal vez hay un objeto que reasigna la variable. Pueden ser muchas cosas, pero para encontrar el problema es necesario ver el proyecto.

También se puede usar la función instance_place, que necesita menos parámetros.

Usar otra view no es recomendable porque el código se va a complicar mucho.
Hice unas modificaciones al ejemplo para que el desenfoque siempre esté centrado en el personaje. Los degradados se dibujan de acuerdo a la posición relativa del personaje y la vista, y por supuesto, es necesario usar unas imágenes más grandes.

Es cierto Elvis, usar superficies causa ralentización en algunas máquinas. Para que el juego funcione bien en la mayoría de computadoras, sería bueno poner una opción que desactive los efectos.

Logré hacerlo funcionar con el juego en movimiento, pero estoy haciendo algo que el manual no recomienda: estoy cambiando los lienzos de dibujo dentro del evento Draw, lo bueno es que no parece afectar, el único problema que he encontrado es que si se usa un "foreground" a veces no se ve. El ejemplo está adjunto, el efecto se controla con obBlur, que tiene una profundidad menor a las demás instancias. Creo que exageré con el desenfoque, eso se puede arreglar cambiando los degradados.

Puede ser que falten algunos ifs con condiciones para manejar esa situación.
Si sólo necesitas el deslizamiento sobre sólidos para no salir de la room, entonces el código se puede simplificar, además no es necesario poner sólidos alrededor de la room:
[gml]
if( x < (anchura/2) ) x = (anchura/2);
if( x > room_width-(anchura/2) ) x = room_width-(anchura/2);
if( y < (altura/2) ) y = (altura/2);
if( y > room_height-(altura/2) ) y = room_height-(altura/2);
[/gml]
anchura y altura son las dimensiones de la caja de colisión, y se dividen entre dos suponiendo que está centrada en la posición de la instancia.

Si, todo se haría con una serie de ifs, pero creo que te ayudaría mejor con un diagrama.

Por un momento pensé en sugerirte un shader, pero me di cuenta de que utilizas GM8. El efecto se puede lograr con superficies. En este caso el proceso se complica un poco porque la escena se debe dibujar a la superficie y no directamente a la pantalla; el dibujo de las instancias se debe hacer previo al evento Draw y en Draw sólo se debe dibujar la superficie para no dibujar dos veces lo mismo.
En resumen, el procedimiento es este: Primero se crean superficies de diferentes tamaños, pero con la misma relación aspecto, y se activa la interpolación de textura. En cada Step se dibuja la escena a una superficie que tiene un tamaño igual a la view, y se usa una imagen con degradado para hacer transparentes algunas zonas de la superficie. Después la superficie con transparencia se dibuja a escala sobre otras superficies.
[gml]
surface_set_target( sf1 );
draw_background( bg0, 0,0 );
draw_set_blend_mode_ext( bm_zero, bm_src_color );
draw_background( bgGradBlanco, 0,0 );
draw_set_blend_mode( bm_normal );
surface_reset_target();

surface_set_target( sf2 );
draw_surface_ext( sf1, 0,0, 1/2, 1/2, 0,c_white,1 );
surface_reset_target();

surface_set_target( sf4 );
draw_surface_ext( sf2, 0,0, 1/2, 1/2, 0,c_white,1 );
surface_reset_target();
[/gml]
En cada evento Draw se dibuja la superficie con la escena original y encima se dibujan las superficies con transparencia, estiradas para que cubran toda el área de la view. Al final se dibuja un degradado oscuro.
[gml]
if surface_exists( sf2 )
draw_surface_ext( sf2, 0,0, 2,2, 0,c_white,1 );

if surface_exists( sf4 )
draw_surface_ext( sf4, 0,0, 4,4, 0,c_white,1 );

draw_background( bgGradNegro, 0,0 );
[/gml]
El resultado es este

Adjunto el editable

El grado de desenfoque y la cantidad de oscuridad se puede modificar cambiando los degradados, usando más supeficies o dibujando con diferentes niveles de opacidad. Además en Limbo parece que hay una capa extra de ruido, para tener ese efecto granulado.

Es porque hay un pequeño error, debería ser así
[gml]
if place_meeting(x+vel,y,obj_bloque) {hspeed*=-1}
[/gml]

El camino y el movimiento se podría controlar con varios paths texturizados de esta forma
http://www.comunidadgm.org/preguntas-y-respuestas/%28resuelto%29-cola-de-serpiente-casi-real/

Los círculos que representan a los niveles podrían ser varias instancias de un mismo objeto que leen los datos de un array global con la información de los niveles.

Para evitar problemas de rendimiento, como menciona eams, puedes desativar las instancias que están fuera de la vista.