Comunidad Game Maker

Según el punto número 2 del primer post, GM8 sí está limitado a leer inis sólo en el directorio del proyecto

http://gmc.yoyogames.com/index.php?showtopic=375804


...uh, el propio manual lo dice  :-[

CitarThe ini file must be stored in the same folder as the game!

A manera de pregunta

Si  ini_open() crea un INI nuevo, ¿qué datos se crean dentro de ese INI nuevo?

En la mayoría de ejemplos en el foro de YoYo he visto que casi siempre comprueban si existe el archivo ini antes leer/escribir, lo que me hace pensar (sólo pensar, no asegurar) que ini_open() no crea un archivo. Pero si se creara, cómo saber qué llaves y secciones leer del ini si lo creo GM y no el usuario?}

Vampy: el enlace que pusiste apunta al manual de GM:S, pero según el ícono del mensaje original, el makero unixhacker usa la versión 8. A lo mejor me equivoco, pero creo que una de las limitaciones del sistema ini de GM8 es que los inis sólo se pueden ubicar dentro de la carpeta donde se encuentra el archivo gmk/gm81. Si quieres usar un ini fuera de esa carpeta (por ejemplo, dentro de un subdirectorio), hay que usar una dll que maneje inis (hablo de gm8, no de gms)

Otra manera podría ser que cada objeto edificio tuviera un sprite con dos subimágenes. Cuando el jugador esté fuera, se muestra la imagen techada, y cuando el jugador esté dentro, se muestra la imagen sin techo. Aunque de esta forma a lo mejor se vería muy brusco el cambio entre imágenes, tendrías que trabajar el efecto para hacer un tipo "fade in" - "fade out" al techo.

Eso implica una solución sencilla. Intenta pensar qué harías para resolverlo. "Sé la grúa"

EDIT:

OK, cambiado a que se resten movimentos cuando el objeto se mueva y no cuando se presione una tecla (aunque si el objeto se mueve es porque se presionó una tecla). En lugar de leer el teclado se opta por usar la variable predefinida direction .

No sé si vaya a funcionar, pero y si usas esto en [DRAW] del controlador?

draw_background(mi_fondo, view_xview[0], view_yview[0])

A algunos les funciona y a otros no, pero puedes probar a activar la opción
"Use synchronization to avoid tearing " En los ajustes generales, pestaña windows.

EDITADO:
La verdad no entiendo por qué quieres hacer esto, pues si el fondo siempre queda anclado a la view, el efecto es que todo es estático, parece que el jugador nunca se mueve (aunque sí se mueva) en la pantalla. Acabo de probar

draw_background(mi_fondo, view_xview[0], view_yview[0])

en GM8.1 y funciona bien, no hay problemas de retraso en la imagen

Modifiqué tu proyecto.

Revisa el evento STEP del jugador y los eventos de teclas (UP, DOWN, LEFT, RIGHT)

Cita de: luckylandia007 en Abril 06, 2014, 09:18:53 AM
la gema no se va a volver a generar si ya la obtuve durante la partida pero si empieza TODO el juego de nuevo si va a estar presente otra vez. Al recurso del INI lo veo mas para save games o actualizar estados en largas partidas progresivas...

Sin haberlo implementado, creo que el procedimiento que puse antes funciona perfectamente para esto. Todo es cuestión de controlar cuando pasar datos del arreglo al ini. Si TODO el juego se reinicia, partida = 0 y todas las gemas originales estarán presentes, si hay un room restart, partida va a ser distinta a 0, por lo que se usa el ini (y al comenzar un juego totalmente nuevo el ini vuelve a iniciciar con los valores originales). De acuerdo con que es un método enredoso, pero hay muchas maneras de hacerlo, el método de vampy parece ser el más inmediato, pero se puede hacer con variables, arreglos, inis, ds_lists o ds_maps, colas, etc, todo se basa en un IF que revise si se hizo un room_restart o si se empezó una partida totalmente nueva.

igual se puede usar el tiempo total de la partida (no recuerdo el nombre de la variable), para decidir si es un juego nuevo o ya se ha jugado otro. Tampoco sé si esta variable toma en cuenta el tiempo desde que inicia el juego o desde que se carga la primera habitación, pero es cuestión de hacer pruebas

Yo lo haría con INIs/archivos de texto

En GM, una variable de nombre partida iniciada en 0 a la que se le sume 1 cada que haya un room_restart() o un game_restart(). Esto serviría para saber si es la primera vez que se ejecuta el juego o ya se había jugado antes.

Si es la primera vez (partida = 0), leer el número de gemas desde un arreglo. Digamos que indica cuantas gemas hay en una habitación
gemas[0] = 5         //Gemas rojas
gemas[1] = 10       //Gemas verdes
gemas[2] = 8        //Gemas azules

A partir de este momento (haber colocado la distribución original de gemas) el arreglo ya no se usa. Sus valores se copian a un archivo INI.
[GEMAS]
roja= 5
verde= 10
azul=8

Los valores en el arreglo nunca cambian porque son los valores originales. Los valores en el INI cambian cada que se recoje una gema (se leería la llave "roja" y a su valor se le restaría 1, y ese nuevo valor se escribiría en "roja"). El arreglo sólo se leeria la primera vez, cuando partida = 0, pero después de eso, todos los cambios y lecturas se basan en el INI

No es tan directo, pero eso es lo que se me ocurrió.

Quien tiene la última palabra eres tú mismo. Pienso que se requiere algo de tiempo, alrededor de uno o dos meses para saber si GM es la aplicación que buscas. Tiempo para conocer la filosofía de GM, sus limitaciones y sus fortalezas. Quizás para ti haya programas más potentes, o quizás sea potente pero no te gusta la manera en que trabaja/está organizado. Yo he visto opiniones de usuarios (no en este foro) que consideran a GM enredoso y se cambian a otra plataforma donde hay métodos ya pre-diseñados de hacer cosas. igual si quieres hacer 3D de manera profesional GM definitivamente no es la mejor alternativa

Sobre las imágenes: En GM por lo general esa mecánica que buscas para tu juego no se trabaja directamente con imágenes, sino con objetos en donde cada uno tiene una imagen asociada a él (su sprite). Que aparezcan en pantalla muchas imágenes sería que pusieras muchos objetos en la habitación, marcar las imágenes sería hacer click en esos objetos.

hay que poner "candados" a la selección con el ratón, es decir, diferenciar si lo que se elige es una bala o es un enemigo, y además hacer que no se pueda seleccionar un enemigo sin antes haber seleccionado una bala.

Usé objetos padre en el ejemplo, porque así las colisiones se controlan de manera más sencilla.

el manual actual de GM:S, de lo contrario no necesitaríamos traducir  :-[

Cita de: Gyga8k en Abril 04, 2014, 07:52:20 PM
y nunca me mandaron nada para traducir.

Cita de: Gyga8k en Diciembre 25, 2013, 07:43:44 PM
No puedo ponerme a traducir por mi tiepo y mi ingles no es tan bueno pero puedo pagarle a alguien aqui para que lo haga, asi que por ejemplo podrias preparame un archivo con unas 30 o 50 paginas y yo pago para que la traduszcan y te las paso, pero lo de ornenarla y quisas ponerle enlaces y eso se encargarian ustedes, hablame por skype: gyga800

Buscamos que la traducción la haga gente que tenga algo de experiencia en GM y un nivel de inglés aceptable, aunque avancemos lento. Veo muy improbable que un traductor profesional o la persona a que le pagarías tengan conocimientos de GM y GML, además que el texto no está limpio, sino que va con enlaces y demás etiquetas HTML. Es un manual comunitario, no me gustaría que pagues por las traducciones.

Por otra parte, no hay muchas novedades qué enfatizar, se siguen traduciendo temas, ¿pero a quién le serviría un manual incompleto? Paciencia, algún día, el menos esperado, llegará este bebé en español para beneficio de la comunidad  XD

Si quieres explicaciones con pelos y señales, pon tu código con pelos y señales. Lo que solicitas es tan sencillo como usar un IF, tal como dijo Caleb, son tres o cuatro líneas de código

Leer INI para obtener puntuación más alta guardada
Leer variable de GM con el puntaje actual
Si la variable del puntaje actual es mayor que la puntuación del INI más alta, escribir la variable del puntaje actual en el INI

No, eso es lo bueno. Cada instancia tiene las variables definidas de acuerdo al objeto enemigo, es decir, si en el objeto enemigo creaste una variable vida, cda instancia del objeto enemigo al ser creada tiene automaticamente su variable vida, pero esta variable es independiente de las otras.

Para conocer la id de la instancia bajo el mouse puedes usar la función en el evento de click del ratón
id_enemigo = instance_position(mouse_x, mouse_y,obj_enemigo)

De esta manera, si al hacer click hay un enemigo bajo el puntero,  su id se guarda en la variable id_enemigo. Después de saber la id de un enemigo, usas esa id para referirte a ese enemigo en particular, or ejemplo para

quitarle vida
id_enemigo.vida -= 5

que el jugador vaya hacia el enemigo
move_towards_point(id_enemigo.x, id_enemigo.y, 4)

Creo que para ambas preguntas, la respuesta es no, al menos no se puede sin el uso de dlls o extensiones. Antes se podían usar las funciones execute_shell o execute_program, pero ahora ya no funcionan por ser obsoletas, además de muy poderosas y peligrosas. No creo que GM:S sea capaz de interpretar por sí solo etiquetas HTML y desplegar una página en la ventana del juego.

para casi todo existe un solución alternativa, pero hasta donde conozco, se me escapa. Aunque me gustaría que alguien diera una.