Riferimenti per server di giochi da tavolo a turni? [chiuso]


12

Ci sono buoni riferimenti / libri da consigliare su come costruire un server di gioco a turni? È qualcosa come un server di scacchi per accoppiare i giocatori di scacchi e mantenere gli stati di gioco. In passato, ad esempio, IGS (per go, weiqi) è un'implementazione basata su socket. Quali sono le tecnologie contemporanee disponibili da cui imparare? Grazie!


c'è un filo correlato su gdev forum gamedev.net/topic/565319-turn-based-game-design-help
zincatura

Puoi imparare dal seguente design del server di gioco: developers.google.com/games/services/android/…
tomash

Risposte:


5

Non penso che ci sia un libro particolare su questo, dal momento che l'argomento è piuttosto banale.

Immagina un server di posta in cui i giocatori possono inviare le loro azioni via mail. Il server ha tutte le azioni eseguite finora (come mail), il che significa che hai lo stato del gioco. Se vuoi ricaricare il gamestate, esegui cronologicamente tutte le azioni all'interno delle mail. L'unica cosa che devi fare è assicurarti di chi è il turno ... ma anche questo è facile (es. Numeri di turno). Non sono necessarie tecnologie contemporanee ... una soluzione client / server di posta modificata funzionerà.

L'associazione di ppl può essere fatta tramite Elo ... ma credo che tu lo sapessi


forse puoi spiegarmi un po 'di più, uovo. Non conosco 'elo'
tintinnio il

Ho modificato il post per includere un link al sistema Elo.
Kylotan,

2

Se fossi in me, lo costruirei da zero con le prese. La quantità di dati da inviare è molto piccola e la natura a turni rende impercettibile una certa latenza.

La vera domanda, a mio avviso, è quali funzioni aggiuntive sono necessarie su di esso. Le sessioni di gioco sono persistenti (qualcuno può abbandonare e ricongiungersi, il gioco può essere salvato, ecc.)? Se stai eseguendo un salvataggio in stile Civilization, probabilmente desideri inviare i dati di salvataggio a tutti i client o avere il lato client di salvataggio fatto con una chiave fornita dal server incorporata per la verifica.

Hai bisogno di segnalazioni tra i turni, ad esempio "Il giocatore 2 sta muovendo un'unità" o "Il tuo avversario potrebbe essere AFK"? In tal caso, potresti voler mantenere aperte le connessioni socket.

In generale, a meno che non ci siano motivi validi per deviare, manterrei il server il più stupido e semplice possibile. Lascia meno al debug. Mi piace anche usare protocolli di testo semplice, dato che posso testare i miei server usando telnet senza un vero client di gioco (che potrebbe essere sospetto in un dato problema), ma questo incoraggia Wireshark a manipolare i dati (cosa che probabilmente farai controlla comunque).

Modifica: se il gioco supporta solo i giochi 1 contro 1, vale la pena dare un'occhiata alle connessioni peer-to-peer.


1

È importante non pensare eccessivamente a cosa sia un server e quali siano le sue responsabilità. In questo caso, hai un gioco ad azione relativamente lenta, quindi l'architettura del server non sarà incredibilmente complicata (rispetto a un gioco più veloce in cui hai una resa dei conti morta, ecc.). Il tuo server dovrebbe essere in ascolto su una porta TCP (potrebbe anche saltare UDP se non richiedi comunque la velocità) affinché i client connessi possano inviargli pacchetti di informazioni. Accetta i pacchetti, li convalida in base alle regole del gioco e invia una risposta. Nel tuo caso specifico, il tuo server dovrebbe sapere chi è il turno attualmente e rifiutare qualsiasi tentativo da parte di altri giocatori di eseguire azioni fino al loro turno.

Non so quale tecnologia avevi in ​​mente, ma qualcosa sarebbe abbastanza facile da fare in Java con la libreria Kyronet. Invia semplicemente le tue azioni di gioco al server centrale (potrebbe anche essere uno dei due giocatori), elaboralo e rispedisci un aggiornamento di gioco ad entrambi i giocatori. Sono sicuro che esiste qualcosa di simile per .NET.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.