Comunidad Game Maker

No estoy seguro de cómo hacerlo, casi no he trabajado con sonido en :GMS:, sin embargo, en éste artículo se menciona que es posible cargar audio desde internet https://www.yoyogames.com/tech_blog/87

Puedes usar la variable solid, pero sólo tiene utilidad si se usa un evento de colisión o con las funciones de movimiento. En las funciones collision_ no se toma en cuenta si las instancias son sólidas. Otra opción es crear una variable que indique si la instancia está en juego:
[gml]
with( obAmigo )
{
    if( en_juego )
    if( collision_ellipse( x1,y1, x2,y2, other.id, false,false ) )
    if( vida < other.dano ) { scratake(other.id,id); break; }
}
[/gml]

Hace tiempo que estoy pensando en hacer un motor para eso, pero no lo he empezado porque me voy a saturar con muchos proyectos a la vez. La idea es definir un conjunto de vértices, ya sea de forma automática o manual, para formar líneas que actúen como el piso. Para introducir los vértices de forma manual, he pensado en usar "paths", de esa forma se podría dibujar a gusto la línea que mejor se adapte al escenario, y usar rampas con cualquier inclinación. Me puse a investigar y confirmé varias de las ideas que tenía leyendo un libro de física para videojuegos, en ese libro se le da un nombre al sistema, pero no recuerdo cuál es. La misma técnica o sistema se aplica frecuentemente en los juegos en 3D para detectar colisiones (aquí hay un ejemplo). No he encontrado un lugar que esplique esto de forma clara y sencilla para recomendarte.

No entendí bien, ¿porqué si el enemigo ha encontrado un contrincante pasa al siguiente?
Si la detección se hace en zonas inesperadas es porque las coordenadas de la elipse no son correctas.

Asignando una variable z a los personajes y al piso, entonces se procede como en un juego de plataformas: si el personaje toca el piso puede saltar (z del personaje == z del piso); al saltar se asigna una velocidad en z y actúa la gravedad (también en z); cuando se alcanza el nivel del piso al caer, la velocidad en z se hace cero y la posición z se hace igual a la del piso.

Para que se puedan detectar varias colisiones de la instancia "enemigo" con las instancias "amigo", la colisión se debe determinar desde las instancias "amigo". El código se podría colocar dentro del objeto amigo, o usar un with en el objeto enemigo:
[gml]
with( obAmigo )
{
    if collision_ellipse( x1,y1, x2,y2, other.id, false,false )
        if( Vida < other.dano ) { scratake(other.id,id); break; }
}
[/gml]
El break termina la búsqueda si es que ya se realizó un ataque.

Y desde el punto de vista opuesto a la filosofía, en cuestiones técnicas, tampoco es azar porque el algoritmo (y el hardware) que genera los números tiene una cantidad finita de posibilidades. http://es.wikipedia.org/wiki/Generador_de_n%C3%BAmeros_aleatorios

La forma de hacer el agua va a depender mucho del tipo de juego y cómo quieras que reaccione con el entorno. Escribe "agua" en el buscador del foro y van a aparecer algunos ejemplos, incluso uno hecho con el motor de físicas de GMS. Sería mejor que proporciones más información para ver cuál es la mejor alternativa.

Estoy trabajando en un proyecto en el que uso muchos arreglos 2D, y esos arreglos tengo que guardarlos y cargarlos desde archivos externos.

Al principio, para simplificar el código, usaba ds_grids, y con la ayuda de las funciones ds_grid_write y ds_grid_read manejaba las matrices como una sola cadena de texto.

Después empecé a trabajar con ENIGMA y me dí cuenta de que el juego tenía un rendimiento mucho mayor, el problema es que las ds_grids creadas con GM no son compatibles con las de ENIGMA, entonces para que el juego fuese compatible con los dos ambientes de desarrollo, comencé a guardar los datos en archivos de texto usando las funciones file_text_write_real y file_text_read_real, esto funciona bien, pero no me gusta que los archivos quedan de un tamaño muy grande para la información que contienen, y además se pueden editar fácilmente con el block de notas.

Ahora he pensado en crear algunas funciones para guardar los datos de forma parecida a como lo hacen las funciones ds_grid, pero no tengo suficientes ideas o información para empezar. Sé que internamente GM maneja los números en tipos parecidos a los que se usan en C (bool, int, float, double), y cuando se inicializa una variable, ésta ocupa la menor cantidad de bytes necesarios para guardar la cantidad requerida, cuando el valor cambia también puede cambiar el tipo interno. También he notado que los números enteros con signo se representan usando el complemento a dos, pero no tengo idea de cómo se representan los números con punto flotante.

La forma de guardar también puede depender de la codificación del archivo de texto. Otra opción es guardar en archivos binarios.
Espero que alguien pueda ayudarme con información o ideas.
Gracias.

Gracias por la información Silver_light, nunca he programado en pascal por eso me parecen extraños. Cierto, la palabras begin y end ya las había visto, no me acordaba. De los símbolos me quedo con <>, porque me parece más fácil de escribir que !=, y creo que se ve mejor. Lo bueno es que hay diferentes opciones para dar legibilidad y buena apariencia al código.

Algunas veces he encontrado códigos que usan estos operadores:
[gml]
<> //diferente a
:= //asignación, comparación
[/gml]
y según mis pruebas son equivalentes a estos:
[gml]
!= //diferente a
=  //asignación, comparación
[/gml]
todos funcionan igual en :GM8: y :GMS: ¿Alguien sabe si tienen un comportamiento especial?

Ya encontré el error, y no se debía a lo que comenté antes, sólo faltaba poner una línea:
[gml]
else swipe = NINGUNO; //si no se toca la pantalla, no hay swipe
[/gml]
Dejo el proyecto con las correcciones, hay que hacer otras pruebas, espero que no tenga errores.

Si, ya se a qué te refieres, ¿lo has probado en windows, no?. El problema es que eso se debe al propio funcionamiento de :GMS:; los eventos del ratón no se actualizan cuando el puntero está fuera de la ventana, entonces cuando sueltas el botón del ratón fuera de la ventana no se detecta el evento "relesased" y se siguen creando los efectos aunque el botón no esté presionado. Para hacer que :GMS: actualice el estado del botón, es necesario poner el cursor dentro de la ventana, hacer click y volver a soltar el botón. Se supone que ese problema no ocurre en un dispositivo móvil porque no se puede poner el puntero fuera de la ventana de juego.

Ya intenté solucionarlo probando con la función mouse_clear, pero no dió resultado. Otra idea es usar las funciones device_mouse_raw o display_mouse_get para saber cuándo el puntero se ha salido del la ventana y entonces dejar de detectar los swipes, pero es una solución parcial, porque tampoco es posible detectar si se ha liberado el botón.

Dentro del proyecto encontré un error, sucede al cambiar de room mientras está presionado el botón del ratón, para solucionarlo sólo hay que inicializar unas variables en el evento Create
[gml]
//para obSwipe1
xa = mouse_x;
ya = mouse_y;
[/gml]
[gml]
//para obSwipeMultiple
for( i=0; i<5; i++ ) //inicializar arreglos
{
    swipe = NINGUNO;
    xa = device_mouse_x(i);
    ya = device_mouse_y(i);
}
[/gml]

También me he dado cuenta de que interpreté tu primer mensaje de una forma, sin embargo, se puede interpretar de otra forma, y entonces el código sería ligeramente diferente; en el código de obSwipeMultiple pensé en crear sólo un tipo de objeto a la vez y por eso usé un algoritmo para determinar el "swipe_final", ahora he pensado que tal vez quieres crear diferentes objetos a la vez dependiendo de la dirección del swipe de cada dedo. ¿Cuál forma te parece mejor?

Hola Gutic, ya estuve ocupado unos días con éste juego, parece sencillo a simple vista, pero tiene una inteligencia artificial muy bien realizada. El problema es que no puedo terminarlo, aparece un error que hace que el juego se cierre, ocurre al vencer a Magnot. El mensaje dice: "Tactical RPG dejó de funcionar". Estoy usando W7, voy a probar en otra máquina para ver si no sucede el mismo error.

Me pareció interesante la idea de usar múltiples swipes, y por fin tuve tiempo de programar un ejemplo (que está adjunto).

En el proyecto hay dos objetos, en el primero está el código para reaccionar a swipes con un sólo dedo y en el segundo se ha extendido el código para reaccionar a múltiples swipes, no tengo forma de probar el segundo ejemplo, pero estoy casi seguro que funciona.
Para trabajar más fácil con los "switch" primero se crearon 5 constantes (en el Árbol de recursos -> Macros -> All configurations) con estos valores

NINGUNO=0
DERECHA=10
ARRIBA=20
IZQUIERDA=30
ABAJO=40


---

En el objeto obSwipe1, en el evento Create se inicializan las variables activo y swipe. La variable activo indica si se puede, o no, reaccionar al swipe realizado, esto es necesario para poner un tiempo de espera antes de volver a reaccionar y así evitar que se agreguen muchos objetos seguidos. A la variable swipe se le asigna alguna de las constantes creadas al principio.

En el evento Step se detecta el swipe. Pensé en dos formas para detectar el swipe:

• la primera es hacer que el punto inicial del swipe es donde se hace click y el punto final es donde se levanta el dedo
• la segunda forma es determinar la dirección del swipe con el movimiento continuo del puntero, sin necesidad de bajar y levantar el dedo

Creo que la segunda es mejor para un juego rápido y es la que está implementada.

Al detectar un swipe se inicia una alarma, la variable activo se hace false y se crea un efecto que depende del valor de la variable swipe. Cunado la alarma termina de contar se restablece la variable activo.

---

En el objeto obSwipeMultiple se extiende el código para revisar los cinco puntos táctiles (en vez de usar las funciones "mouse" se usan las funciones "device_mouse") y las variables que guardan las posiciones de los punteros y los tipos de swipe se convierten en arreglos (de 5 elementos).

Aquí cada dispositivo puede realizar un swipe en diferente dirección, por lo que se necesita un modo de determinar una sola dirección dominante, pensé en dos formas para determinar la dirección y la cantidad de dedos usados:

• la primera es contar cuántos swipes se realizan en cada dirección y el que tenga mayor número es el dominante, sin embargo, si todos los dedos hacen un swipe diferente no hay dominante y se podría ejecutar una acción al azar, además ésta forma es más difícil de implementar comparada con la segunda
• en la segunda forma se determina una dirección final si todos los dispositivos que realizaron un swipe lo hicieron en la misma dirección aproximada

La segunda forma es la que está en el ejemplo, ahí se asignan las variables swipe_final y contador. La variable contador guarda la cantidad de dedos usados en el swipe y en una parte la variable se limita para contar sólo hasta 3
[gml]if( contador > 3 ) contador = 3;[/gml]
sin embargo se puede eliminar esa línea para detectar hasta cinco dedos.

Usando las constantes creadas al principio, se simplifica mucho el código para ejecutar acciones que dependen del swipe final
[gml]
switch( swipe_final + contador ) //ejecutar una acción
{
    case DERECHA + 1: //swipe a la derecha con un dedo
        effect_create_above( ef_explosion, x+200,y, 2,c_blue );
        break;
    case ARRIBA + 1: //swipe a la izquierda con un dedo
        effect_create_above( ef_firework, x,y-150, 2,c_blue );
        break;
    case IZQUIERDA + 2: //swipe a la izquierda con dos dedos
        effect_create_above( ... );
        break;
    case ABAJO + 3: //swipe hacia abajo con tres dedos
        effect_create_above( ... );
        break;
}
[/gml]
Como mencioné al principio éste, código no lo he probado con multitouch, pero con un dedo funciona bien. No completé las acciones a realizar con múltiples dedos, eso tienes que agregarlo tú.

Espero que se entienda, cualquier duda me dices.