Como codifico eficientemente o cliente e o servidor ao mesmo tempo?

15

Estou codificando meu jogo usando um modelo cliente-servidor. Ao jogar no modo singleplayer, o jogo inicia um servidor local e interage com ele como um servidor remoto (multiplayer). Fiz isso para evitar a codificação de códigos singleplayer e multiplayer separados.

Acabei de começar a codificar e encontrei um grande problema. Atualmente, estou desenvolvendo o jogo no Eclipse, tendo todas as classes de jogos organizadas em pacotes. Então, no código do meu servidor, apenas uso todas as classes nos pacotes do cliente.

O problema é que essas classes de clientes têm variáveis específicas para renderização, que obviamente não seriam executadas em um servidor.

Devo criar versões modificadas das classes de clientes para usar no servidor? Ou devo apenas modificar as classes do cliente com um booleano, para indicar se é o cliente / servidor que está usando? Existem outras opções que eu tenho? Eu apenas pensei em talvez usar a classe server como classe principal e depois estendê-la com renderização?

— liamzebedee
fonte

Você tem opções de pré-processador? Como #ifdef CLIENT <algum código> #endif. Essa é uma maneira simples de compartilhar arquivos de classe, que podem ser diferentes entre o servidor e o cliente e compartilhar partes também. É um pouco bagunçado.

— William Mariager

Eu concordo com o MindWorX. Embora a compilação condicional seja um problema em Java, existem soluções que devem ser consideradas.

— 7119 Sam

11

A compilação condicional é uma maneira grosseira de dizer "Não dediquei tempo de design suficiente aos meus pacotes", na minha opinião =) "Um pouco confuso" geralmente se traduz em "O que diabos isso faz?" seis meses depois, quando você relê até mesmo seu próprio código e é contraproducente para qualquer coisa, exceto protótipos descartáveis.

— Patrick Hughes

23

Você deve preferir manter o código de renderização separado da lógica do jogo , pois são preocupações separadas .

Se você separar o código de renderização do código do cliente / servidor, terá algumas vantagens:

Criar um servidor dedicado será mais fácil, pois qualquer código renderizado estará em um só lugar.
Você pode separar sua updatefase da sua renderfase e executá-las em diferentes intervalos de tempo.
Você pode garantir que seu código de renderização não mude o estado do jogo, usando a constredução de bugs.

— Blair Holloway
fonte

11

+1 Não posso concordar mais com esse sentimento. A separação da modelagem de dados das visualizações renderizadas desse modelo permitirá que você faça coisas limpas, como várias janelas que mostram informações diferentes, mova a renderização para outras plataformas, adicione análises e aprimore sua simulação para jogabilidade, sem precisar tocar em 90% da sua base de código .

— Patrick Hughes

5

Eu acho que você deve separar corretamente o código do cliente e do servidor. O código do servidor e o código do cliente não devem saber um do outro, exceto pela funcionalidade exposta com interfaces. O servidor não deve saber nada sobre renderização, apenas registrando clientes, rastreando posições, horário etc. Se você tiver preocupações bem separadas, é mais fácil manter e desenvolver seu jogo. Espero que isso ajude um pouco.

— loodakrawa
fonte

+1 Eu tendem a concordar com isso. Se o servidor estiver executando clientes, deverá fazê-lo como processos separados.

— Engenheiro de

5

Separação de preocupações O FTW, como os outros disseram, mas se seu objetivo final é ter aplicativos de cliente e servidor separados, você precisa dar um passo adiante. Você precisa determinar o que é específico do cliente, o que é específico do servidor e o que é compartilhado. Para tudo o que é compartilhado, separe-o em classes de código compartilhado exclusivamente; as classes específicas do cliente ou do servidor podem subclassificar ou referenciar as classes compartilhadas conforme apropriado. Mova as classes compartilhadas para um projeto separado, construindo um JAR de "biblioteca compartilhada" e inclua esse JAR nos projetos do cliente e do servidor.

Isso tem algumas vantagens: torna clara a separação de preocupações para manter tudo em projetos separados; garante que o cliente e o servidor estejam começando com o mesmo código compartilhado (desde que estejam usando a mesma versão do JAR compartilhado); e torna impossível "acidentalmente" modificar o código compartilhado sem perceber. Se o código compartilhado estiver em seu próprio projeto, você saberá quando estiver editando algo nesse projeto que precisa estar ciente de como as alterações afetarão o cliente e o servidor.

— Adrian
fonte