Comunidad Game Maker

El mensaje del zombie no es el error precisamente. Eso es un mensaje genérico para indicar que algo malo ocurrió en el proceso. El error real es

I/yoyo    (20060): ERROR: Enumerating API level getDescriptor []

Parece que no hay mucha información sobre el error. Creo que lo mejor sería que contactaras directamente al helpdesk de YoYo.

Hay varias maneras, pero así sin haberlo probado, sólo pensando un poco, la que más me agrada a mi sería usar un ds_map para almacenar los sprites. Las claves (key) en un dsmap pueden ser de tipo string o real, así que cada par llave-valor en el mapa quedaría como:

key(real): valor (nombre del recurso-sprite)

Entonces para cada llave usaría el nombre de la habitación y en el valor el sprite asociado a esa habitación. Teniendo relacionados cada habitación con su sprite, sería fácil dibujar el sprite correcto. De hecho, creo que la key puede contener tanto un valor de cadena como real, depende de la lógica que uses para referirte a las habitaciones

Cita de: arcangelcaos en Enero 17, 2015, 11:27:53 PM
Que hago mal. Por descontado que los sprnivel1,2,3, etcc están creados

a = "sprnivel" + string(Nivel)

Eso no va a funcionar: Los nombres que les das a los sprites en GM en realidad apuntan a un índice NUMÉRICO (real). Es decir, que en tu juego, cuando escribes sprnivel1, GM no toma en consideración el nombre como cadena, sino el índice de sprite asociado a ese recurso (1, 2, 3, etc), por eso los nombres de los recursos aparecen resaltados en color distinto.

La variable a en tu ejemplo, sólo contiene información de tipo string, así que GM no puede usar eso como un índice NUMÉRICO para llamar a un sprite. Lo mismo pasa con las habitaciones, aunque todas tienen un nombre, lo que en realidad GM usa es un índice que se asigna automáticamente al crear cada habitación.

Sea lo que sea que dibujes en el evento DRAW, no cuenta como máscara de colisión. De manera automática, lo único que toma en cuenta GM para evaluar colisiones es la máscara como está definida en las propiedades del sprite. Quizás en algún lado estás usando funciones de colisión adicionales como instance_place(), collision_circle(), etc.

Puede que sí, puede que no, pero lo que creo que está pasando es que no estás usando una condición adecuada para lanzar la cuenta de la alarma: Por ejemplo, si en STEP tienes algo como esto:
[gml]
if (variable > 10)
     obj_enemigo.alarm[0] = 2 * room_speed
[/gml]

Pues NO VA A FUNCIONAR: porque en cuanto la variable llega a 10,  se cumple la condición, y la alarma se ajusta al valor que le indicas, peeeero... al siguiente STEP, la condición sigue siendo verdadera, por lo que el valor de la alarma se vuelve a ajustar, y de esta manera, la condición no permite que la alarma llegue a cero, y por lo tanto, nunca se lanza el evento de la alarma.

La animación de salto sólo debe estar activa cuando haya gravedad, es decir, cuando no haya contacto con el suelo, es decir, cuando esté en el aire. Si está en contacto con el suelo, no hay gravedad, entonces no se debe permitir mostrar la animación de salto. La solución es usar un IF, la condición puede variar según tu juego (gravedad, vspeed, contacto contra el objeto suelo, etc)

BEGIN STEP se ejecuta antes que los eventos de alarma y de teclado
STEP se ejecuta antes que los eventos de colisión y END STEP después.

Si antes hay otra habitación con otras dimensiones, las habitaciones siguientes se ajustan al tamaño de la primera. En GMS, el tamaño de la application surface se ajusta al tamaño de la primer habitación.

Game Maker o Game Maker Studio no está hecho para hacer ese tipo de programas, sino juegos (y principalmente juegos 2D). No estoy diciendo que no se pueda. Se pueden hacer programas orientados hacia áreas didácticas o incluso comerciales, como simular inventarios, bases de datos, etc, pero para hacer ese tipo de programas, hay lenguajes mucho más adecuados y potentes que GML.

En pocas palabras: un programador profesional experimentado, jamás elegiría GM para crear un programa del tipo que mencionas. Nada impide que hagas un programa así con GM, no hay regla que lo prohiba.

EN la imagen, ¿cada color fue un objeto distinto? Si es así, lo que debes hacer es que antes de dibujar un color, se debe preguntar si en esa zona ya existe un color (un objeto) Si resulta que sí, se debe preguntar la profundidad de ese objeto (o llevar un conteo en una variable) y disminuir la profundidad del nuevo objeto (según la profundidad del objeto que ya existe o de la variable) para que quede por encima.

Desconozco qué método uses para dibujar los objetos, si fuera en el evento DRAW, entonces la estrategia tendría que ser distinta.

Antes de usar las funciones, lo mejor es consultar el manual para entender su funcionamiento.
http://docs.yoyogames.com/source/dadiospice/002_reference/movement%20and%20collisions/collisions/index.html

Cita de: arcangelcaos en Enero 10, 2015, 09:08:43 PM
El problema es que place_free simpre me detecta que hay una criatura, cuando no hay nada, nada de nada.

¿Estás seguro que debes usar place_free? place_free es una función que sólo funciona CON OBJETOS MARCADOS COMO SÓLIDOS. Lo que pienso que pasa es que como las instancias que pruebas no son sólidos, y la condición busca !place_free, entonces eso devuelve true, aunque en ese lugar no haya nada.

Cita de: arcangelcaos en Enero 10, 2015, 09:08:43 PM
Y lo peos es que collision_point siempre me devuelve -4, incluso si hay criatura.

Porque las funciones collision() se basan en dos máscaras de colisión: la del objeto que llama la función y la del objeto usado como argumento en la función. En tu caso, estás moviéndote en múltiplos de 96 pixeles ;MÁS ALLÁ de los límites de la máscara de colisión del objeto que llama la función, por lo que NUNCA habra colisión, a menos que la máscara de esa instancia fuera enorme y cubriera todo el terreno donde buscas objetos. Por eso nunca se detecta colisión.

Esta línea indica qué API hace falta instalar
c:\Program Files (x86)\Android\android-sdk\tools\ant\build.xml:542: Unable to resolve project target 'android-8'

Instalando únicamente la API 8 debería ser suficiente para solucionar el error en la mayoría de los casos, al menos.

Sí, pero como dice el manual, si se usa working_directory para leer, se puede desde leer desde las dos ubicaciones: primero busca en el área de guardado, y si ahí no está el archivo, busca en el game bundle.

Para escritura, sólo hay una una ubicación: el área de guardado, o appdata, como le dices. Si un archivo se cambia desde el juego, por ejemplo, un ini, entonces la copia con esos cambios se guardan en el área de escritura, pero el original se sigue manteniendo en el game bundle. Mientras no se borre el ini de esa área de guardado (que se puede), GMS siempre leería de ese ini y no le haría caso al ini original, que se supone no tiene modificaciones

Y sí, como dices, en el bundle no hay directorio "saves" porque la función directory_create sólo funciona, como es logico, en el área de guardado, pero se supone que una vez creado, ahí sería la primera ubicación donde GM buscaría leer el archivo

Es porque GMS trabaja en modo sandboxed, por lo que ya no se permite guardar en cualquier lugar del disco duro, sólo en ubicaciones específicas según el sistema operativo.

http://docs.yoyogames.com/source/dadiospice/002_reference/file%20handling/file%20system%20limits.html

http://docs.yoyogames.com/source/dadiospice/002_reference/file%20handling/directory_create.html

Revisa el manual, si observas el ejemplo que trae, te darás cuenta de lo que hace falta. Ánimo, es lo último que te falta para terminar!  :D

http://docs.yoyogames.com/source/dadiospice/002_reference/file%20handling/ini%20files/ini_read_real.html