Comunidad Game Maker

Las configuraciones de la vista están en la pestaña View del editor de rooms.
Con respecto a la application surface, las modificaciones se le hacen por código directamente, por lo que si no usas GML (o usas poco) seguramente no hayan problemas con eso.

Muestra las configuraciones de la vista, para asegurarnos de que no haya ningún problema ahí.
También revisa si no modificas la application_surface o las vistas de algún modo durante la ejecución del juego.

¿Qué versión de GameMaker estás usando?
Recuerda poner el ícono del GM correspondiente en el post para que los usuarios te puedan ayudar mejor, al igual que un título algo más descriptivo, con solo decir "variable" no se dice mucho.

Ahora al tema, según lo que he entendido podrías simplemente tener el objeto de animación creado desde el inicio, pero hacerlo visible solamente cuando aumentes el valor de la vida.
[gml]
///En el evento en que vayas a aumentar la vida
vida += 10;
with obj_animacion {
    visible = true;
    image_index = 0;
}
[/gml]
[gml]
///En el evento Animation end del objeto animación
visible = false;
[/gml]

(nadie ha visto nada xd)
EDIT:
A ver, puedes intentar de esta forma:

1. Crea al objeto aleatoriamente en cualquier lugar, no va a haber una comprobación de disponibilidad inicial.
[gml]
///En el timeline
var _x, _y;
_x = irandom(room_width);
_y = irandom(room_height);

instance_create(_x, _y, objeto);
[/gml]

2. Será dentro del código del mismo objeto en donde comprobaremos si el lugar está disponible
[gml]
///Evento create del objeto
var n = 0; //Un contador para limitar la cantidad de "intentos" por ponerse en una zona libre.
while not place_empty(x, y) {
    x = irandom(room_width);
    y = irandom(room_height);
    n ++;

    if n > 20 { //Así evitamos que se bloquee el juego si el objeto no encuentra espacio disponible
        instance_destroy();
        exit;
    }
}
[/gml]

Las funciones place_*() comprueban la disponibilidad de un lugar basándose en comprobar si la máscara de colisión del objeto que las ejecuta choca con la máscara de alguna instancia. En tu caso, utilizas una timeline que no tiene máscara de colisión y, por tanto, dichas funciones no van a trabajar correctamente.

Una solución simple podría ser utilizar position_empty() o position_meeting() que no utilizan la máscara de colisión del objeto que las ejecuta, sino que comprueban un choque entre un punto concreto (dado por coordenadas) y la máscara de las otras instancias.

No sé cómo es en GMS2, pero me imagino que no ha de ser muy diferente al Studio 1.

Resulta que GM guarda todos los archivos en un directorio "confinado" (sandbox) para proteger a los usuarios de nuestros juegos. Ese directorio es la ruta almacenada en working_directory, que normalmente es %appdata%»tuJuego. Básicamente, todos los archivos que guardes y leas están ahí, y de ahí raramente pueden salir.

Cuando dicen que se usa en raras ocasiones, es porque no es necesario utilizar la variable working_directory para guardar, puesto que dicha ruta siempre será el directorio principal.

Otra cosa, el manual hace referencia a un tal Game Bundle, que es la ruta del ejecutable de tu juego. Puedes leer archivos en esa ubicación, pero no modificarlos, cualquier intento por hacerlo sólo creará una copia del archivo con los cambios en working_directory.

¿Qué versión de GameMaker estás usando?
Puedes poner el ícono del GM correspondiente en el post para que los usuarios te puedan ayudar mejor.

El error se debe a que en GM no puedes concatenar un número con una cadena de texto. Tienes que convertir los números a cadena antes de poderlos operar con texto.

No estoy en PC así que no te puedo dejar enlace, pero puedes solucionar el problema utilizando la función string().

Solución fácil:
[gml]
///COORDENADAS EN PANTALLA (NO EN HABITACIÓN) DEL MAUS
var mouse_display_x = mouse_x - view_xview[0];
var mouse_display_y = mouse_y - view_yview[0];
[/gml]

Solución menos fácil: Usa teclas virtuales.
http://docs.yoyogames.com/source/dadiospice/002_reference/mouse,%20keyboard%20and%20other%20controls/virtual%20keys/index.html

No necesitas utilizar ciclos anidados. Basta con un cálculo sencillo para saber en qué celda está el mouse:
[gml]
///EVENTO MOUSE PRESSED O ALGO ASÍ XD

//Las coordenadas en la habitación en las que se dibuja el inventario
//(ezquina superior izquieda del inventario)
var xinit, yinit; //Asígnales el valor que sea necesario

//Tamaño de las celdas
var cellw, cellh; //Asígnales el valor que sea necesario

//Cantidad de celdas (horizontal y verticalmente)
var cellwnum, cellhnum;  //Asígnales el valor que sea necesario

//Tamaño total del inventario
var gridw = cellwnum * cellw;
var gridh = cellhnum * cellh;

//Posición del mouse con respecto al inventario
var mousedx = mouse_x - xinit;
var mousedy = mouse_y - yinit;

//Comprobar que el mouse esté dentro del inventario
if point_in_rectangle(mousedx, mousedy, 0, 0, gridw, gridh) {
    //Convertir las coordenadas en la pantalla a coordenadas dentro el inventario
    //(coordenadas de celda)
    mousedx = floor( mousedx / cellw );
    mousedy = floor( mousedy / cellh );

    //Esas dos variables ahora indican la celda en la que se hizo clic
}
[/gml]

¿Qué tan "descuadrado" está? Quiero decir, ¿parecen moverse con el mismo path, pero desde inicios distintos, o la ruta es directamente distinta?

Pues, el error es el mismo. Las constantes que vienen con el GM también se basan en el mismo sistema, representan los componentes BGR con sus cifras en binario. Si se empiezan a leer al revés, pues dichas constantes fallan también.

De momento (si es que algún día se arregla) no nos queda más que corregir el problema manualmente. Mírate este script:
http://www.comunidadgm.org/index.php?topic=30809.0

Autor: NiuWeb.
Versión de GM: Studio 1.4.9999.
Descripción: Invierte los componentes de un color representado como número entero. Es decir, el componente rojo pasará a ser azul, y viceversa.

Resulta que en la versión 1.4.9999 las funciones effect_create_below() y effect_create_above() tienen un error que les hace interpretar los colores al revés.

Es decir, este código de aquí:
[gml]
effect_create_above(ef_firework, 128, 128, 0, c_orange);
effect_create_below(ef_firework, 256, 128, 0, c_teal);

effect_create_above(ef_firework, 128, 256, 0, c_blue);
effect_create_below(ef_firework, 256, 256, 0, c_red);
[/gml]
Muestra en pantalla esta locura:


Código: El problema se puede solucionar con este código.
[gml]
///color_rgb_fix(color);
//Invierte los componentes del color dado

//Obtener componentes iniciales
var red   = argument0 & 255;
var green = (argument0 >> 8) & 255;
var blue  = argument0 >> 16;

//Rehacer el color
return (red << 16) | (green << 8) | (blue);
[/gml]

Ejemplo:
Esta sería la versión corregida de las constantes de color, para usar con estas funciones:
[gml]
aqua    = color_rgb_fix(c_aqua);
black   = color_rgb_fix(c_black);
blue    = color_rgb_fix(c_blue);
dkgray  = color_rgb_fix(c_dkgray);
fuchsia = color_rgb_fix(c_fuchsia);
gray    = color_rgb_fix(c_gray);
green   = color_rgb_fix(c_green);
lime    = color_rgb_fix(c_lime);
ltgray  = color_rgb_fix(c_ltgray);
maroon  = color_rgb_fix(c_maroon);
navy    = color_rgb_fix(c_navy);
olive   = color_rgb_fix(c_olive);
orange  = color_rgb_fix(c_orange);
purple  = color_rgb_fix(c_purple);
red     = color_rgb_fix(c_red);
silver  = color_rgb_fix(c_silver);
teal    = color_rgb_fix(c_teal);
white   = color_rgb_fix(c_white);
yellow  = color_rgb_fix(c_yellow);
[/gml]
Y así, cuando necesitemos usar constantes de color en las funciones de efectos, no usaríamos c_yellow sino yellow, por ejemplo.

Así que, el código que puse al principiose corregiría de esta forma:
[gml]
effect_create_above(ef_firework, 128, 128, 0, orange);
effect_create_below(ef_firework, 256, 128, 0, teal);

effect_create_above(ef_firework, 128, 256, 0, blue);
effect_create_below(ef_firework, 256, 256, 0, red);
[/gml]
Y en pantalla:

espera, ¿queeeeeeeé? xDdXd.

A ver, que no panda el cúnico. Parece que a los de YoYo les ha dado por cambiar el funcionamiento de los colores en esa función a último momento, ni idea de por qué.

El "bug" sucede porque ahora los colores (por lo menos con effect_create_above, no he probado las demás ni quiero) se leen completamente al revés. Quiero decir, mientras que antes los tres bytes de un número entero se leían de izquierda a derecha como azul, verde y rojo, ahora es rojo, verde y azul.

Oséase, que si antes el rojo era 255 (00000000 00000000 11111111 en binario), ahora debería ser 16711680‬ (11111111 00000000 00000000).

Sinceramente, gran tontería me parece este cambio tan incómodo, pero es la última versión (1.4.9999) así que toca resignarnos xd.

Entre utilizar una variable y un entero no hay prácticamente ninguna diferencia, y de hecho los mismos de YoYo utilizan room_speed en varios de sus tutoriales.

No solo no hay repercusión en el rendimiento, sino que además evita tener que modificar manualmente los valores en caso de cambiarse la velocidad de la sala.