¿Cómo codifico eficientemente tanto el cliente como el servidor al mismo tiempo?


15

Estoy codificando mi juego usando un modelo cliente-servidor. Cuando se juega en un solo jugador, el juego inicia un servidor local e interactúa con él como un servidor remoto (multijugador). He hecho esto para evitar codificar código separado para un jugador y multijugador.

Acabo de comenzar a codificar y he encontrado un problema importante. Actualmente estoy desarrollando el juego en Eclipse, teniendo todas las clases de juego organizadas en paquetes. Luego, en el código de mi servidor, solo uso todas las clases en los paquetes del cliente.

El problema es que estas clases de cliente tienen variables que son específicas de la representación, que obviamente no se realizarían en un servidor.

¿Debo crear versiones modificadas de las clases de cliente para usar en el servidor? O debería simplemente modificar las clases del cliente con un booleano, para indicar si es el cliente / servidor que lo usa. ¿Hay alguna otra opción que tenga? ¿Acabo de pensar en usar la clase de servidor como clase principal y luego extenderla con material de renderizado?


¿Tiene opciones de preprocesador? Como #ifdef CLIENTE <algún código> #endif. Esa es una manera simple de compartir archivos de clase, que pueden ser diferentes entre el servidor y el cliente y también compartir partes. Sin embargo, es un poco desordenado.
William Mariager

Estoy de acuerdo con MindWorX. Aunque la compilación condicional es una molestia en Java, hay soluciones que deben considerarse.
sam hocevar

1
La compilación condicional es una forma cruda de decir "No puse suficiente tiempo de diseño en mis paquetes", en mi opinión =) "Un poco desordenado" generalmente se traduce en "¿Qué diablos hace esto?" seis meses después, cuando vuelve a leer incluso su propio código y es contraproducente para cualquier cosa que no sean prototipos descartables.
Patrick Hughes

Respuestas:


23

Debes preferir mantener tu código de renderizado separado de la lógica de tu juego , ya que son preocupaciones separadas .

Si separa su código de representación del código de su cliente / servidor, obtendrá un par de ventajas:

  • Crear un servidor dedicado será más fácil, ya que cualquier código que se represente estará en un solo lugar.
  • Puede separar su updatefase de su renderfase y ejecutarlas en diferentes pasos de tiempo.
  • Puede asegurarse de que su código de representación no mute el estado del juego, al usarlo const, reduciendo errores.

1
+1 No puedo estar más de acuerdo con este sentimiento. Separar el modelado de datos de las vistas renderizadas de ese modelo le permitirá hacer cosas limpias como múltiples ventanas que muestran información diferente, portar el renderizado a otras plataformas, agregar análisis y ajustar su simulación para el juego sin tener que tocar el 90% de su código base .
Patrick Hughes

5

Creo que debería separar limpiamente el código del cliente y el servidor. El código del servidor y el código del cliente no deben conocerse entre sí, excepto por la funcionalidad expuesta con las interfaces. Se supone que el servidor no debe saber nada sobre renderizar, solo registrar clientes, rastrear posiciones, tiempo, etc. Si tiene preocupaciones separadas, es más fácil mantener y desarrollar su juego. Espero que esto ayude un poco.


+1 Tiendo a estar de acuerdo con esto. Si el servidor va a ejecutar algún cliente, debe hacerlo como procesos separados.
Ingeniero

5

Separación de preocupaciones FTW, como han dicho los demás, pero si su objetivo final es tener aplicaciones separadas de cliente y servidor, debe ir un paso más allá. Debe determinar qué es específico del cliente, qué es específico del servidor y qué se comparte. Para todo lo que se comparte, sepárelo en clases de código compartido exclusivamente; Las clases específicas de cliente o servidor pueden subclasificar o hacer referencia a las clases compartidas según corresponda. Mueva las clases compartidas a un proyecto separado, construyendo un JAR de "biblioteca compartida" e incluya ese JAR en los proyectos de cliente y servidor.

Esto tiene algunas ventajas: hace que la separación de las preocupaciones sea clara para mantener todo en proyectos separados; le asegura que el cliente y el servidor comienzan con el mismo código compartido (siempre que usen la misma versión del JAR compartido); y hace que sea imposible "accidentalmente" modificar el código compartido sin darse cuenta. Si el código compartido está en su propio proyecto, sabrá cuando esté editando algo en ese proyecto que necesita saber cómo afectarán los cambios tanto al cliente como al servidor.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.