Comunidad Game Maker

Cita de: Texic en Enero 11, 2013, 06:42:24 PM
Me suena a kaillera xD

Sí, con Kaillera pasa seguido.

Cita de: Texic en Enero 11, 2013, 06:42:24 PMLa desincronización de un juego así no es muy grave, es más que esperable, no es como en kaillera que los emuladores tienen que estar completamente sincronizados para funcionar.

¿Cómo que no?

Cita de: Texic en Enero 11, 2013, 06:42:24 PMCon respecto al efecto que mencioné, no hablo de la latencia, hablo de datos que quedan en cola, y más datos que quedan en cola, y así infinitamente hasta que la cola es tan grande que lo que haces llega 20 segundos después a los demás.

Me pregunto cómo hiciste para lograr ese efecto...

Cita de: Texic en Enero 11, 2013, 06:42:24 PMPD: Con tu método sucedería otra cosa que no me gusta, recuerda que la latencia sube y baja constantemente, y la actualización de coordenadas a veces llegaría antes y a veces más tarde, produciría un efecto muy extraño en el movimiento de la bala, parecería una bala con epilepsia xD

Puede ser, pero el efecto no debería ser muy perceptible, a no ser que los fps de alguno de los jugadores estén muy bajos.

Cita de: francordoba en Enero 11, 2013, 05:56:59 PM
Acabo de probar el código Wadk.

Funciona muy bien, respetan su sitio, esquivan y buscan el lugar más cercano. El único inconveniente es como antes. Empiezan a la izquierda del personaje, se mueven con el cuando pulso la tecla, pero, cuando la suelto vuelven a estar siempre a la izquierda.

Qué raro. ¿Podrías poner el editable que estás usando para probar?

CitarPor cierto: ¿Soys programadores?, es decir, ¿vuestro alto nivel se debe al simple uso reiterado del GameMaker, o programabais de antes? A mi el código me cuesta horrores. (Soy diseñador  8))

Yo empecé con Game Maker hace años, y después me fui moviendo a php, Python, C y C++, entre otros.

Texic, el "asqueroso efecto" que mencionás es producido por la latencia; la des-sincronización es más grave y no se puede arreglar de forma ninguna. Si ocurre, básicamente lo único que podés hacer es reiniciar el juego y probar otra vez.

brunoxzx, ¿por qué tanta complicación? con mp_potential_step es un toque.
Esto debería funcionar:
[gml]// align_allies(len, dir, cover_angle, speed);
var len, cover_angle, dir;
len = argument0;
dir = argument1;
cover_angle = argument2;
with (objAlly) {  // Cambiá objAlly por el nombre del objeto aliado.
    dir += cover_angle / (instance_number(objAlly) + 1);  // Y acá tambien.
    mp_potential_step(other.x + lengthdir_x(len, other.direction + dir),
                      other.y + lengthdir_y(len, other.direction + dir),
                      argument3, false);
}[/gml]
Eso hace que busquen el camino más corto a la posición.
Si querés que se muevan de una manera específica, lo que podés hacer es darles un par de variables, por elemplo, x_goal y y_goal y en step ponerles el código que haga que traten de llegar a la posición marcada por esas variables, y el script lo usás así:
[gml]// align_allies(len, dir, cover_angle);
var len, cover_angle, dir;
len = argument0;
dir = argument1;
cover_angle = argument2;
with (objAlly) {  // Cambiá objAlly por el nombre del objeto aliado.
    dir += cover_angle / (instance_number(objAlly) + 1);  // Y acá tambien.
    x_goal = other.x + lengthdir_x(len, other.direction + dir);
    y_goal = other.y + lengthdir_y(len, other.direction + dir);
}[/gml]
Y ahí el script lo único que hace es establecer x_goal y y_goal.

Me parece que estás confundiendo la dessincronización con la latencia. Latencia siempre va a haber, en WAN, LAN y hasta MAN, y no es tan grave. Los jugadores más afectados tardan un poco más en recibir y enviar datos, que puede suponer una desventaja, pero nada más. En cualquier caso, la latencia rara vez se ve afectada por la cantidad de datos que envíes (a no ser que envies una cantidad realmente descomunal); más bien por la conexión de los jugadores y el ping.
En cambio la des-sincronización de datos es un verdadero problema. Un jugador puede ver una cosa y otro puede ver otra completamente distinta, aunque la conexión sea perfecta y con latencia mínima. Y la mejor manera de tratar con la des-sincronización es evitar que pase.

Cita de: francordoba en Enero 11, 2013, 02:47:10 AMProblema de coordenadas relativas?¿ no creo.

De hecho sí, entre otras cosas xD. Error mío. Cambiá el script por este:
[gml]// align_allies(len, dir, cover_angle);
var len, cover_angle, dir;
len = argument0;
dir = argument1;
cover_angle = argument2;
with (objAlly) {  // Cambiá objAlly por el nombre del objeto aliado.
    dir += cover_angle / (instance_number(objAlly) + 1);  // Y acá tambien.
    x = other.x + lengthdir_x(len, other.direction + dir);
    y = other.y + lengthdir_y(len, other.direction + dir);
}[/gml]

y llamalo así:
[gml]align_allies(64, 95, 170);[/gml]

Esta vez está probado y debería funcionar.

Probá con este script:
[gml]// align_allies(len, dir, cover_angle);
var len, cover_angle, dir;
len = argument0;
dir = argument1;
cover_angle = argument2;
with (objAlly) {  // Cambiá objAlly por el nombre del objeto aliado.
    x = lengthdir_x(len, other.direction + dir);
    y = lengthdir_y(len, other.direction + dir);
    dir += cover_angle / instance_number(objAlly);  // Y acá tambien.
}[/gml]

Ejecutalo así al final de step del jugador:
[gml]align_allies(64, 170, 95);[/gml]

El primer argumento (64) es la distancia entre los aliados y el jugador.
El segundo (170) es el ángulo de covertura (con 360 tratarían de cubrir todo alrededor del jugador).
El tercer argumento (95) es el ángulo del primer aliado posicionado, relativo a la dirección en la que mira el personaje (variable direction).

No van a quedar exactamente como describiste, pero no creo que te vaya a molestar.

Cita de: Texic en Enero 11, 2013, 01:16:52 AMAdemás no hay que ser tan pesimistas con los fps, lo que más falla en un juego online es el envío de datos, los fps son muy secundarios

No es que sea pesimista, es que no se puede asegurar que los fps van a ser constantes durante el juego entero. Incluso, por ejemplo, usando el método que proponés, el usuario servidor podría bajar sus fps deliberadamente para que el usuario cliente no vea los objetos en donde realmente se encuentran.

Por otro lado, no entiendo por qué decís que lo que más falla es el envío de datos. En mi experiencia los datos se suelen enviar sin problema ninguno. Como mucho algún paquete se puede perder, si se envía por UDP. Sería un desastre que no existiera una manera fiable de enviar un paquete por internet.

Cita de: Texic en Enero 10, 2013, 12:54:30 PM
Mejor hacer que el cálculo de movimiento tenga en cuenta los fps y listo

Vaya. Yo no confiaría en eso. ¿Ya lo probaste anteriormente?

• Nombre del creador: Wadk
• Breve descripción de su función: Comprueba si un archivo dado es una partida guardada que corresponde al juego actual. Nótese que el script puede fallar si, por alguna casualidad estratosférica, un archivo cualquiera llega a tener el game_id del juego en cuestión en los bytes del 4 al 7. Creo que es más probable que te caiga un rayo en un día soleado, y después otro.
• Versión GM utilizada: :GM8: , posiblemente funcione en otras.
• Código del Script:[gml]// file_is_savegame(file);
  // Return whether the given file is a valid savegame of the current game.
  
  var f, i, value;
  f = file_bin_open(argument0, 0);
  
  value = 0;
  for (i = 0; i < 4; i += 1) {
      file_bin_seek(f, 4 + i);
      value += file_bin_read_byte(f) << (i << 3);
  }
  
  file_bin_close(f);
  return (value == game_id);[/gml]
  El único argumento es la localización del archivo a verificar.

Es un script que creé hace un par de años para una pregunta: http://www.comunidadgm.org/index.php?topic=11653

Pensé que ya lo había puesto en esta sección, pero lo busqué y no lo encontré, así que bueno, acá está.
Esta versión es un poco distinta (más optimizada) pero no está probada. Cualquier problema lo reportan acá.

Saludos.

Cita de: Silver_light en Enero 10, 2013, 12:05:37 AM

Cita de: Texic en Enero 09, 2013, 09:03:37 PM
Es para una bala? Silver, es mejor enviar la dirección, la velocidad y las coordenadas iniciales en el byte y asignarlos al crear, que el cliente saque sus propios cálculos, sino es un mambrollo de datos volando de un lado a otro y jamás te va a funcionar bien en wan

Si, son para disparos. Que el cliente o el servidor dispare y se vea en la otra pantalla.
Ok haré eso que dices así no hay tanto "embrollo de datos" haha

Yo no lo recomendaría. Las balas podrían des-sincronizarse a la más mínima fluctuación de los fps de alguno de los jugadores...
Lo que podés hacer, que es lo que más se recomienda en estos casos, es enviar la posición, la velocidad y la dirección una vez cada x steps. 5, por ejemplo. Así cualquier des-sincronización solo duraría un poco y no sería muy notoria, y a la vez te ahorrás tener que enviar los datos una vez por frame.

¿Esa forma, la probaste? ¿Y funciona? Porque para que funcione, el id de las balas en el cliente y el servidor debería estar sincronizado, y es muy difícil que pase...
Yo te recomendaría lo siguiente.

Para crear la bala:
[gml]clearbuffer();
writebyte(5);
writeuint(id);  // Enviás el id de la bala también.
sendmessage(global.tcp_cliente);[/gml]

Al recibir el paquete de creación de bala:
[gml]case 5:
    with (instance_create(0, 0, disparo)) {
        remote_id = readuint();
    }
break;[/gml]

El código para enviar las coordenadas como lo pusiste en el post anterior, y el código para recibirlas:
[gml]case 6:
    var recieved_remote_id = readuint();
    with (disparo) {
        if (remote_id == recieved_remote_id) {
            x = readshort();
            y = readshort();
            break;
        }
    }
break;[/gml]
No estoy seguro de si se puede usar break en un with. Si no se puede, sacalo, el código quedaría menos optimizado pero debería seguir funcionando.

EDIT: Por cierto, ahora que me fijo esto es exactamente lo que propuso Texic su primer post en el tema.

Cita de: brunoxzx en Enero 08, 2013, 12:08:26 PM

Cita de: Wadk en Enero 06, 2013, 06:57:04 AM

Citar0.000007
0.000006
0.000004
0.000012

Aparentemente el mío es el más lento, por lejos jaja. El de brunoxzx parece ser el más rápido. La única duda que me queda es si maneja bien los números negativos.

El mod en números negativos hace lo mismo solo que devuelve el resultado en negativo. Por ejemplo -450 mod 360 debe dar -90.

Entonces tu script es el mejor hasta ahora. Felicidades jaja.

Cita de: brunoxzx en Enero 08, 2013, 12:08:26 PM
Porcieto mi script en una sola linea seria:
[gml]return( argument0 mod 360 + 360*(argument0<0) );[/gml]
y tal vez sea igual de rápido que el anterior.

Se ve bien, aunque no puedo probar si funciona en Python porque el mod de Python (que se escribe %) se comporta distinto para números negativos...
De cualquier forma, la velocidad me dio exactamente igual que la versión con el if.

Cita de: Mr.Dudas en Enero 07, 2013, 03:44:17 PMno seria así?

Código [Seleccionar] Expandir

return abs ( ((((argument0 - argument1) mod 360) + 540) mod 360) - 180 )

No parece que haga lo mismo... para empezar lleva dos argumentos...
Si lo que quisiste decir fue esto:
[gml]return abs((argument0 mod 360 + 540) mod 360 - 180);[/gml]
en ese caso, pues tampoco.  El tiempo menor de ejecución de ese script me dio 0.000006, igual que el de Texic. Y no da el resultado correcto en unos cuantos casos, a veces ni siquiera un resultado equivalente.
Estas son algunas de las pruebas que hice. El valor de la izquierda es el argumento de la función, el del medio es lo que devuelve, y el de la derecha lo que debería devolver:
0 0 0
720 0 0
-362 2 358
-361 1 359
-360 0 0
-100 100 260
100 100 100
360 0 0
361 1 1
362 2 2
-720 0 0

Cita de: Texic en Diciembre 29, 2012, 08:29:06 PM
No es más facil así?
[gml]while argument0>360 {argument0-=360}
while argument0<0 {argument0+=360}[/gml]
Digo por la optimización, no es lo mismo sumar que dividir, hacer floor y multiplicar

Un pequeño problema; el primer while debería decir >=360, sino, el script podría devolver 360 (cuando debería devolver 0). La versión de romon_28 también devuelve 360 a veces.

Creo que la mejor forma si el número es positivo es usando mod, como propuso brunoxzx. Pero no recuerdo bien como es que el mod de GM maneja los mumeros negativos...
La forma que se me ocurre ahora de hacerlo es:
[gml]return (abs(argument0) mod 360) * sign(argument0) + 360 * ((abs(argument0) mod 360) * sign(argument0) < 0);[/gml]
Me gusta porque es una sola línea, pero no sé si es más rápida que las demás xD.
Si la versión de brunoxzx funciona bien con números menores a -360, creo que sería la mejor.
Si alguien que tenga GM se anima a hacer una prueba de velocidad...
Hice la prueba en Python, y estos son los tiempos de ejecución mas bajos para cada script, en el orden en el que fueron posteados:

Citar0.000007
0.000006
0.000004
0.000012

Aparentemente el mío es el más lento, por lejos jaja. El de brunoxzx parece ser el más rápido. La única duda que me queda es si maneja bien los números negativos.