Use advanced navigation for a better experience.
You can quickly scroll through posts by pressing the above keyboard keys. Now press the button in right corner to close this window.

Los Peligros del Multiplayer

 

 

Hace un tiempo hablaba con un amigo desarrollador que aceptó un proyecto para un cliente, un juego de carreras bastante simple pero que debía habilitar, a futuro, una opción multiplayer. El engine a usar era Unity 3D. 

Sin contar con experiencia en proyectos multiplayer, la decisión que tomaron fue: “lo hacemos todo singleplayer y después vemos”. ¡Grave error!

Un proyecto multiplayer, por lo general, no debe ser tomado tan a la ligera, o al menos no considerarlo de la misma forma que un juego singleplayer. ¡La experiencia me incentivó a realizar este post!

 

¿Qué debemos tomar en cuenta al hacer un juego multiplayer?

 

Arquitectura, Seguridad y etc

No hay que tomar a la ligera a los usuarios, más si se trata de un juego con puntajes o con dinero real de por medio. Programas para hackear las requests de un juego online sobran y gente que la tiene clara y puede intentar rompernos las bolas (y mucho), también. Así que es importante tomar buenas prácticas para evitar que manipulando las requests destruyan la experiencia de los usuarios.

Entre ellas se encuentra lo más básico en un juego multiplayer online: derivar la lógica central del juego al server y no a los clientes. 

Así que, si nunca hiciste un juego MP, es buena idea googlear un poco y ponerte al día con las arquitecturas que suelen utilizarse. En líneas generales, es importante aprender a diferenciar el cliente del server, derivar la lógica a donde corresponde y aprender un poco sobre técnicas como predicción o similares.

 

Real-Time  vs Asincrónico.

Dependiendo que tipo de multiplayer sea en cuestión, vamos a optar por herramientas distintas y, en consecuencia, técnicas y tiempos de desarrollo distintos. La posta de la posta: a veces es un dolor de ovis, pero lo vale!

Si el juego es asincrónico o por turnos la tenemos semi-facil. Podemos utilizar servers como SmartFox Server, un engine multiplayer bastante difundido. Si bien el engine en sí no priva la posibilidad de realizar un juego realtime, leyendo en la web y realizando pruebas, uno puede notar que la performance para esos desarrollos no es la mejor en SFS (que me disculpen sus creadores).

No obstante, SFS tiene muchas facilidades en otros aspectos: matchmaking, rooms, chat, IP ban, moderator, server vars, etc, etc.

Otra opción en un juego multiplayer asincrónico es realizar la lógica del juego y los turnos en un web server típico: algo en PHP, algo en Java, algo en Python/Django, etc. No debemos olvidar que no tenemos gratis todas las funcionalidades interesantes como rooms, matchmaking, etc.

Hace unos años trabajé desarrollando Bloodrealm, un juego onda Magic o Hearthstone, donde el server lo hicimos nosotros. Dado que hablamos de un juego por turnos, es bastante más fácil controlar la lógica en base a requests asincrónicos.

Ahora, si nos tiramos para algo real-time.. entramos en un mundo fangoso (malas interpretaciones abstenerse). Yo prefiero evitar la opción de desarrollar nuestro propio engine-server en estos casos, porque hablamos de costos enormes.

 

¿Qué uso para el cliente + Qué uso para server?

Aunque hoy por hoy, muchos engines multiplayer tienen api clientes para muchas tecnologías, siempre hay compatibilidades a tener en cuenta. Me gustaría más adelante hablar un poco de las herramientas que tuve la posibilidad de usar, pero, por ahora, voy por un vistazo general .

Un ejemplo claro de solución de server muy utilizada es PhotonServer, que si bien tiene soporte para muchas plataformas cliente, en Unity es donde se destaca.

De todas formas, mi opción preferida para Unity, es uLink. Va como trompada. Está totalmente integrada, al punto que el mismo server se programa en Unity3D. Estos nos da mil facilidades, ya que disponemos para el lado server de cosas básicas del motor como la física, las colisiones y un lenguaje compartido, por lo que transportar objetos entre cliente y server es muy cómodo. Un buen ejemplo de juego que utiliza esta herramienta es el conocido Rust.

Si vamos a juegos hechos con Flash, hace unos años habían muchas opciones, como Smart Fox Server, PlayerIO (creo que ya no existe..) y varias más. Pero, honestamente, hace rato dejé de considerar Flash como una opción real.

En juegos HTML5, muchas de las viejas opciones multiplayer de Flash ahora soportan esta tecnología.

 

Peformance

No es lo mismo un juego de carrera donde la fluidez lo es todo, que un MMO social de casitas y animalitos donde la gente solo quiere chatear y hacer compra venta de ropa y huevadas(de repente se me ocurrió un juego: “La Salada Online”).

Cuando la fluidez es secundaria, casi cualquier server sirve. Caso contrario… y sin haber probado a fondo todas las opciones.. existen algunas que destacan. Personalmente encontré muy buena performance en uLink y en PhotonServer. Tuve buenas referencias de Raknet pero no tuve la suerte de probarlo, lo mismo sucede con ElectroServer.

Hay que tener en cuenta, si necesitamos fluidez, un par de cosas. Programar eficientemente (duh), tener un server potente (o varios..) y disponer de un buen ancho de subida/bajada para nuestro server. Sobre las buenas prácticas de programación para mejorar la eficiencia, pienso hablar más adelante.

 

Usuarios y Arquitectura

Aquí reitero lo mencionado en el ítem anterior No es lo mismo muchos usuarios en un mismo mundo, que muchos usuarios divididos en diversos rooms. Por otro lado, existe la posibilidad de que sea necesaria una escalabilidad importante. Es normal también usar servers distribuidos para asegurarnos que un crecimiento en los usuarios no nos hace explotar todo y balancear las cargas.

En juegos como MMOs, lo común es tener sectores divididos con cargas de usuario por sector. Juegos antiguos como el WoW permiten cargas por isla de algunas pocas decentas de personas, mientras juegos más modernos alcanzan bastante más. Por supuesto, cuanto más potencia necesitemos, mejor server (y más caro).

No es lo mismo hacer un Street Fighter Online, donde cada partida es sólo entre dos jugadores, que un League of Legends, donde es de a 10, o un Guild Wards, donde son decenas. La arquitectura de cada uno de estos juegos cambia y muchísimo.

Elementos como el matchmaker, lobbies de distintos tipos (antes de jugar, después de jugar, entre amigos, etc), queues diferentes (por ejemplo partidos por puntos, partidos para joder, etc)… hablamos de bastantes factores para tomar en cuenta!

Muchas herramientas permiten nativamente hacer matchmaking o formar lobbies/rooms. Otras no y hay que programarlo bien de cero. Por supuesto que, cuanto más grande y especifico es el juego, menos nos sirven las herramientas pre-hechas.

 

PetPet Park. Utiliza Smartfox, un claro ejemplo de un multiplayer social donde la performance no lo es todo

Back End Clásico: Usuarios, Información de Cuentas, Compras, etc,etc.

Es importante tener en cuenta factores como qué tipo de servidor necesitamos, desde el punto de vista físico. Por lo general utilizamos nuestros propios servidores físicos puestos en algún lugar del universo, aunque algunos motores recomiendan también utilizar servicios cloud de ellos mismos o bien de terceros como Amazon.

También tengamos en cuenta factores como la persistencia de datos. Si bien podemos usar bases de datos clásicas como un MySQL, meter bases no relacionales basadas en archivos(MongoDB por ejemplo) es una práctica bastante recomendada para la información de acceso constante. Muchos motores traen incluída alguna solución para la persistencia de datos noSQL y, la mayoría, nos permiten conectarnos también de la forma típica a nuestras propias bases relacionales.

 

Conclusión

Hacer un juego multiplayer es mucho más fácil que tiempo atrás. Como pasa en toda área de software, existen muchas herramientas y conceptos cada vez mejores y que aumentan la productividad.

No obstante, no debemos tomar a la ligera ningún desarrollo multiplayer. Si nunca realizamos alguno, antes de aceptar cualquier presupuesto, ¡Infórmense! Realmente es un mundo y cada proyecto puede tener sus aristas heavies.

Vi  varios proyectos de juegos cancelados “sólo” por subestimar la parte multiplayer. ¡Espero que con este post ayude a prevenir algún caso! (suena a campaña: Todos Unidos en contra del Mal del Cancelamiento)

¡Adio!

Leave a reply

 

small_keyboard