Comunidad Game Maker

Prueba este script
http://www.gmlscripts.com/script/sprite_desaturate

Otra opción es la función move_random.

No creo que afecte el rendimiento; como mencionas, el trabajo pesado se hace en el evento Draw; en cada step se recalcula la iluminación porque GMS no tienen un buffer predefinido para ello. Sólo deberías borrar la función _enable.

Es compilado cuando se usa el YoyoCompiler, de otra forma es interpretado.

Si hay una ligera diferencia en el tiempo de interpretación, pero es insignificante, así que no debes preocuparte.

Depende del tipo de juego, por ejemplo en Super Mario Bros. todos los niveles son alargados, de 3000 px en promedio y 224 px de alto; en un metroidvania las escenas suelen ser más pequeñas, pero varían en proporción, algunas son alargadas de forma vertical y otras de forma horizontal; en algunos juegos de plataformas los niveles son del tamaño de la ventana (640 x 480, por ejemplo).
La mejor forma de decidir el tamaño de una room es tener clara la mecánica de juego en ese nivel y hacer muchas pruebas.

Por lo general el tamaño de la room no afecta el rendimiento, lo que si afecta es el número de instancias de objetos. Puedes desactivar las instancias que están fuera de la vista para que no gasten recursos:
http://docs.yoyogames.com/source/dadiospice/002_reference/objects%20and%20instances/instances/deactivating%20instances/index.html

Declara la variable en el evento Create
[gml]
colision = false;
[/gml]

Depende de cómo se muestre el efecto; podría ser en el evento End Step, Draw, o culaquier otro evento que se ejecute después de la colisión. Ahí se tendría que revisar la variable colision
[gml]
if( collision )
{
    //crear efecto en (xx, yy)
}
[/gml]
También se podría crear en el evento colisión, si el efecto es un objeto o partículas.
Uno de los problemas que podrían surgir, si no hay un mecanismo que desplaze al objeto a un lugar sin colisión, es que el efecto se creará constantemente, en cada Step.

También he pensado que la posición promedio no se ajustaría bien si los objetos son de diferentes tamaños y formas. Tal vez las coordenadas del efecto queden mejor de esta forma:
[gml]
//Evento Collision
colision = true;
xx = clamp( other.x, bbox_left, bbox_right );
yy = clamp( other.y, bbox_top, bbox_bottom );
[/gml]

Otra solución que se me ocurre es calcular la posición media entre las dos instancias y ahí crear el efecto
[gml]
//Step
colision = false;

//Evento Collision
colision = true;
xx = (x + other.x)/2; //estas serían las coordenadas del efecto
yy = (y + other.y)/2;
[/gml]

Podrías editar el sprite y repetir una de las subimágenes varias veces, después asignar una image_speed constante, y en el evento Step mover al personaje sólo si image_index es diferente a las imágenes repetidas.

Es muy fácil, sólo debes usar esto después de establecer las transformaciones
[gml]
coords = d3d_transform_vertex(x,y,vrZ);
[/gml]
coords se convierte en un vector con las coordenadas transformadas.

La reflexión se llama "lens flare", que simula la reflexión de la luz dentro de los lentes de una cára. Encontré dos ejemplos:
http://gmc.yoyogames.com/?showtopic=138220
http://gmc.yoyogames.com/index.php?showtopic=192056
Un efecto muy parecido es el "bokeh", no encontré ejemplos, pero se podría simular con partículas personalizadas.
La niebla tal vez está hecha con sprites transparentes.
Me gustaría practicar haciendo esos efectos, pero será hasta que tenga más tiempo libre.

Muchos de los efectos se pueden hacer con surfaces. GMS viene con un tutorial para hacer efectos de iluminación con surfaces.
Muchas veces es más eficiente usar shaders, pero es más complicado aprender al programarlos, hay varios ejemplos aquí: https://marketplace.yoyogames.com/search/results?utf8=%E2%9C%93&query=light

Hay varias soluciones, entre ellas hay dos que se usan comunmente:

La primera es usar una variable de estado, que puede ser global o pertenecer a las instancias. La variable se revisa en cada Step para saber si la instancia debe ejecutar código. Ejemplo:
[gml]
//Evento Step
if( global.pausa )
{
    image_speed = 0;
    exit;
}
[/gml]

La segunda es tomar una captura de la pantalla, en un archivo o en una surface, y después desactvar las instancias. La captura se muestra como fondo. Ejemplo:
Se crea el objeto pausa con el siguiente código
[gml]
//Evento Create
visible = false; //la variable visible se usa como el estado de pausa
sf_pausa = surface_create( room_width, room_height );
[/gml]
si se usa una vista más pequeña que la room, la surface se debe hacer igual al tamaño de la vista.
[gml]
//Evento Key Press
if( not visible ) //pausar
{
    if( not surface_exists(sf_pausa) )
    sf = surface_create( room_width, room_height );
   
    surface_copy( sf_pausa, 0,0, application_surface );
   
    instance_deactivate_all( true );
    visible = true;
}
else //quitar pausa
{
    instance_activate_all();
    visible = false;
}
[/gml]
[gml]
//Evento Draw
if surface_exists( sf_pausa )
draw_surface_ext( sf_pausa, 0,0,1,1,0, c_gray,1 );

draw_self();
[/gml]
El inconveniente con este sistema es que la surface se puede borrar de forma inesperada, por la forma en que se almacenan las surfaces, pero es poco probable. Una alternativa es guardar la application_surface como un archivo, pero eso requiere un poco más de memoria.

Adjunté un ejemplo, esa es una forma de hacerlo, pero hay varias.