Comment puis-je coder efficacement le client et le serveur en même temps?

15

Je code mon jeu en utilisant un modèle client-serveur. Lorsque vous jouez en mode solo, le jeu démarre un serveur local et interagit avec lui comme un serveur distant (multijoueur). J'ai fait cela pour éviter de coder un code solo et multijoueur séparé.

Je viens de commencer à coder et j'ai rencontré un problème majeur. Actuellement, je développe le jeu dans Eclipse, ayant toutes les classes de jeu organisées en packages. Ensuite, dans mon code serveur, j'utilise simplement toutes les classes dans les packages client.

Le problème est que ces classes clientes ont des variables spécifiques au rendu, qui ne seraient évidemment pas effectuées sur un serveur.

Dois-je créer des versions modifiées des classes clientes à utiliser sur le serveur? Ou devrais-je simplement modifier les classes clientes avec un booléen, pour indiquer si c'est le client / serveur qui l'utilise. Y a-t-il d'autres options que j'ai? Je viens de penser à utiliser peut-être la classe serveur comme classe principale, puis à l'étendre avec du rendu?

java networking server client-server metaprogramming liamzebedee
la source
Avez-vous des options de pré-processeur? Comme #ifdef CLIENT <un code> #endif. C'est un moyen simple d'avoir des fichiers de classe partagés, qui peuvent être différents entre le serveur et le client et partager des parties également. C'est un peu compliqué cependant.
William Mariager
Je suis d'accord avec MindWorX. Bien que la compilation conditionnelle soit un problème en Java, il existe des solutions à considérer.
sam hocevar
1
La compilation conditionnelle est une façon grossière de dire "Je n'ai pas mis assez de temps de conception dans mes packages", à mon avis =) "Un peu désordonné" se traduit généralement par "Qu'est-ce que ça fait?" six mois plus tard, lorsque vous relisez même votre propre code et que vous êtes contre-productif pour tout sauf pour les prototypes jetables.
Patrick Hughes

Réponses:

23

Vous devriez préférer garder votre code de rendu séparé de votre logique de jeu , car ce sont des préoccupations distinctes .

Si vous séparez votre code de rendu de votre code client / serveur, vous obtenez quelques avantages:

  • La création d'un serveur dédié sera plus facile, car tout code rendu sera au même endroit.
  • Vous pouvez séparer votre updatephase de votre renderphase et les exécuter à des pas de temps différents.
  • Vous pouvez vous assurer que votre code de rendu ne mute pas l'état du jeu, en utilisant const, en réduisant les bogues.
Blair Holloway
la source
1
+1 Je ne peux plus être d'accord avec ce sentiment. Séparer la modélisation des données des vues rendues de ce modèle vous permettra de faire proprement des choses soignées comme plusieurs fenêtres qui affichent des informations différentes, de porter le rendu sur d'autres plates-formes, d'ajouter une analyse et de peaufiner votre simulation pour le gameplay sans avoir à toucher 90% de votre base de code .
Patrick Hughes
5

Je pense que vous devriez séparer proprement le code client et le code serveur. Le code serveur et le code client ne doivent pas se connaître, sauf pour les fonctionnalités exposées avec les interfaces. Le serveur n'est pas censé savoir quoi que ce soit sur le rendu, il suffit d'enregistrer les clients, de suivre les positions, le temps, etc. Si vous avez des préoccupations clairement séparées, il est plus facile de maintenir et de développer davantage votre jeu. J'espère que ça aide un peu.

loodakrawa
la source
+1 J'ai tendance à être d'accord avec cela. Si le serveur doit exécuter des clients, il doit le faire en tant que processus distincts.
Ingénieur
5

Séparation des préoccupations FTW, comme les autres l'ont dit, mais si votre objectif final est d'avoir des applications client et serveur distinctes, vous devez aller plus loin. Vous devez déterminer ce qui est spécifique au client, ce qui est spécifique au serveur et ce qui est partagé. Pour tout ce qui est partagé, séparez-le en classes de code exclusivement partagé; les classes spécifiques au client ou au serveur peuvent ensuite sous-classer ou référencer les classes partagées selon le cas. Déplacez les classes partagées dans un projet distinct, en créant un JAR de "bibliothèque partagée" et incluez ce JAR dans les projets client et serveur.

Cela présente quelques avantages: il rend la séparation des préoccupations limpide de tout garder dans des projets séparés; il vous assure que le client et le serveur démarrent avec le même code partagé (tant qu'ils utilisent la même version du JAR partagé); et il rend impossible de modifier "accidentellement" le code partagé sans s'en rendre compte. Si le code partagé se trouve dans son propre projet, vous saurez, lorsque vous modifierez quoi que ce soit dans ce projet, que vous devez savoir comment les modifications affecteront à la fois le client et le serveur.

Adrian
la source