[wip][multiplayer] arena3

B

#60 ty bro


Pequeña escapada hoy (sigo de vacaciones) para implementar física... ray casting server side para (entre otros) usar en el punto de mira del player.

En el vídeo, se puede ver al inicio el proyecto Webpack abierto. Al guardar archivo se auto recarga en el navegador.

Abajo dos consolas, izquierda con el servidor maestro que es el enlace Websocket y WebRTC al player. A la derecha el sub servidor que aloja la física del mapa de la estación.

El multi admite diferentes configuraciones, si maestro y esclavos están en la misma máquina se comunican vía memoria compartida, sino lo hacen vía sockets.

El cubo rojo es el punto de detección del rayo proyectado, probando de paso su respuesta con los colliders móviles de las puertas.

También he implementado mecánica FPS, falta pulir el punto de mira cuando tenga listo el ray casting...

Animación nueva para movimiento lateral.

Y disparo con iluminación dinámica.


2 1 respuesta
Kalgator

Está op!, sigue así! :D

1 1 respuesta
B

#62 gracias wapo xD

He resubido el vídeo a youtube, en gfycat quedó cortado, no pasa del minuto.

Hukha

#61 WTF
Escapada dice, como te cunden unos minutos
pinta dpm

1
B

Recuperando una cuenta de twitter que tenía abandonada para usarla con el proyecto.

B

Desarrollando el segundo servidor con las físicas de vuelo...

1 respuesta
Jastro

#66 te esta quedando guapo el juego :O

1 1 respuesta
B

#67 ty you


Desarrollando la física de vuelo server side (2)

1 respuesta
Wasd

#68 Disculpa si mis dudas son absurdas:

Entiendo que el worker 1 es para gráficos, el 2 para físicas y el 3 para la comunicación client/server.

  • ¿Todas las físicas del client pasan por el servidor autoritativo o solo un subset de estas?
  • Imagino que el servidor también utiliza CannonJS para los cálculos, ¿es así? (doy por hecho que si, si no me explota la cabeza)
  • Como limitas que no todas las físicas autorizadas lleguen a todos los clients? O bien llegan todas y ya el client elige lo que hace con ellas?
    Por si no se me entiende, me refiero a que si un player A está en la zona exterior y un player B en una habitación de la zona interior, si el player B rompe una taza, al player A no le interesa como han rebotado en cada frame los trozos contra el suelo, siempre y cuando al llegar a la misma habitación esté la taza rota.
  • ¿Eso se decide mediante el motor de renderizado, raycasting, u otra forma?
  • ¿En caso de que no lo hayas implementado todavía, tienes pensado hacerlo?
1 respuesta
B

#69 aparte del worker multiplayer, desde el hilo principal también está habilitada comunicación webrtc (los workers no admiten webrtc) aunque de momento no le estoy dando uso.

¿Todas las físicas del client pasan por el servidor autoritativo o solo un subset de estas?

Ahora mismo pasa todo, más adelante cuando llegue el momento desarrollaré esa parte.

Actualmente trabajo en modularizar el servidor.

Como limitas que no todas las físicas autorizadas lleguen a todos los clients? O bien llegan todas y ya el client elige lo que hace con ellas?

En un agar.io (top down) puedes determinar si envías o no al cliente calculando la distancia a la que se encuentra del objeto a sincronizar, usando un valor que garantice que esté en visible en pantalla.

En otro contexto, un juego con zonas completamente delimitadas (ej habitaciones cerradas) puedes marcar cada objeto y user presente en la room, con ese flag determinas que enviar.

Depende de cada caso.

Pero...

Si quieres física en mallas, colisiones con fuerzas (física compleja del lado del servidor)... el cuello será la física, no la gestión de red.

Imagino que el servidor también utiliza CannonJS para los cálculos, ¿es así? (doy por hecho que si, si no me explota la cabeza)

Actualmente si, pero podría cambiar a algo basado en C++.


No se realmente que tienes en mente... las preguntas así sin contextualizar suelen dar lugar a respuestas poco prácticas, igual deberías abrir devlog.


edit: la mejor optimización a plantearse es: enviar solo si cambia de estado/posición

1 1 respuesta
Wasd

#70 Gracias por las respuestas :)
Estoy pensando en abrir devlog si. Si lo hago pasate a saludar :) aunque mis proyectillos no tienen nada que ver con el tuyo. Son muchísimo mas sencillos, y a ver si con el tiempo voy cogiendo inercia.

No es que tenga nada en particular en mente, son preguntas así genéricas para hacerme a la idea de como se arquitecturiza un proyecto de ese tipo, y tengo curiosidad por cómo vas implementando cada parte. Mucho ánimo en el desarrollo.

#70debugZ80:

Actualmente si, pero podría cambiar a algo basado en C++. No veo motivo para reventones de cabeza.

No lo decía del palo "si no es así es que está mal!" ni muchisimo menos. Lo decía porque, en el caso de que las físicas se calculen tanto en cliente como en servidor (y como es lógico mandan las del servidor), posiblemente un motor de físicas en el backend distinto al del client podrían dar resultados distintos, y por lo tanto el server podría interpretar que alguien está intentando falsear las físicas desde su cliente. A parte de eso, imagino que si los cálculos fuesen distintos, el cliente vería una cosa y al poco rato vería otra (cuando recibe el packet del cálculo autoritativo del server, vaya). Realmente no se si sería así, aunque es lo que me dice la lógica, y de ahí lo de que "me explotaría la cabeza".

1 respuesta
B

#71 a calcular la física tanto en cliente como en servidor sólo le veo un uso práctico, hacerlo determinista para compensar el retardo de red.

Habría que mirar algo similar a como trabaja Photon Quantum...

La física del cliente, por ahora, la uso para efectos en el renderizador y para reproducir eventos sincronizados enviados desde el server pero sin crear dependencias en la física del server.

Más adelante podría cambiar...

B

Desarrollando la física de vuelo server side (3)

Ya hay precisión suficiente como para poder entrar y salir del tubo sin dificultad.

1 1 respuesta
Ridote

#73 Hostia hacía mil que no me metía, qué cambio. Por cierto, me da la sensación en el vídeo de que la nave vuelve siempre a su "rotación" original. ¿Puedes volar boca abajo? ¿O tiene siempre laparte inferior orientada al "suelo"?

1 1 respuesta
B

Es ajustable...

La idea es visualizar, focalizar el supuesto obstáculo que intentas evitar, ya sea abajo, arriba, laterales, para ganar precisión, inmersión.

1 1 respuesta
Ridote

#75 Chaval el ratón cuando vas con el tío por la nave está megasensible, bájale un poco la sensibilidad al menos cuando vas con el ingeniero andando por la nave. Luego le meto un try. ¿Hiciste tú todos los modelos?

Imagino que yo conecto a tu servidor al instanciar el juego en el navegador y que lo mismo para el resto, ¿pero en qué partes puedo ver a otros usuarios? Luego cuando no esté en el trabajo me meto con algún amigo a ver si nos vemos con las naves o algo.

1 1 respuesta
B

Yes... hay que añadir un ajuste de sensibilidad al input ¿a qué resolución has probado?

Los modelos son de pago.

Puedes ver al resto de usuarios en cualquier parte del mapa. Por ahora solo está disponible la estación, no hay vuelo.

Gracias por probar, me viene de perlas recordarme el ajuste del ratón.

1 respuesta
Ridote

#77 He probado a 1920x1080. Con habilitar el vuelo y poner disparos ya nos tienes haciendo el mongolo en el servidor... dicho queda.

1 1 respuesta
B

#78 si puedes entra aquí https://arena3.space/test.html

Me interesa saber en que rango se mantiene el primer valor de cada fila cuando el ratón está en movimiento.

Nota: Si el movimiento no es continuo dará valores altos que no me interesan.

1 respuesta
Ridote

#79 Haciendo ochos en la pantalla se mantiene entre 15 alto y 17 sin llegar a 17.

1 1 respuesta
B

Gracias you

1 1 respuesta
Ridote

#81 Avísame si quieres que testee algo, en casa tengo dos monitores uno grande y uno que creo que es del tamaño del que tengo aquí en el curro. ¿En cuánto estimas que podremos salir a volar con las naves? ¿1 mes? ¿Ni idea?

1 2 respuestas
B

Ni idea de cuanto tiempo voy a tener disponible. Pero vamos, si no hay contratiempos quizás un par de semanas o algo antes.

Ok thanks, por el soporte

1
B

El muestreo que entrega el navegador es frame dependiente... las cifras que indicas deben ser aproximaciones a 16.666 que son 60hz.

Si no me equivoco la prueba la hiciste con un monitor ajustado a 60hz ¿puedes confirmar?

1 respuesta
Ridote

#84 Confirmo. 60Hz

1 1 respuesta
B

PROBAR en ARENA3.SPACE