Arquitectura Java del lado del servidor MMORPG


8

Actualmente estoy haciendo un juego MMORPG, que está basado en turnos. Se supone que el cliente se ejecuta en Android. Ahora, mi amigo está haciendo los gráficos, y yo he estado haciendo las clases de juego (jugador, armamento, etc.). Ahora, si se inicia la pelea, las clases pueden ser manipuladas por interfaces (en realidad para mi compañero, es como trabajar con interfaces puras, él no necesita ningún acceso a las clases de implementación).

Ahora necesitamos introducir un servidor de juego para permitir múltiples jugadores. Y surgen algunas preguntas muy importantes:

1) ¿Debo copiar el modelo del juego en el servidor por completo, sin dejar clases en el cliente o es mejor tener 2 copias del modelo: 1 en el servidor y 1 en el dispositivo y completar la sincronización periódica entre ellos?

2) ¿Qué método de conexión elegir entre el cliente y el servidor (el cliente a la vista es un teléfono Android)? En cuanto al servidor, me estoy volviendo hacia Java porque tengo algo de experiencia con él. Pero ahora la pregunta es: ¿es mejor usar sockets para esta tarea o puedo usar los servicios REST, o incluso es posible conectarlo de alguna manera al servidor Java EE, que es genial desde mi punto de vista porque elimina mucha programación? ¿complicación? Aunque el juego es multijugador, se basa en turnos, por lo que no es necesario renovarlo con mucha frecuencia.

3) ¿Qué pasa con el enhebrado? ¿Debería cada cliente tener su propio hilo (en caso de enchufes)?

4) ¿Hay algún libro sobre programación de juegos de servidor REAL MMORPG?

Respuestas:


7

No copie el modelo de juego completo en el servidor, no le gustaría cargar todas las texturas y mallas detalladas en su servidor. Manténgalo lo más simple posible, maneje todos los procesos importantes como la ubicación, la salud, cualquier movimiento, pero no cargue todo. - NUNCA CONFÍES EN EL CLIENTE.

Hay muchos libros, junto con múltiples wiki. Cada proveedor de motores como IdeaFrabrik, Epic Games, Exitgames, Unity (también es compatible con mmo's) tiene muy buena documentación para sus productos. La mayoría de esas cosas son públicas, por lo que tienes acceso a soluciones completas y puedes descubrir cómo funcionan las cosas.

La forma más fácil de encontrar un libro que necesita es buscar MMORPG en Amazon, luego ir a la categoría de libro y elegir la subcategoría "programación". Si lo buscas en Google obtendrás resultados no deseados ...

Aquí está la lista de libros que encontré

No he profundizado en la programación del servidor, pero de hecho, estuve cerca de elegir la solución del motor Unity + Photon Cloud para mi proyecto MMORPG. (HeroEngine ganó) El lado del servidor se hace en este en C # y una cosa que recuerdo es la forma en que se explicaron las cosas en los tutoriales.


No estamos usando ningún motor porque el juego no requiere uno. Carece de gráficos geniales. Por lo tanto, no necesitamos Unity con sus características supremas para 3D. Los libros que proporcionó parecen ser demasiado amplios, aún no hay referencia al libro que explica cómo escribir un servidor de carga múltiple para varios jugadores. Pero gracias por el consejo.
Artem Moskalev

Debe aprender sobre la programación de servidor-cliente TCP. "Diciéndolo de manera brutal, la programación del servidor también se usa en los juegos". Tienes que aprender su base. Esto podría ayudarlo a comenzar en Java. edn.embarcadero.com/article/31995
Mikolaj Marcisz

Sí, sé que ya =) he programado suficientes de ellos junto con JMS y servidores de mensajes de cadena simples =) Es por eso que pregunté cuál es mejor + los sockets tienen un nivel bastante bajo en comparación con Java EE con el que trabajé anteriormente) Simplemente no sé cómo se hace con los juegos multijugador porque hasta ahora parece que programar el servidor del juego es totalmente diferente de programar sitios web o programas simples de intercambio de mensajes)
Artem Moskalev

4

1) ¿Debo copiar el modelo del juego en el servidor por completo, sin dejar clases en el cliente o es mejor tener 2 copias del modelo: 1 en el servidor y 1 en el dispositivo y completar la sincronización periódica entre ellos?

De acuerdo con Mikolaj no copiar todo. Envíe la menor cantidad de datos posible. Puede tener las mismas clases (que representan solo el modelo de datos, no otros activos) en el cliente y el servidor, pero no los envíe a través de la red. Desea serializarlos en el servidor y deserializar en el cliente. El cliente debe enviar solo comandos al servidor.

2) ¿Qué método de conexión elegir entre el cliente y el servidor (el cliente a la vista es un teléfono Android)? En cuanto al servidor, me estoy volviendo hacia Java porque tengo algo de experiencia con él. Pero ahora la pregunta es: ¿es mejor usar sockets para esta tarea o puedo usar los servicios REST, o incluso es posible conectarlo de alguna manera al servidor Java EE, que es genial desde mi punto de vista porque elimina mucha programación? ¿complicación? Aunque el juego es multijugador, se basa en turnos, por lo que no es necesario renovarlo con mucha frecuencia.

Está planeando un MMORPG por turnos (aunque no tengo idea de cómo funcionaría). Entonces la velocidad no es un gran problema. Puede usar cualquier tipo de servicio, REST puede ser bueno, es simple. Por lo general, los MMORPG usan UDP (no seguro, más pequeño, más rápido) para cosas como actualizaciones de movimiento donde un paquete perdido o dos no importan y TCP (seguro, sobrecarga) para una comunicación segura. La mayoría de los juegos probablemente usan algún tipo de protocolo personalizado encriptado y comprimido sobre UDP y TCP para que sea rápido y difícil de descifrar.

3) ¿Qué pasa con el enhebrado? ¿Debería cada cliente tener su propio hilo (en caso de enchufes)?

Por lo general, desea tener un grupo de subprocesos. Cada subproceso del grupo atiende una solicitud y luego se recicla. Cuando no tiene suficientes hilos, puede considerar bloquear o asignar más hilos.

4) ¿Hay algún libro sobre programación de juegos de servidor REAL MMORPG?

Mikolaj ya buscó en Google eso para ti ...


¿Podría elaborar más sobre el grupo de hilos? Si hay sockets, entonces el servidor está escuchando las solicitudes y asigna un nuevo socket para cada uno. Los sockets con toda la información entrante se pueden encapsular como un trabajo para el subproceso. Pero, ¿cómo se recuperan los subprocesos del grupo de subprocesos si cada vez que esos subprocesos tienen trabajos diferentes? + ¿Cuántos sockets abiertos puede contener un servidor promedio? ¿Será más intensivo en recursos que REST o no? + en REST no hay estado de sesión, por lo que es difícil mantener la información del jugador. Pero descansar en Java tiene una integración perfecta en el servidor empresarial, lo que es bueno
Artem Moskalev

Los libros introducidos tienen que ver con el diseño OOP de MMORPG como parece de los comentarios. Por eso prefiero seguir con GoF. Nuevamente, parece que la programación de juegos en línea para jugadores múltiples en el lado del servidor es algún tipo de conocimiento sagrado transmitido a través de la generación =) Todos los foros / publicaciones / libros surgen con esas ideas: "no intentes programar MMO / Programar MMO es realmente difícil / MMO no es para un novato "... y ningún consejo en absoluto ...
Artem Moskalev


Los libros introducidos tienen que ver con el diseño OOP de MMORPG como parece de los comentarios. Por eso prefiero seguir con GoF. Esta oración no tiene sentido. También construir un MMORPG es equivalente a construir un avión a reacción. Yo diría que ganes tus alas con aviones de papel.
MartinTeeVarga

Tienes razón al 100% sobre aviones de papel =) Pero esos libros ni siquiera son sobre aviones de papel (por aviones de papel me refiero a la programación mmo del lado del servidor). Ya lo aprendí de los comentarios en Amazon =) Algunos de esos libros tratan patrones de diseño para juegos MMORPG, que se pueden aprender de otros libros mejores, en el mismo contexto de creación de juegos. + Ya estoy construyendo un B-2, así que agradezco cualquier consejo que pueda obtener. Gracias =)
Artem Moskalev
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.