¿como funcionan?

[big_boss]

bueno, yo soy el novato mas novato d este mundo y espero no molestar...

el caso es k stoy estudiando C++ tras haber trasteado cn blitz3D, no se si lo conoceis... y m ha entrado la curiosidad d como funciona un multijugador masivo. ¿que hace falta xa programarlo? ¿q hace falta xa mantenerlo? ¿que es lo que el programa del servidor hace y lo k hace el programa del cliente?
y bueno, si es muy lioso pues al menos m gustaria saber a kien preguntar o donde leer acerca del tema.

es sincera curiosidad y se q el tema es muy  jodido xo no s x vacilar ni nada d eso...

weno gracias x la atencion!

[Tei]

y m ha entrado la curiosidad d como funciona un multijugador masivo. ¿que hace falta xa programarlo? ¿q hace falta xa mantenerlo? ¿que es lo que el programa del servidor hace y lo k hace el programa del cliente?

Esto que te escribo es como lo constuiria yo. No tiene porque ser igual en la realidad.

Intentaria dividir la carga de trabajo al maximo, y minimizar los datos en circulacion.

- 1 maquina de servidor de chat
- 1 maquina para login (y puede que ademas para cobro)
- NxN maquinas, con una por cada area del mapa. Esta es la granja.
- Un sistema de hardware especialidad y con redes de altacapacidad que conecta los nodos de la granja con la base de datos, una base de datos o sistema de datos optimizado para velocidad.

Cuando tu te logueas el proceso es el siguiente:

- Tu cliente llama al server de login
- El server de login te hace el trabajo del login, contra su base de datos, o su tabla dentro de la base de datos principal. Posiblemente el server de login este al tanto de temas de facturacion que esas yo  no las pondria junto a los datos de juego (tipo monedas de oro que tienes). Pero cada uno es cada uno.
- El server de login te redirige a una de las maquinas de la granja.
- Al moverte por el mapa, se produce una traslacion de tu ficha al correspondiente nodo de la granja de forma mas o menos automatica.

Minimo trafico.... Hasta el 99% de lo que ves animado en el mundo (animaciones de modelos, particulas obviamente, etc, etc etc..) es simulado por el cliente. El servidor envia la minima informacion prescindible. El cliente debe figurarse lo demas.
En el espacio de tiempo que transcurre entre los frames que envia el servidor, tu cliente renderiza el mundo fluidamente, sin pausas, mediante interpolacion de movimiento, prediccion y cosas asi.

La informacion se envia enpaquetada en estructuras estilo las de C, incluso con las tipicas "union" de C. Algo muy parecido a lo que puedes encontrar en los formatos de los ficheros. No se desperdicia ni un nible.
Aunque en cosas que no requieren tiempo real, como login, se pueden intercambiar mensajitos en XML "de toda la vida".

Creo que puedes encontrar un articulo sobre todo esto publicado por la gente de Second Life.

Un mmorpg puede ser una enorme infraestructura informatica basada en cientos de servidores (reales o virtuales) cooperando.

Lo de servidores virtuales/reales es todo un punto. Por ejemplo. Vanguard : Saga of Heroes estaba programado en base a hilos. Entonces al hilo le daba igual correr en una maquina sola o junto a otros 8000, y tal como estaba creado, podian iniciarse los hilos dinamicamente en unos sitios u otros, creo que incluso moverlos de server (aunque no te fies mucho de esto).  Hay un video muy divertido de Mr T sobre la virtualizacion de servidores.
http://www.youtube.com/watch?v=tW1S2tsxVHg

update: editado el texto para hacerlo mas comprensible

[1cacalvo]

Os tienen miedo!!!! Mira como ha preguntado con todo el respeto del mundo y ha excusado poner la palabra mmporg :D

[senior wapo]

Necesitas como mínimo:
1. Un servidor (varias máquinas),  que ejecute la simulación del mundo y coordine la sincronización entre clientes. Vamos, que si un jugador se mueve o hace algo, eso deben saberlo los demás clientes también.
2. Otro que gestione la base de datos de usuarios y estado del mundo.
3. Una buena conexión a Internet en los servidores, especialmente en caudal de salida (lo contrario a lo que tenemos en las casas).
4. Un programa cliente que se conecte a los servidores y le muestre al jugador el estado de la simulación y haga de puente entre el jugador y el mundo virtual.

La forma más simple es un juego por turnos en el que el cliente sea un navegador web y el servidor sea una aplicación PHP/ASP contra una base de datos que te ponga el proveedor, digamos mysql. Hay varios de estos mencionados por el foro.

Si lo que buscas es algo en tiempo real, en 3D y con grandes mundos, tipo World of Warcraft, pues necesitas saber mucho de todo, redes, gráficos, estructuras de datos, comunicación remota entre procesos, bases de datos y mil cosas más.
Te programas tu un servidor dedicado (en principio), un cliente en 3D, las herramientas de apoyo y mil cosas más. También se pueden comprar componentes sueltos que hagan algunas de las funciones necesarias (por ejemplo toda la arquitectura que corre en el servidor)  y valen una pasta.

Sobre como funcionan:
- La regla es que el servidor ordena y el cliente obedece y pide; que el servidor dispone y se hará lo que a el le venga en gana.
El cliente normalmente se limita a pintar y mantener una copia de los datos minimos  del mundo necesarios para poder pintar con coherencia.
Cuando el jugador hace algo, como moverse  o tirar de un bolso, informa al servidor de que "quiere" hacerlo; el servidor calcula si es posible hacerlo según las reglas y la situación actual y le devuelve los cambios que han ocurrido en la simulación para que el cliente actualice la pantalla.
O bien le dice que no, y el cliente se aguanta y aquí no ha pasado nada.

Por su parte el servidor está todo el rato ejecutando un  bucle en el que va avanzando la simulación del mundo y modificándola según la información y peticiones que le llega desde los clientes. Además se encarga de propagar todos los cambios entre los clientes susceptibles de notarlos en su situación actual.

Los detalles de como hacer todo esto  bien dan para años de estudio y no los realiza una sola persona.

[Tei]

Si jugabas con lag en el anarchy online, de pronto veias que un compañero tuyo que creias tenias justo delante estaba muchos metros adelantado.

Esto es porque en el lado client ese simula tambien cosas como la posicion de los jugadores, y en eso se tienen en cuenta cosas como la velocidad de los jugadores, su direccion y colisiones. Asi que no es un modelo cliente servidor puro, porque modelo cliente servidor puro no se puede hacer en internet, solo en lan, porque el lag es de 200ms, y eso hay que multiplicarlo por dos porque va y vuelve: 400ms. Si hubiera 400 ms entre que dejas de ir a la izquierda, y vas hacia la derecha, lo notarias, porque es casi medio segundo. Si no estas acostumbrado a moverte asi, te costara.

Esto lo puedes experimentar por ti mismo. Levanta un servidor de Quake1 normal, y conectate con lag (quizas pon a la vez la mula a todo ritmo). Quake1 no tiene prediccion de movimiento, es cliente/servidor puro. En cambio si haces lo mismo con Quake2, Half-Life, Quakeworld o Batlefield 1942, veras que no se produce este efecto. Porque estos juegos tienen prediccion.  Los MMORPG potencialmente deberian tener mas lag, dado que no es tan importante (nada en realidad) la posicion de las cosas mas halla de cosas muy simples como si dos entes se ven o no.

Los MMORPG tienen un componente "singleplayer" muy fuerte. Estan los mobs, y para los mobs normalmente se programa algun tipo de patron de movimiento, como seguir patrones de waypoints. Y si cogen el agro, encontrar su camino entre ellos y el jugador. En los mmorpg para que la gente no abuse, es normal que si el mob no puede alcanzar al jugador (no encuentra un camino), que se teleporte junto a el. Para evitar que se utilice este tema como xploit para matar inpunemente infinitos mobs de mele simplemente atacandolos desde una posicion mas alta (como en pasaba en un episocio de thenoobcomic ;D )

El cliente de un mmorpg 3D se puede programar de forma muy parecida a un FPS. Si acaso los FPS suelen tener mapas pequeños optimizados. Mientras que los MMORPG requieren algun sistema decente de streaming, para que el juego no se pare nunca. Aunque muchos MMORPG cortan por lo sano, y por ejemplo entre mapas hay una ventana de carga.

Un buen MMORPG requiere de un sistema para personalizar los personajes de modo que cada persona tenga un personaje distinto. Esto puede llegar a ser complicado, y suele exigir temas como tener modelos multimodelos, huesos, buenos algoritmos para modificar algunas propiedaes... es casi una Ciencia por si misma (con C mayuscula).

Etc etc etc etc.. El tema es gigantesco, y haria falta una biblioteca de libros para tratar la mayor parte de los temas :D

[jazcks]

los paquetes que envia el cliente al servidor, indicando  entre otras cosas, su posicion en el mundo, pueden ser escuchados para luego reproducirlos aparte para hacer trucos, teletransporte etc... eso tengo entendido, que un cliente puede ser "emulado".

como lo hacen los "grandes" mmorpgs para evitar esas cosas?

[gdl]

como lo hacen los "grandes" mmorpgs para evitar esas cosas?

Por lo que sé, el Lineage II encripta los paquetes mediante RSA, Blowfish y un método propio. Luego, el servidor detecta paquetes "raros". Finalmente todo queda en un log donde se comprueba que todo el mundo es legal.

Desde mi punto de vista, la encriptación es una tontería porque tarde o temprano se desencripta. Lo que sí que funciona es tener unas reglas sólidas en el server que detecten los paquetes "raros" y actuen en consecuencia.

[Khayn]

si usas blitz3d hay un par de motores mmo basicos, mira en los foros y los encontraras, tanto los servidores como los clientes, e incluso motorcillos de chat pero con pjs movibles por mapas.

no estan optimizaos ni nada pero para aprender te vendran bien y ya que tienes el blitz,,,, pues el codigo es abierto, el ultimo creo que se llama voidonline o algo asi

en el mio y eso que es una mierdecilla uso 3 servidores:
no es lo mismo 1 programa verificando todo por muy deprisa que vaya que 3 cada uno por su lao... y si uno tiene un problema o relentiza no afecta casi al resto.....