Comunidad Game Maker

Si el único requisito del autor para usar su música es darle crédito, no debiera haber problema con el uso que le das, sea cual sea, mientras le des el crédito. Normalmente los autores que sólo piden que se les de crédito indican explícitamente que se puede usar su música incluso con fines comerciales. Revisa la descripción del video para aclarar si sólo pide créditos y nada más.

Cita de: NiuWeb en Octubre 09, 2015, 07:20:32 AM
Si con la ayuda que Kostra te dio tampoco funciona, el problema es sencillo. Leí detenidamente tu problema y encontre esto:

Citaral exportarlo para android, tengo problemas al salir del juego y volver a entrar no retoma las variables

Y el problema es fácil de arreglar, sólo ve a la sección de Global Game Settings, ve a la pestaña de Android, y luego a la pestaña de Permissions...
Normalmente tendras sólo la casilla de INTERNET marcada, si no necesitas internet la desactivas, y activas la casilla de WRITE_EXTERNAL_STORAGE, que es la que le da a tu juego permiso para almacenar datos en el teléfono...saludos XD

Yo nunca he activado esa opción y no he tenido problemas al guardar archivos en la save area. Creo que el problema es por otra cosa. Habría que ver el código con el que se guardan y leen los datos en el ini.

Si intentas leer un archivo vacío no obtendrás una cadena vacía desde él. Lo que corresponde es que antes de leer verifiques que no se ha llegado al final del archivo con file_text_eof.

Tomando la idea de fasst007 para llevarla a código, puedes crear un script que retorne el sprite asociado a un tipo de gusano y un estado. Por ejemplo:

//argument0=número de gusano
//argument1=estado ("aplastado", "muerto")
return asset_get_index("spr_gusano"+string(argument0)+"_"+argument1);

Para que funcione, los nombres de los sprites deben estar en la forma spr_gusanoN_estado, donde:

N=1,2,3....,10 que representa el tipo de gusano
estado=aplastado, muerto

entonces, por ejemplo, el gusano tipo 3 en su estado muerto quedaría como spr_gusano3_muerto.

Donde necesites saber qué sprite corresponde a un gusano que ha cambiado su estado, invocas al script con esos 2 argumentos. Por ejemplo si nombras al script scr_spr_gusano, para cambiar el sprite del gusano tipo 7 a aplastado colocas:

sprite_index=scr_spr_gusano(7,"aplastado");

Probablemente esto pasa: la velocidad horizontal del personaje nunca es cero y por lo tanto cuando colisiona horizontalmente con el suelo, lo hace una y otra vez en cada step, haciendo que su posición retroceda a la anterior (por colisionar con un sólido) y quede atascado. Yo colocaría esto:

Evento de colisión con suelo:
move_contact_solid(direction,12);
if !place_free(x,y+1)
    vspeed=0;
if !place_free(x+1,y)
    hspeed=0;

Evento step:
if place_free(x+1,y)
    hspeed=12;

Probablemente tienes alguna instancia que no tiene máscara de colisión o no está permanentemente dentro del view y que debe estar activa siempre. En ese caso tendrás que asegurarte de que siempre esté activa. Por ejemplo puedes modificar el código así:

instance_deactivate_all(true);
instance_activate_region(view_xview[0],view_yview[0],view_wview[0],view_hview[0],true);
instance_activate_object(objeto que dibuja las cosas de la pantalla);

Tendrías que aclarar si el evento que utilizas como referencia es el morir o el reiniciar el nivel, ya que no producen necesariamente resultados iguales: puede ser que al morir simplemente coloques al personaje en su ubicación inicial; puede ser que además reinicies el room (en cuyo caso la solución es distinta) o puedes reiniciar el juego completo, donde también la solución es distinta.

Suponiendo que el método que escogiste es reiniciar el room, lo que yo haría a primera vista sería colocar mediante código (y no en el editor del room) las instancias que dan una vida, ya sea desde el código de creación del room o desde el room start de un objeto controlador. Para saber cuáles colocar, en una variable global tipo array previamente definida guardaría para cada una de esas instancias sus coordenadas y si corresponde ser creada o no. Cuando una de esas instancias toca al personaje y entrega la vida, debe actualizarse el array para cambiar a falso el elemento asociado a esa instancia que indica si debe ser creada o no, de modo que en un room restart ya no vuelva a ser creada. Esta es sólo una idea y puede parecer engorrosa pero por el momento no logro pensar en algo mejor.

Cita de: PabloPbl en Septiembre 18, 2015, 02:49:11 PM
Si, me acabo de dar cuenta  :-[

Ahora que lo veo, no es que sea un sistema limitado, lo que pasa es que  :GMS: esta hecho de esta manera por el tema de la potabilidad, en Android el working_directoy, seria otra ruta, al contrario de Windows o otros SOs que tienen su propia "área de trabajo".

Muchas gracias por tu ayuda, un saludo.

Está limitado intencionalmente por un asunto de seguridad, para evitar que el juego acceda a otros archivos del usuario no relacionados con el juego.

Prueba agregando esto a tu código del personaje:

evento Create:
tsalto=round(2*vsalto/gravity);//tiempo de un salto, vsalto es el módulo de la velocidad con que salta; gravity es la gravedad
z=0.2;//grado de zoom (0=100%, 1=200%, etc.)
zoom=false;//indica si se está haciendo zoom
vw=view_width[0];
vh=view_height[0];

evento alarm[0]:
zoom=false;//termina el zoom
view_wview[0]=vw;
view_hview[0]=vh;

evento step:
if zoom
    {
    view_wview[0]=vw*(1+z*sin(pi*(t/tsalto)));
    view_hview[0]=vh*(1+z*sin(pi*(t/tsalto)));
    t+=1;
    }

evento de salto (puede ser key press vk_up o lo que sea):
salto=true;
t=0;
alarm[0]=tsalto;

El engine del movimiento del personaje lo defines tú.

EDIT: dejo por si las dudas un editable con lo mismo.

Para hacer un juego destinado a android no tienes otra opción más que comprar la versión pro de  :GMS: más el módulo de exportación a android. La versión gratuita sólo permite crear juegos para Windows. Ambas cosas suman alrededor de US$450 al día de hoy.

http://www.yoyogames.com/studio

Más que memoria te ahorras uso de CPU ya que la memoria que utilizan las instancias desactivadas no es liberada pero sí se ignora el código de todos sus eventos y el dibujo de su sprite. Si la view se mueve permanentemente, tendrás que usar esas funciones en step ya que puede haber instancias que en cualquier momento entran o salen del view. El ejemplo del manual para instance_activate_region debiera servirte:

instance_deactivate_all(true);
instance_activate_region(view_xview[0],view_yview[0],view_wview[0],view_hview[0],true);

Ese código debiera ir en un objeto controlador en el evento step.

Utiliza las funciones instance_activate_region e instance_deactivate_region con las coordenadas y dimensiones de la view como la región a activar/desactivar.

La variable working_directory es de sólo lectura, como te lo indica el mismo mensaje de error, y todos tus intentos por guardar archivos en otro lado fracasarán. Las únicas excepciones son las funciones get_open_filename y get_save_filename que están disponibles sólo para windows. Tendrás que acostumbrarte a este sistema más limitado de  :GMS: para acceder a archivos.

Puede ser que estás buscando en el lugar equivocado. Suponiendo que no has leído en el manual el apartado File System Limits, ahí se indica la ruta donde se guardan los archivos que crea GMS y que corresponde a la Save Area. En Windows 7, por ejemplo, corresponde a este directorio:

/Users/<User Name>/AppData/Local/<Game Name>

Antiguamente la ruta por defecto para manipular archivos que tenía GM era la misma carpeta del ejecutable, pero eso dejó de ser así. Si vas a usar inis o cualquier archivo externo, es muy importante que entiendas cómo funciona el sistema sadbox; para el caso de los inis, por ejemplo (y me estoy adelantando a un futuro problema que podrías tener), verás que si tienes uno en included files, los cambios que le hagas no se verán reflejados en la Save Area. Tendrás que acostumbrarte a utilizar como prefijo de ruta para operaciones con archivos la palabra clave working_directory. Estudia con detención ese capítulo.

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

También puedes ver esa información corriendo el juego en modo debug: en la parte inferior aparece la memoria utilizada (dentro de otras cosas), y en Set type - All instances puedes ver cuántas instancias de cada objeto existen.