Come posso codificare in modo efficiente sia il client che il server allo stesso tempo?

15

Sto codificando il mio gioco usando un modello client-server. Quando si gioca su singleplayer, il gioco avvia un server locale e interagisce con esso come un server remoto (multiplayer). L'ho fatto per evitare di codificare codice giocatore singolo e multiplayer separato.

Ho appena iniziato a scrivere codice e ho riscontrato un grosso problema. Attualmente sto sviluppando il gioco in Eclipse, avendo tutte le classi di gioco organizzate in pacchetti. Quindi, nel mio codice server, utilizzo solo tutte le classi nei pacchetti client.

Il problema è che queste classi client hanno variabili specifiche per il rendering, che ovviamente non verrebbero eseguite su un server.

Devo creare versioni modificate delle classi client da utilizzare nel server? O dovrei semplicemente modificare le classi client con un valore booleano, per indicare se è il client / server che lo utilizza. Ci sono altre opzioni che ho? Ho pensato di usare forse la classe server come classe principale, per poi estenderla con il rendering?

— liamzebedee
fonte

Hai opzioni pre-processore? Come #ifdef CLIENT <alcuni codici> #endif. Questo è un modo semplice per condividere file di classe, che possono essere diversi tra server e client e condividere anche parti. È un po 'disordinato però.

— William Mariager il

Sono d'accordo con MindWorX. Sebbene la compilazione condizionale sia una seccatura in Java, ci sono soluzioni che dovrebbero essere considerate.

— Sam Hocevar,

1

La compilazione condizionale è un modo rozzo di dire "Non ho messo abbastanza tempo di progettazione nei miei pacchetti", secondo me =) "Un po 'disordinato" di solito si traduce in "Che diamine fa questo?" sei mesi dopo, quando rileggi anche il tuo codice ed è controproducente per qualsiasi cosa tranne i prototipi usa e getta.

— Patrick Hughes,

23

Dovresti preferire mantenere il tuo codice di rendering separato dalla logica del tuo gioco , poiché sono preoccupazioni separate .

Se si separa il codice di rendering dal codice client / server, si ottengono alcuni vantaggi:

La creazione di un server dedicato sarà più semplice, poiché qualsiasi codice che esegue il rendering sarà in un unico posto.
Puoi separare la tua updatefase dalla tua renderfase ed eseguirli in timestep diversi.
Puoi assicurarti che il tuo codice di rendering non muta lo stato del gioco, usando const, riducendo i bug.

— Blair Holloway
fonte

1

+1 Non posso essere più d'accordo con questo sentimento. Separare la modellazione dei dati dalle viste renderizzate di quel modello ti consentirà di fare in modo pulito cose come più finestre che mostrano informazioni diverse, trasferire il rendering su altre piattaforme, aggiungere analisi e modificare la simulazione per il gioco senza dover toccare il 90% della tua base di codice .

— Patrick Hughes,

5

Penso che dovresti separare in modo chiaro il codice client e server. Il codice del server e il codice client non devono conoscersi a vicenda tranne per la funzionalità esposta con le interfacce. Il server non dovrebbe sapere nulla sul rendering, solo sulla registrazione dei client, sul tracciamento delle posizioni, sul tempo, ecc. Se hai dubbi ben separati è più facile mantenere e sviluppare ulteriormente il tuo gioco. Spero che questo aiuti un po '.

— loodakrawa
fonte

+1 Tendo ad essere d'accordo. Se il server eseguirà dei client, dovrebbe farlo come processi separati.

— Ingegnere

5

Separazione delle preoccupazioni FTW, come hanno detto gli altri, ma se l'obiettivo finale è avere applicazioni client e server separate, è necessario fare un ulteriore passo avanti. È necessario determinare cosa è specifico del client, cosa è specifico del server e cosa è condiviso. Per tutto ciò che è condiviso, separalo in classi di codice esclusivamente condiviso; le classi specifiche del client o del server possono quindi sottoclassare o fare riferimento alle classi condivise come appropriato. Spostare le classi condivise in un progetto separato, creando un JAR "libreria condivisa" e includendo tale JAR in entrambi i progetti client e server.

Ciò presenta alcuni vantaggi: rende la separazione delle preoccupazioni cristallina per mantenere tutto in progetti separati; ti assicura che client e server stanno iniziando con lo stesso codice condiviso (purché utilizzino la stessa versione del JAR condiviso); e rende impossibile "accidentalmente" modificare il codice condiviso senza accorgersene. Se il codice condiviso si trova nel suo progetto, saprai quando stai modificando qualcosa in quel progetto che devi essere consapevole di come le modifiche avranno effetto sia sul client che sul server.

— Adrian
fonte