Lógica de turnos

MrBigel #1 May '18

¡Hola señores!

Tengo una duda, no sé si pequeña, ya que no se cuanto abarca su solución; el caso, es que estoy haciendo una aplicación web de tres en raya para practicar, y me encuentro con el problema de los turnos.

Es decir, si fuera algo totalmente local y "off-line" no me sería difícil implementarlos, pero quiero un aplicación en la que distintos usuarios de distintas IP's puedan jugar entre sí, por lo que no se que tecnología se emplea para esto o por donde van los tiros.

No os pido que me mostréis el mismo código que lo implementa, solo si sabéis y podéis informarme de que recursos se pueden utilizar en estos casos.

Muchas gracias.

NeV3rKilL #2 May '18 :psyduck:

Así a groso modo, como es 1on1, puedes hacerlo adhoc donde de alguna manera ambos se comportan como clientes y servidores a la vez.
La conexión puedes hacerla vía ip o hasta vía irc o email (hay juegos que van así). La cosa es que le llegue al programa lo que el otro quiere.

Puedes mirarte freeciv. Es un juego por turnos y tiene bastantes maneras de "conectar".

1

_Rpv #3 May '18

Pues yo lo haría con una bbdd y ajax jajajajajaja

Nada más entrar en la web que te de a elegir que si local u online (unirse a partida o crear partida)
en el caso de unirse a partida que tengas que introducir un código generado por el otro usuario al crear la partida.
Si le das a crear la partida, pues que se genere un código para identificar la partida en la bbdd

Igual me he tirado al agua de cabeza sin comprobar que la piscina estaba llena, pero es lo primero que se me ha ocurrido xd

1

Wasd #4 May '18

Un servidor nodejs en el back, con el motor de db que te de la gana.
Cada cliente se connecta via web utilizando una url, eligen un username que no esté repetido en tu bd, haces un matchmaking "sencillote" y en el back eliges quien empieza y trackeas cada turno, de forma que el servidor (autoritativo) es quien acepta cada turno cuando toca.

(cliente) A se conecta
(cliente) B se conecta
(servidor) realiza matchmaking
(servidor) elige quien empieza (digamos A)
(cliente) A realiza su turno (entiendo que le habilitas la interfaz para que pueda colocar su ficha)
(servidor) comprueba que el turno actual le pertenece a A. Le acepta la petición
(cliente) B ve lo que ha hecho A y se le habilita la interfaz
(cliente) supongamos que A te ha tocado el javascript y quiere hacer doble turno
(servidor) comprueba que el turno actual le pertenece a A. Meeec, error 403. Le devuelves un json con el estado actual de la partida y se lo pintas en la UI
(cliente) B realiza su turno
(servidor) comprueba que el turno actual le pertenece a B. Le acepta la petición

No tiene mucho mas, al menos así a priori, luego por el camino siempre salen cosas, pero a nivel básico eso es lo que veo.

2 4 respuestas

QuitCat #5 May '18 Gafe

#4 Entiendo que su duda va mas orientada hacía "como le dice el servidor al cliente que le toca mover ficha (sin que el cliente esté haciendo peticiones "es mi turno?" cada X tiempo). O al menos creo que esa es su duda.

1 respuesta

Wasd #6 May '18

#5 Comprendo.
En mi respuesta no había implícita ninguna tecnología de comunicación específica, aunque la más lógica que se me ocurre sería dejar un socket abierto y ahí se realizan los intercambios de datos en "tiempo real" sin que haya un proceso de pregunta-respuesta. Ahora bien, sigue siendo menester tener un servidor de por medio. Nunca he trabajado con comunicaciones p2p así que por ahí poco puedo ayudar.

NickNack #7 May '18 :psyduck:

la solución de #4 es la mas friendly, el resto con todo el resperto va ser que no. Un juego por turnos a tiempo real con una bbdd de por medio moviendo los datos... Si vale es el tres en raya y se podria hacer es simple, pero eso no se hace es caca.

2 respuestas

Wasd #8 May '18

#7 Mi propuesta incluye db, quizà te has equivocado al citarme. Sin embargo las queries no tienen por que ser en tiempo de ejecucion, sino por eventos generados por el servidor que maneja la lógica. Otro escucha los eventos y va insertando los datos. Yo lo digo principalmente por el tema estadísticas. Una bd para mi es algo bastante necesario si quieres ver la evolución del juego.

Creo que un palanteamiento interesante sería tener un redis o un mongo donde guardas los datos durante la partida (pérdida de rendimiento practicamente nula) y una vez la partida termina proyectas los datos que quieras a la bd principal.

Hacer un juego online sin almacenar datos dificilmente te permitirá mejorarlo ni ver las necesidades del grueso de usuarios.

B

[Borrado] #9 May '18

Backend: golang/nodejs y redis, frontend: lo que quieras usando websockets.

1 respuesta

QuitCat #10 May '18 Gafe

#7 No lo dejes en

Un juego por turnos a tiempo real con una bbdd de por medio moviendo los datos es caca.

Proponle una solución mejor y explicale las diferencias/beneficios aunque sea modo resumen. A mi también me interesa la respuesta de hecho

NickNack #11 May '18 :psyduck:

Un juego con la BBDD en medio moviendo los datos != Un juego con BBDD y datos

Pues claro que puiedes poner una base de datos de por medio para almacenar y coger ALGUNOS datos. Pero no vas a estar guardando cada vez que un juegador pone una X o un O el parametro en la base de datos. Por infinitas razones, la principal es que es un juego a tiempo real, la secundaria es optimización.

2 usuarios haciendo inputs en la BBDD cada 5 segundos... bueno, no va a pasar nada. Ahora, mete 400 usuarios (200 partidas simultaneas) y veras cuando los usuarios empiecen a hacer movimientos todos a la vez xdddd

No tengo que explicar nada, lo siento, si queréis saber un poco más #4 lo ha explicado bien por encima aunque no parece que lo entienda del todo (me he quedado un poco roto con esa respuesta, pensaba que entendías que estabas diciendo). Busca NODEJS y mira que es. #9 ha dado otra pista, yo usaria algo así aunque quizás usar Redis para esto si que es pasarse un poco xD

1 respuesta

Wasd #12 May '18

#11 Justamente mi respuesta en #8 habla de cómo evitar un excesivo uso de la bd, especialmente en tiempo de ejecución. ¿Qué es lo que te ha dejado con el culo roto, por curiosidad? Si lo dices por el "Mi propuesta incluye db, quizà te has equivocado al citarme" es porque pensé que renegabas de usar base de datos en general, cosa que me parecía ilógica.

Lo del redis para un tres en raya será matar moscas a cañonazos el 99% de las veces, efectivamente. Para otros casos (se me ocurre por ejemplo una partida de Overwatch) sí que lo veo bastante guay.

1 respuesta

NickNack #13 May '18 :psyduck:

#12 no sé, yo me leo y con los matices entiendo perfectamente cuando digo la BBDD por medio moviendo los datos. El reply esta bien, solo que no entiendo por que dices que me equivoco al citar. No decia NO PONGAS una base de datos, si no que mover los datos de la partida mediante una base de datos es una chapuza para un juego a tiempo real.

No tengo nada mas que añadir por que ya lo has explicado tu. El que quiera saber mas cosas que parta de ahí.

X-Crim #14 May '18 Moderador Mario Kart

La base es #4

Lógica de turnos

Usuarios habituales

Tags