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?
fuente
Respuestas:
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:
updatefase de surenderfase y ejecutarlas en diferentes pasos de tiempo.const, reduciendo errores.fuente
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.
fuente
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.
fuente