¿Cómo permite que se escriba el código de red en las etapas posteriores del desarrollo?

Actualmente estoy en el progreso inicial de escribir un juego que eventualmente querré mejorar en la mayoría de los aspectos.
¿Cómo puedo omitir la escritura de código de red y dejarlo implementado con bastante facilidad, es decir, no tener que reescribir todo el juego solo para agregarlo?
¿Qué debo tener en cuenta?

Tengo un patrón de componentes donde separo la física / detección de colisión, la lógica del juego, los tipos de datos y la animación / representación entre sí.
¿Cómo escribo un cliente y un servidor que no tienen ningún código de red implementado pero que pueden probarse localmente?
¿Qué debo hacer en el cliente y qué debo hacer en el servidor? ¿Debo fingir que tengo el código de red terminado y enviar mensajes entre el servidor y el cliente y dar cuenta de los retrasos, etc. aunque no haya ninguno?

Editar: está planeado ser un juego de rol de arriba hacia abajo. El modo multijugador simple donde alojas un servidor para tus amigos es lo que estoy pensando, por lo que hacer trampa no es un gran problema (¿a quién le gustaría jugar con amigos tramposos?). Aún así, me gustaría ir con un enfoque "El servidor siempre tiene la razón".

Edición 2: supongo que estoy buscando algunos indicadores sobre cómo debería ser mi mentalidad. ¿Cómo debo manejar la entrada del teclado, la animación, etc., en lugar de simplemente aplicar cada efecto / cambio al instante? Hmmm, es posible que necesite leer correctamente en la red antes de ir a cualquier parte, después de todo, que era lo que esperaba escapar haciendo un esqueleto de red de algún tipo que pudiera funcionar localmente.

Sin saber más sobre el juego exacto que estás escribiendo y cómo lo estás escribiendo, es muy difícil decir soluciones genéricas a tu problema.

Sin embargo, es posible que desee considerar esta decisión que está tomando de dejar el código de red hasta el final, dependiendo de cuán crucial sea la red para su juego.

Lo que quiero decir es que, si estás escribiendo un juego pesado de red, como un MMORPG, puede que no sea aconsejable dejar la red hasta el final.

Dicho esto, si el impacto que espera para el código de red es bajo (como en el caso de que no tener código de red no sea un factor decisivo), entonces podría ser apropiado dejarlo para una etapa posterior (pero no demasiado tarde).

Recuerde que escribir código de red no es lo mismo que pensar en ello. A medida que toma decisiones sobre cómo se hace su juego, debe considerar cómo esto afectaría las decisiones de la red, y si el impacto esperado es alto, tal vez impleméntelo como un trozo que brinde información genérica, y luego cuando sea el momento de escribir la red código, solo es cuestión de enchufarlo donde dejaste el trozo.

Entonces, por ejemplo, si está haciendo un juego de ajedrez en línea, puede tener una función llamada ExecuteMove()que se llama de alguna manera cuando un movimiento se ingresa con el mouse, y de otra manera cuando un movimiento se ingresa con el teclado. En este punto, es posible que desee pensar en crear un código auxiliar de red que, después de obtener los datos requeridos del otro host (esto es lo que escriba en una parte posterior), llame ExecuteMove().

De esa manera, a medida que creas tu juego, sabrás qué partes están afectadas por el código de red, y cuando sea el momento de escribir el código de red, estarás varios pasos por delante.

Si es la primera vez que escribes un juego en red, considera no pensar demasiado en la lucha contra las trampas y cosas así. Hacer un juego en red es lo suficientemente complejo como para requerir que todo un equipo de personas altamente experimentadas lo haga para un juego AAA, así que tómatelo con calma y primero crea un juego que funcione, antes de enfocarte en temas más complejos.

Finalmente, si es la primera vez que haces un juego, no lo hagas en red, por favor. Hacer un juego es tan complejo que cada requisito que agregue a su juego lo hará exponencialmente más complejo.

Estoy en una situación similar, pero estoy tratando de hacer una simulación en red más que un juego; pero creo que mi enfoque puede ayudarlo en su proceso de diseño.

Mi enfoque está en la línea de su comentario sobre IPC (comunicación entre procesos).

Primero, como antecedentes, estoy estudiando el libro "Gráficos en red" de Steed y Oliveira. Esto proporciona una buena base en varias arquitecturas de red para juegos, dependiendo de varios criterios y tipos de juegos. Proporciona una herramienta para ayudarlo a decidir la arquitectura de su juego y qué es exactamente lo que quiere poner en la red, y qué quiere que ocurra localmente.

En segundo lugar, separe los componentes de la red en un subproceso de fondo separado para que su desarrollo inicial del juego pueda codificar el componente localmente, pero se ve obligado a lidiar con la separación del subproceso. No los combine con ninguna otra característica que luego será "fondo local", sino que los fuerce a subprocesos de fondo "potencialmente remotos".

Esto debería ayudar a mantener su lógica separada y también permitirle simular factores de retraso de la red en el proceso para que también pueda ver el impacto de la latencia.

Si estás aprendiendo sobre todo esto, ¿por qué no escribes una versión 1 para un jugador simple, y una vez que esté funcionando, con tu conocimiento más profundo, reconsidera todo en profundidad para la versión 2 que será multijugador?

Implemente una clase de "red falsa" que pase mensajes entre hilos, que tiene la misma interfaz que tendrá la clase de red. Más tarde, puede elaborar la red falsa para tener demoras aleatorias y pérdida de paquetes. Siempre será más fácil depurar el código de red con la clase falsa que con la red real.